Defaults.Exposed › Cách khắc phục › Guides

SPF Lỗi Với Công Cụ SaaS? Tại Sao Và Thứ Tự Sửa — Phiên Bản Châu Âu (2026)

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

Số liệu tính đến 2026-06-29 · phương pháp luận v7. Dữ liệu tổng hợp từ 261 triệu tên miền được chấm điểm. Xem cách chúng tôi chấm điểm.

Khi công cụ SaaS “lỗi SPF”, bản ghi của bạn thường không phải vấn đề: thư đang thất bại căn chỉnh DMARC, hoặc chuỗi include của bạn đã vượt giới hạn 10 tra cứu DNS của SPF. 2,119,539 trong 138,927,207 tên miền xuất bản SPF đang ở 9–10 tra cứu — một include SaaS là rơi xuống bờ vực — theo dữ liệu khảo sát 261,086,232 tên miền của Defaults.Exposed.

Bên dưới: cách xác định bạn đang gặp vấn đề nào trong hai vấn đề, rồi thứ tự sửa — quét trước, tìm tên miền công cụ thực sự gửi từ đâu, chuyển nhà cung cấp sang DKIM tên miền tùy chỉnh, và chỉ thêm include SPF nơi nó thực sự giúp ích — cộng với thông tin cụ thể cho HubSpot, Salesforce, Mailchimp và SendGrid.

Tại sao thư từ công cụ SaaS lỗi SPF?

Ba mẫu bao gồm hầu hết mọi trường hợp:

Dữ liệu tính đến 2026-06-29.

Hàng in đậm là nơi hầu hết mọi người đang đứng. Thêm các dòng include: cho mọi công cụ không chạm vào nó — và mỗi dòng đưa bạn gần hơn đến hàng thứ hai: ít nhất 797,263 tên miền đã vượt quá giới hạn 10 tra cứu, và SPF của họ giờ trả về PermError không bảo vệ gì. Con số đầy đủ trong báo cáo SPF PermError.

SPF thực sự kiểm tra tên miền nào?

Không phải tên miền trong header From. Máy chủ nhận đánh giá SPF theo tên miền Return-Path (RFC5321.MailFrom, còn gọi là địa chỉ bounce hoặc envelope-from) — header From mà người nhận thấy không có phần nào trong chính kiểm tra SPF.

Một thực tế đơn giản này giải thích hầu hết “lỗi SPF SaaS”. Nền tảng marketing của bạn gửi với Return-Path như [email protected]; SPF được kiểm tra theo vendor.com và vượt qua rõ ràng. Sau đó DMARC hỏi liệu tên miền được kiểm tra SPF đó có khớp với tên miền From của bạn không. Không, vì vậy chân SPF của DMARC lỗi và dashboard của bạn nói “SPF đang lỗi”. Chỉnh sửa bản ghi SPF của chính bạn không thể sửa điều đó — bản ghi của bạn không bao giờ được tham khảo.

Thứ tự sửa là gì?

