Defaults.Exposed › Báo cáo

SPF ~all so với -all: Softfail hay Hardfail — 139 Triệu Bản Ghi Đã Chọn Gì (2026)

Đã xuất bản 2026-07-03

Số liệu tính đến 2026-06-29 · phương pháp luận v7. Dữ liệu điều tra tổng hợp trên 261 triệu tên miền đã được chấm điểm. Tất cả số liệu đều là tổng hợp — chúng tôi không bao giờ công bố bản ghi của một doanh nghiệp cụ thể. Xem cách chúng tôi chấm điểm.

Mọi bản ghi SPF đều kết thúc bằng một cơ chế “all” — phán quyết đối với thư gửi từ bất kỳ nơi nào không nằm trong danh sách của bạn — và internet đã áp đảo chọn phương án nhẹ nhàng: 55.8% trong số 139 triệu tên miền công bố SPF kết thúc bằng ~all (softfail), so với 39.3% kết thúc bằng -all (hardfail). Chỉ một ký tự phân tách giữa “từ chối thư giả mạo” và “có lẽ là thư giả mạo — nhưng cứ chuyển đi”. Phương án nào phù hợp với bạn phụ thuộc vào một thiết lập thứ hai mà hầu hết chủ sở hữu không bao giờ cấu hình.

~all và -all thực sự nói gì với bên nhận?

• -all (hardfail): “Từ chối thư từ bất kỳ nơi nào khác.” Một lời từ chối dứt khoát.
• ~all (softfail): “Thư từ nơi khác có lẽ không hợp lệ — hãy nhận, có thể đánh dấu.” Một cái nhún vai.
• ?all (neutral): “Không có ý kiến.” Được 3.0% bên công bố chọn; chỉ mang tính bảo vệ trên danh nghĩa.
• +all: “Bất kỳ ai cũng có thể gửi thư nhân danh tôi.” Được 36,014 tên miền công bố, và tệ hơn cả việc không có bản ghi nào — vấn đề trải thảm chào đón có báo cáo riêng của nó.

Vậy ~all có sai không? Chỉ khi nó đứng một mình — và hầu như luôn là như vậy

Softfail có một lập luận hiện đại có thể bảo vệ được: hướng dẫn dành cho người gửi của Google, cùng với hầu hết các thực hành về khả năng gửi thành công đi theo hướng đó, đều hội tụ về ~all kết hợp với một chính sách DMARC thực thi (p=reject). Sự kết hợp này bảo vệ tốt như -all tại mọi bên nhận có đánh giá DMARC — mà hiện nay bao gồm tất cả các nhà cung cấp hộp thư lớn — mà không làm dội ngược cứng nhắc thư chuyển tiếp hợp lệ, vốn là nạn nhân điển hình của -all. Trong cấu hình đó, cái nhún vai lại có hiệu lực: DMARC cung cấp phán quyết mà SPF đã từ chối đưa ra.

Nhưng sự kết hợp mới chính là mấu chốt, và đây là điều mà cuộc điều tra bổ sung mà các hướng dẫn cài đặt không thể làm được: trong số 77,484,057 bản ghi softfail trên internet, chỉ 7.1 triệu — khoảng 1 trong 11 — có một chính sách DMARC thực thi đứng phía sau. Với 70.4 triệu tên miền còn lại, ~all đúng như nghĩa đen của nó. Bản ghi của họ nhận diện được thư giả mạo và vẫy tay cho nó đi qua.

Chẳng phải các yêu cầu bắt buộc năm 2024 đã khắc phục điều này rồi sao?

Không — và sự phân biệt này quan trọng hơn những gì hầu hết các bài viết ngụ ý. Google và Yahoo bắt đầu yêu cầu xác thực từ những người gửi hàng loạt vào tháng 2 năm 2024, với Microsoft theo sau vào tháng 5 năm 2025: SPF hoặc DKIM vượt qua và căn chỉnh, cộng với một bản ghi DMARC ở mức tối thiểu p=none. Các yêu cầu bắt buộc dừng lại ở chỗ không đòi hỏi thực thi — một tên miền có ~all, một bản ghi p=none và DKIM căn chỉnh vẫn tuân thủ đầy đủ, và vẫn hoàn toàn có thể bị giả mạo. Các yêu cầu bắt buộc đã chuẩn hóa giấy tờ, chứ không phải sự bảo vệ. Vùng ở giữa chưa được thực thi đó — tuân thủ, đã công bố, có thể bị giả mạo — chính xác là khoảng trống mà cuộc điều tra này đo lường, và nó là nhóm dân số lớn nhất trong bảo mật email.

