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

Email Chuyển Tiếp Lỗi SPF — Tại Sao Bạn Không Thể Sửa Và Điều Gì Thực Sự Hoạt Động (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.

Bạn không thể làm SPF vượt qua cho email được chuyển tiếp — chuyển tiếp phá vỡ SPF theo thiết kế, và cách sửa thực sự là DKIM căn chỉnh, thứ tồn tại qua chuyển tiếp. Quy mô là toàn khảo sát: 7,355,985 trong số 138,927,207 tên miền xuất bản SPF cho phép include chuyển tiếp của Namecheap, với tỷ lệ SPF strict <0.1%, theo dữ liệu khảo sát 261 triệu tên miền của Defaults.Exposed.

Bên dưới: tại sao không có bản ghi SPF nào bạn có thể viết sống sót qua chuyển tiếp, tại sao SRS và ARC không phải công cụ bạn kiểm soát, và cách sửa thực sự — ký DKIM với tên miền của bạn làm kết quả DMARC pass — cộng với trường hợp duy nhất cũng phá vỡ DKIM (danh sách gửi thư viết lại thư) và phải làm gì với phần dư đó.

Tại sao chuyển tiếp phá vỡ SPF?

Máy chủ nhận đánh giá SPF theo tên miền Return-Path (RFC5321.MailFrom), không phải header From. Khi bạn gửi trực tiếp, IP của máy chủ của bạn nằm trong bản ghi SPF của bạn và kiểm tra vượt qua. Khi người nhận tự động chuyển tiếp thư — đến Gmail cá nhân, qua bí danh của trường đại học, qua sản phẩm chuyển tiếp của nhà đăng ký — máy chủ bộ chuyển tiếp sẽ truyền lại thư, thường giữ tên miền của bạn trên Return-Path. Máy chủ nhận cuối cùng bây giờ hỏi: máy chủ chuyển tiếp này có được ủy quyền trong bản ghi SPF của bạn không?

Không, và sẽ không bao giờ có: bạn không chọn bộ chuyển tiếp, bạn không biết nó tồn tại, và cùng thư được chuyển tiếp qua dịch vụ khác vào ngày mai sẽ lỗi từ IP khác. SPF trả lời một câu hỏi — “IP này có đến từ máy chủ được tên miền Return-Path ủy quyền không?” — và với thư được chuyển tiếp, câu trả lời thực sự là không. Lỗi là SPF hoạt động đúng như quy định, không phải bản ghi của bạn sai.

Dữ liệu khảo sát cho thấy con đường này phổ biến như thế nào: 7,355,985 tên miền cho phép include chuyển tiếp email của Namecheap (spf.efwd.registrar-servers.com) — sản phẩm chuyển tiếp của một nhà cung cấp, lấy từ 139 triệu nhà xuất bản SPF — với tỷ lệ SPF strict <0.1% và chỉ 0.2% thực thi DMARC. Mẫu soft đó không phải sơ suất: chuyển tiếp chính xác là nơi -all strict bắn nhầm, và nhà cung cấp mà sản phẩm là chuyển tiếp thì giao hàng phù hợp. Toàn bộ câu chuyện qualifier nằm trong báo cáo ~all vs -all của chúng tôi, và bức tranh theo từng nhà cung cấp trong nhà cung cấp email nào có SPF mạnh nhất.

Không thể chỉ thêm máy chủ của bộ chuyển tiếp vào bản ghi SPF của tôi sao?

Không — và lý do là toàn bộ bài viết này:

1. Bạn không thể liệt kê các bộ chuyển tiếp. Bất kỳ người nhận nào, bất cứ nơi nào, đều có thể chuyển tiếp thư của bạn qua bất kỳ dịch vụ nào. Bản ghi SPF của bạn sẽ cần liệt kê các máy chủ mà bạn không thể biết trước.
2. Liệt kê chúng sẽ đánh bại mục đích. Các dịch vụ chuyển tiếp lớn chuyển tiếp thư cho hàng triệu khách hàng. Đặt dải IP của họ vào bản ghi và mọi thư bất kỳ người dùng nào của họ chuyển tiếp — kể cả kẻ giả mạo — đều vượt qua SPF như thể là bạn.

Cùng logic đó loại trừ việc làm lỏng qualifier để “làm chuyển tiếp hoạt động”: qualifier không phải lý do thư được chuyển tiếp bị lỗi, và một khi DMARC đã hoạt động, nó thay đổi ít hơn hầu hết hướng dẫn tuyên bố — xem dữ liệu qualifier. Bản ghi không phải đòn bẩy ở đây. Ngừng kéo nó.

Còn SRS và ARC — chúng không sửa chuyển tiếp sao?

Chúng giải quyết nó — nhưng không cái nào là của bạn để triển khai:

Dữ liệu và trạng thái cơ chế tính đến 2026-06-29.

SRS làm mất đi vấn đề SPF của bộ chuyển tiếp, không phải của bạn: viết lại Return-Path thay đổi SPF của ai được kiểm tra, trong khi header From của bạn — tên miền DMARC bảo vệ — không được chạm vào. ARC là quyết định tin tưởng giữa các nhà vận hành hạ tầng. Nếu hướng dẫn bảo bạn “triển khai SRS” với tư cách chủ sở hữu tên miền, nó đã nhầm lẫn bạn với nhà cung cấp dịch vụ chuyển tiếp.

Làm thế nào để email của tôi sống sót qua chuyển tiếp?

Làm DKIM, căn chỉnh với tên miền của bạn, trở thành kết quả DMARC pass của bạn. Chữ ký DKIM là mật mã được mang trong header thư: nó xác minh ở bất cứ đâu thư đến, qua bao nhiêu máy chủ đã chuyển tiếp, miễn là nội dung đã ký không bị sửa đổi. DMARC chỉ cần một kết quả căn chỉnh — SPF hoặc DKIM — vì vậy khi chuyển tiếp giết chân SPF, DKIM căn chỉnh giữ thư được xác thực.

1. Chạy quét miễn phí tại defaults.exposed trước khi chạm vào DNS. Nó cho thấy bạn có DKIM không, DKIM có ký với tên miền của bạn không, và DMARC của bạn đang ở đâu — để bạn sửa lỗ hổng thực sự thay vì chiến đấu với bản ghi SPF.
2. Xác nhận chuyển tiếp thực sự là vấn đề của bạn. Trong header Authentication-Results của thư bị ảnh hưởng, thư trực tiếp vượt qua SPF trong khi bản sao được chuyển tiếp bị lỗi từ IP của dịch vụ chuyển tiếp. Nếu cả SPF và DKIM vượt qua nhưng DMARC vẫn lỗi, bạn có vấn đề căn chỉnh thay vào đó — xem DMARC lỗi nhưng SPF và DKIM vượt qua.
3. Bật ký DKIM với tên miền của bạn tại mọi dịch vụ gửi — nhà cung cấp hộp thư trước, sau đó ESP và người gửi giao dịch. Mặc định của nhà cung cấp thường ký với tên miền của nhà cung cấp, không căn chỉnh; bạn muốn d=yourdomain. Bắt đầu tại cách sửa DKIM, với hướng dẫn thao tác cho Google Workspace và Microsoft 365.
4. Xác minh căn chỉnh, không chỉ vượt qua. Tên miền d= trong chữ ký phải khớp với tên miền From; dkim=pass trên tên miền của người khác không có ích gì cho DMARC của bạn.
5. Giữ nguyên bản ghi SPF. Giữ nó chính xác cho thư trực tiếp — nó vẫn xác thực hầu hết lưu lượng của bạn và vẫn là chân DMARC thứ hai của bạn. Chỉ ngừng cố gắng làm nó bao gồm các bộ chuyển tiếp.
6. Quét lại, rồi triển khai thực thi DMARC theo giai đoạn — phần tiếp theo, và hướng dẫn triển khai từ p=none đến p=reject.

Kết hợp này — SPF cộng DMARC thực thi dựa trên DKIM căn chỉnh — là mẫu chống chuyển tiếp, và nó hiếm: trong số 77.5 triệu tên miền xuất bản ~all, chỉ 9.2% (7,116,774) hỗ trợ nó bằng chính sách DMARC thực thi, và chỉ 3.87% trong 261 triệu tên miền được chấm điểm (10,092,481) hoàn thành bộ ba SPF + DKIM + DMARC-thực-thi đầy đủ, theo dữ liệu khảo sát (2026-06-29).

Còn danh sách gửi thư viết lại thư thì sao?

Con đường chuyển tiếp duy nhất mà DKIM căn chỉnh không sống sót: danh sách gửi thư sửa đổi thư — thẻ [list-name] trong tiêu đề, footer hủy đăng ký, tệp đính kèm bị gỡ bỏ. Thay đổi nội dung đã ký và hash nội dung không còn khớp, nên DKIM cũng lỗi (dkim=fail: body hash did not verify là hướng dẫn riêng cho lỗi đó). Bây giờ cả hai chân DMARC đều chết, và chỉ có danh sách mới có thể giảm thiểu nó (viết lại From, niêm phong ARC).

Phần dư này chính xác là những gì triển khai DMARC theo giai đoạn dành cho. Chuyển qua p=quarantine với ramp pct trong khi bạn xem báo cáo tổng hợp cho thấy bao nhiêu thư thực sự của bạn chảy qua các danh sách viết lại trước khi chính sách p=reject bắt đầu trả lại nó. Không nhảy sang reject trên tên miền mà người dùng sống trong danh sách gửi thư; nhưng cũng đừng dừng mãi ở p=none. Hướng dẫn triển khai theo giai đoạn hướng dẫn quá trình tăng dần.

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

Chuyển tiếp có phá vỡ DKIM cũng không? Chuyển tiếp đơn giản, không: chữ ký đi cùng thư và xác minh tại máy chủ nhận cuối. DKIM chỉ hỏng khi nội dung đã ký bị sửa đổi trong quá trình truyền — thẻ chủ đề của danh sách gửi thư và footer là trường hợp điển hình — đó là lý do phần dư danh sách được xử lý bằng dàn dựng chính sách DMARC, không phải bất cứ điều gì trong DNS.

Nên chuyển từ -all sang ~all để chuyển tiếp ngừng lỗi không? Thay đổi qualifier sẽ không làm bộ chuyển tiếp vượt qua — đó không phải lý do chúng lỗi. Điều đáng chú ý là include chuyển tiếp của Namecheap, 7,355,985 tên miền và dân số chuyển tiếp chuyên dụng lớn nhất trong khảo sát (2026-06-29), được giao với tỷ lệ SPF strict <0.1%: SPF soft có thể là mẫu đúng cho sản phẩm chuyển tiếp. Xem báo cáo ~all vs -all để biết qualifier thực sự thay đổi gì.

Tại sao thư của tôi vượt qua SPF khi gửi trực tiếp nhưng lỗi khi ai đó chuyển tiếp? Máy chủ nhận kiểm tra xem IP của máy chủ truyền cuối cùng có được ủy quyền bởi bản ghi SPF của tên miền Return-Path không. Trực tiếp: máy chủ của bạn, trong bản ghi của bạn, vượt qua. Được chuyển tiếp: máy chủ của bộ chuyển tiếp, không có trong bản ghi của bạn, lỗi. Bản ghi của bạn không thay đổi — IP truyền đã thay đổi.

Có thể cài đặt SRS để sửa điều này không? Chỉ khi bạn là bộ chuyển tiếp. SRS chạy trên máy chủ thực hiện chuyển tiếp, và ngay cả khi nó chạy, kết quả SPF pass thuộc tên miền của bộ chuyển tiếp và không căn chỉnh với From của bạn — DMARC của bạn vẫn cần chân DKIM.

SPF có vô dụng không nếu chuyển tiếp phá vỡ nó anyway? Không. Hầu hết thư được gửi trực tiếp, nơi SPF hoạt động đúng như dự kiến, và nó vẫn là một trong hai chân DMARC của bạn. Trong số 261,086,232 tên miền trong khảo sát (2026-06-29), 138,927,207 xuất bản SPF — giữ bản ghi của bạn chính xác qua trang sửa SPF, và để DKIM mang phần còn lại được chuyển tiếp.

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

Nếu bạn đang sửa điều này cho khách hàng hoặc nhà tuyển dụng, hãy đóng vòng lặp với bằng chứng. Khi DKIM tên miền tùy chỉnh đã hoạt động và DMARC đã được dàn dựng, chạy lại quét miễn phí và chuyển tiếp báo cáo được chấm điểm cho chủ doanh nghiệp: có ngày tháng, ngôn ngữ đơn giản, cho thấy tên miền vẫn được xác thực ngay cả khi thư của nó được chuyển tiếp. Đó là tài liệu cho đợt tái tục bảo hiểm mạng và bảng câu hỏi nhà cung cấp tiếp theo — tài liệu trước-và-sau, không phải “tôi đã bật một thứ gì đó”.

Kiểm tra tên miền → · DMARC lỗi nhưng SPF và DKIM vượt qua → · Sửa DKIM → · 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.