1. Chạy quét miễn phí trước. Nó cho bạn biết trong một lần xem SPF của bạn có bị thiếu, bị trùng, vượt giới hạn tra cứu hay ổn không, và DMARC đang ở đâu — trước khi bạn chạm vào DNS.
2. Tìm Return-Path mà công cụ thực sự dùng. Gửi cho mình một bài kiểm tra từ công cụ và đọc header Return-Path (và Authentication-Results) trong thư thô. Điều đó cho bạn biết bạn đang ở hàng nào trong bảng trên.
3. Bật DKIM tên miền tùy chỉnh của nhà cung cấp. Mọi công cụ SaaS nghiêm túc đều cung cấp “xác thực tên miền”: vài bản ghi CNAME để nó ký DKIM với tên miền của bạn. Chữ ký đó căn chỉnh với tên miền From của bạn, vì vậy DMARC vượt qua qua DKIM — bền vững, và ngay cả khi thư được chuyển tiếp. Đây là cách sửa bền vững.
4. Chỉ thêm include SPF của nhà cung cấp nếu nó dùng return-path của bạn — bạn đã bật bounce domain tùy chỉnh của nó, hoặc nó thực sự gửi với tên miền của bạn trong envelope. Include cho nhà cung cấp bounce qua tên miền của chính họ không mua gì cả và tiêu ngân sách tra cứu.
5. Đếm tra cứu DNS trước khi lưu. Giới hạn là 10 tra cứu đã phân giải, includes tính đệ quy, và 2,119,539 tên miền đã ở 9–10 — p99 của khảo sát là 9. Gần bờ vực? Trước tiên xóa includes cho các công cụ bạn không còn dùng. Vừa chuyển đổi nhà cung cấp email? Kiểm tra bản ghi thứ hai còn sót lại — hai bản ghi SPF bằng một PermError.
6. Quét lại và xác nhận. SPF vượt qua trên tên miền đúng, DKIM căn chỉnh, DMARC vượt qua. Tài liệu tham khảo đầy đủ nằm tại cách sửa SPF; hướng dẫn từng nhà cung cấp như SPF trên GoDaddy và DMARC trên IONOS bao gồm các thao tác bảng điều khiển DNS.

Nên làm gì với HubSpot, Salesforce, Mailchimp và SendGrid?

HubSpot. Kết nối tên miền gửi của bạn trong cài đặt HubSpot và xuất bản hai CNAME DKIM mà nó cung cấp (hs1-… / hs2-…). Điều đó căn chỉnh DKIM với tên miền From. Bạn không cần include SPF HubSpot trừ khi bạn đã cấu hình HubSpot để dùng bounce domain của chính bạn.

Salesforce. Tạo khóa DKIM trong Salesforce Setup và xuất bản cặp CNAME nó tạo ra. Nếu Salesforce gửi với return-path của tổ chức bạn, hãy thêm include:_spf.salesforce.com và cấu hình bounce domain — đây là CRM lớn duy nhất nơi include SPF thường thực sự cần thiết.

Mailchimp. Xác thực tên miền và xuất bản CNAME DKIM k2 / k3. Căn chỉnh Mailchimp chỉ DKIM — không có include SPF nào để thêm nữa, và thêm một cái từ hướng dẫn cũ chỉ lãng phí tra cứu.

SendGrid. Hoàn thành xác thực tên miền (“automated security”): ba CNAME xử lý cả DKIM và return-path trên tên miền con của chính bạn. Không cần include SPF. Trong số 740,321 tên miền có SPF cho phép sendgrid.net, chỉ 18.0% có DMARC thực thi (dữ liệu tính đến 2026-06-29) — hầu hết người gửi SendGrid dừng lại một bước trước.

Zendesk và mọi thứ khác: cùng mẫu. Tìm trang “domain authentication” của công cụ, xuất bản CNAME DKIM của nó, và chỉ chạm vào SPF nếu công cụ ghi lại rằng nó dùng return-path của bạn.

SPF có khác cho các doanh nghiệp châu Âu không?

Không — SPF, DKIM và DMARC hoạt động giống nhau ở mọi nơi. Điều khác ở châu Âu là bối cảnh: ai đang hỏi, và những người hàng xóm của bạn đã làm gì rồi.

ccTLD của bạn đặt tiêu chuẩn địa phương. Các ccTLD châu Âu xuất bản SPF cao hơn tỷ lệ .com, nhưng các tên miền hoàn thành công việc — chính sách DMARC thực thi bên trên — là thiểu số ở mọi nơi:

Dữ liệu tính đến 2026-06-29. Pháp: 13.65% thực thi DMARC; Ý: 5.24%.

Máy chủ lưu trữ châu Âu của bạn quan trọng. 4,346,526 tên miền cho phép máy chủ thư EU của IONOS (_spf-eu.ionos.com) trong SPF — và chỉ 0.3% kết thúc bằng -all strict, với 1.0% DMARC-thực thi. 2,132,049 tên miền của OVH làm tốt hơn về strictness (43.7%) nhưng chỉ 2.2% thực thi DMARC (dữ liệu tính đến 2026-06-29). Nếu bạn không bao giờ chạm vào bản ghi của mình, bạn đang đứng trên các mặc định đó.