Vậy bản ghi của bạn nên kết thúc bằng gì?

1. Bạn gửi thư và việc chuyển tiếp quan trọng (bản tin, danh sách gửi thư, bí danh): ~all với DMARC p=reject đứng phía sau — sự kết hợp được khuyến nghị ở trên.
2. Bạn gửi thư từ một thiết lập được kiểm soát chặt chẽ: -all phù hợp và tuyên bố chính sách ngay trong chính bản ghi. Hãy lập bản đồ các bên gửi của bạn trước — một kết thúc nghiêm ngặt trên một bản ghi chưa được lập bản đồ sẽ làm hỏng thư thật, hoặc tệ hơn.
3. Tên miền không bao giờ gửi thư: -all cộng với p=reject, ngay hôm nay. Không có gì hợp lệ tồn tại để bảo vệ, nên cũng chẳng có gì để làm hỏng.

Dù bạn chọn kết thúc nào, bài học một câu của cuộc điều tra vẫn đúng: bộ định tính chỉ quan trọng đúng bằng những gì thực thi nó. Vị trí của bạn trên bậc thang đó là có thể đo lường được.

Các câu hỏi thường gặp

SPF ~all hay -all tốt hơn? Không có cái nào tốt hơn một cách phổ quát. ~all với một chính sách DMARC thực thi là mô hình mà hướng dẫn của Google khuyến nghị — bảo vệ ngang nhau tại các bên nhận có đánh giá DMARC mà không làm hỏng thư chuyển tiếp. -all phù hợp với những người gửi được kiểm soát chặt chẽ. ~all đứng một mình — tình trạng của tất cả trừ 1 trong 11 tên miền softfail — là phương án yếu.

SPF softfail nghĩa là gì? ~all cho bên nhận biết rằng thư từ các máy chủ không được liệt kê có lẽ không hợp lệ nhưng vẫn nên được nhận, thường là với sự nghi ngờ. Nó chỉ trở thành sự bảo vệ thực sự khi một chính sách DMARC hành động dựa trên sự thất bại đó; xem SPF không có DMARC.

Hardfail -all có làm hỏng email chuyển tiếp của tôi không? Có thể: việc chuyển tiếp gửi lại thư của bạn từ máy chủ của bên chuyển tiếp, mà SPF của bạn không liệt kê, và một hardfail sẽ dẫn đến việc bị từ chối trước khi DKIM hoặc DMARC có tiếng nói. Rủi ro đó chính là lý do tồn tại của sự kết hợp ~all + p=reject.

Bây giờ Google và Microsoft có yêu cầu -all không? Không. Các yêu cầu bắt buộc dành cho người gửi hàng loạt đòi hỏi xác thực căn chỉnh, vượt qua và một bản ghi DMARC ở mức tối thiểu p=none — không thực thi, không có bộ định tính cụ thể. Việc Google từ chối thư hàng loạt không tuân thủ đã có hiệu lực; Microsoft đã đưa các thư thất bại vào thư rác và đang tiến tới việc từ chối hoàn toàn. Tuân thủ không phải là bảo vệ.

Kiểm tra xem bản ghi của bạn kết thúc bằng gì — và điều gì đứng phía sau nó

Hai lần tra cứu cho bạn biết cả hai, miễn phí, trong 30 giây. Nếu bạn là một trong 70.4 triệu cái nhún vai chưa được thực thi, giải pháp là một bản ghi DNS, chứ không phải một khoản mua sắm.

Kiểm tra tên miền của bạn → · Sửa SPF → · Sửa DMARC → · Mô hình trưởng thành SPF → · Bản đồ +all → · Chỉ dữ liệu tổng hợp. Dữ liệu được lưu trữ và xử lý tại EU.