Các cơ quan quản lý giờ đây đặt tên điều này. Điều 21(2)(j) NIS2 yêu cầu các thực thể trong phạm vi bảo mật thông tin liên lạc, và Quy định Thực hiện của Ủy ban (EU) 2024/2690 quy định rõ các biện pháp bảo mật email và DNS. Xác thực email là phần cụ thể, có thể kiểm tra — và, không giống các vấn đề tuân thủ khác, miễn phí để sửa.

Về nơi lưu trữ dữ liệu: scanner và khảo sát Defaults.Exposed chạy tại AWS eu-west-1, chúng tôi chỉ xuất bản số liệu tổng hợp, và một lần quét chỉ kiểm tra tên miền bạn hỏi.

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

Công cụ kiểm tra SPF của tôi nói “pass” nhưng dashboard của công cụ nói SPF đang lỗi — tại sao? Công cụ kiểm tra đã kiểm tra bản ghi của bạn; máy chủ nhận đã kiểm tra tên miền Return-Path mà công cụ thực sự dùng, sau đó DMARC so sánh với tên miền From của bạn. Đó là lỗi căn chỉnh, không phải lỗi bản ghi — được sửa bằng DKIM tên miền tùy chỉnh của nhà cung cấp, không phải bằng chỉnh sửa SPF.

Có nên thêm include SPF cho mọi công cụ chúng tôi dùng không? Không. Mỗi include tiêu một phần ngân sách 10 tra cứu của SPF, đệ quy: 2,119,539 trong 138,927,207 tên miền xuất bản SPF đang ở 9–10 tra cứu, và ít nhất 797,263 đã vượt — SPF của họ trả về PermError và không bảo vệ gì (dữ liệu tính đến 2026-06-29).

Include có sửa DMARC cũng không? Chỉ khi công cụ gửi với return-path của bạn, vì vậy SPF vượt qua và căn chỉnh. Đối với hầu hết công cụ SaaS thì không — đó là lý do tại sao DKIM căn chỉnh, không phải SPF, là chân làm DMARC vượt qua cho thư SaaS.

Đây có phải yêu cầu pháp lý ở EU không? Đối với các thực thể trong phạm vi NIS2, Điều 21(2)(j) và Quy định Thực hiện (EU) 2024/2690 làm cho bảo mật email thành nghĩa vụ. Ngay cả ngoài phạm vi, các nhà bảo hiểm và bảng câu hỏi khách hàng ngày càng hỏi — và tính đến 2026-06-29, không có ccTLD EU nào đưa được đến một phần ba tên miền lên chính sách DMARC thực thi (29.43% ở .nl tốt nhất; 5.24% ở .it).

Gửi báo cáo cho chủ sở hữu

Khi các CNAME đã hoạt động, chạy lại quét và chuyển tiếp báo cáo được chấm điểm cho chủ doanh nghiệp hoặc khách hàng. Nó cho thấy, bằng ngôn ngữ đơn giản, điều gì đang lỗi, bạn đã sửa gì và tên miền hiện đứng ở đâu — chính xác là bằng chứng họ cần cho đợt tái tục bảo hiểm hoặc bảng câu hỏi bảo mật khách hàng, bằng văn bản thay vì chỉ là lời nói của bạn.

Kiểm tra tên miền miễn phí

Xem chính xác chân nào của SPF, DKIM và DMARC đang lỗi — một cách riêng tư và chỉ chủ sở hữu mới thấy.

Kiểm tra tên miền → · Sửa SPF → · SPF PermError: “quá nhiều tra cứu DNS” → · Cách chúng tôi chấm điểm → · Chỉ dữ liệu tổng hợp. Dữ liệu được lưu trữ và xử lý tại EU.