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

DMARC Lỗi Nhưng SPF và DKIM Vượt Qua? Cách Sửa Căn Chỉnh (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.

DMARC cần nhiều hơn là vượt qua — tên miền vượt qua SPF hoặc DKIM phải khớp với tên miền From của bạn. Hầu hết thư “SPF pass, DMARC fail” đã vượt qua SPF trên tên miền bounce của nhà cung cấp, không phải của bạn. Chỉ 7.4% trong 261,086,232 tên miền được chấm điểm vượt qua SPF với căn chỉnh dưới chính sách DMARC thực thi, theo dữ liệu khảo sát của Defaults.Exposed (2026-06-29).

Cách sửa nhanh hơn bạn nghĩ. Đọc header Authentication-Results để xem chân nào — SPF hay DKIM — đang vượt qua trên sai tên miền; rồi bật ký DKIM tên miền tùy chỉnh của dịch vụ gửi của bạn (thường là vài CNAME, và cách sửa tồn tại qua chuyển tiếp), hoặc đặt return-path tùy chỉnh của nó để SPF vượt qua trên tên miền của bạn. Một chân căn chỉnh là tất cả những gì DMARC cần.

DMARC lỗi như thế nào khi cả SPF và DKIM đều vượt qua?

Vì DMARC không bao giờ hỏi “SPF có vượt qua không?” Nó hỏi: SPF hoặc DKIM có vượt qua cho một tên miền khớp với địa chỉ From người nhận thấy không? Điều kiện bổ sung đó được gọi là căn chỉnh, và đó là toàn bộ mục đích của DMARC — không có nó, ai cũng có thể vượt qua SPF trên tên miền họ sở hữu trong khi hiển thị tên miền của bạn trong header From.

Mỗi kiểm tra xác thực một tên miền khác nhau:

Kiểm tra	Tên miền thực sự được đánh giá	Nơi xem
SPF	Return-Path (RFC5321.MailFrom, địa chỉ bounce/envelope-from) — không phải header From	`smtp.mailfrom=` trong Authentication-Results
DKIM	Tên miền trong thẻ `d=` của chữ ký — bất cứ điều gì người ký chọn	`header.d=` trong Authentication-Results
DMARC	*Tên miền header From của bạn — và yêu cầu tên miền SPF hoặc* `d=` DKIM khớp với nó**	`header.from=` trong Authentication-Results

Đây là cách các phần thường xảy ra sai: nền tảng newsletter hoặc CRM của bạn gửi với Return-Path như [email protected], SPF được kiểm tra với vendor.com và vượt qua, DKIM vượt qua với d=vendor.com — và DMARC lỗi, vì không có tên miền nào vượt qua khớp với yourcompany.com. Mọi kiểm tra đều nói sự thật; không kiểm tra nào xác thực bạn. Chỉnh sửa bản ghi SPF của chính bạn không thể sửa điều này — nó không bao giờ được tham khảo. Đây là cùng bẫy được đề cập trong SPF lỗi cho các công cụ SaaS của bạn.

Dữ liệu khảo sát cho thấy rất ít người gửi hoàn thành bước cuối này: 27,640,987 trong 261,086,232 tên miền được chấm điểm (10.59%) có chính sách DMARC thực thi, và chỉ 7.4% vượt qua SPF với căn chỉnh dưới một chính sách như vậy. Trong số 77.5 triệu tên miền có SPF kết thúc bằng softfail (~all), chỉ 9.2% nằm dưới chính sách DMARC thực thi; trong số các nhà xuất bản hardfail (-all), 12,142,351 được thực thi trong khi 42,514,532 thì không. Hầu hết tên miền dừng lại ở “SPF vượt qua” — điều mà không có DMARC hành động dựa trên đó, không bảo vệ được gì.

Cách đọc Authentication-Results để thấy chân nào không căn chỉnh?

Gửi cho mình một thư qua dịch vụ đang lỗi, mở nguồn thô, và tìm header Authentication-Results. Một kết quả không căn chỉnh điển hình trông như này:

Authentication-Results: mx.google.com;
       spf=pass smtp.mailfrom=bounces.espmail.net;
       dkim=pass header.d=espmail.net;
       dmarc=fail (p=NONE) header.from=yourcompany.com

Đọc theo ba so sánh:

Chân SPF: smtp.mailfrom= có kết thúc bằng tên miền của bạn không? Ở đây là bounces.espmail.net — không căn chỉnh.
Chân DKIM: header.d= có kết thúc bằng tên miền của bạn không? Ở đây là espmail.net — không căn chỉnh.
Kết quả DMARC: header.from= là tên miền DMARC đang bảo vệ. Không chân nào khớp với nó, nên dmarc=fail — dù cả hai kiểm tra riêng lẻ đều nói pass.

Chân nào đã liên quan đến tên miền của chính bạn (hoặc có thể làm cho liên quan) là chân cần sửa. Bạn chỉ cần một.

Sự khác biệt giữa căn chỉnh relaxed và strict là gì?

DMARC cung cấp hai chế độ khớp, được đặt bằng các thẻ aspf (SPF) và adkim (DKIM) trong bản ghi DMARC của bạn:

Relaxed (r, mặc định): hai tên miền phải chia sẻ cùng tên miền tổ chức — tên miền có thể đăng ký theo Public Suffix List. bounce.yourcompany.com căn chỉnh với yourcompany.com; d=mail.yourcompany.com của DKIM cũng vậy. Đây là lý do return-path tùy chỉnh của nhà cung cấp và DKIM tùy chỉnh, sống trên tên miền con, hoạt động.
Strict (s): các tên miền phải khớp chính xác, từng ký tự. bounce.yourcompany.com không còn căn chỉnh với yourcompany.com.

Nếu bản ghi của bạn không đề cập đến aspf hay adkim, bạn đang ở chế độ relaxed — và hầu như chắc chắn bạn muốn ở đó. Chế độ strict không thêm bảo mật có ý nghĩa cho hầu hết người gửi và lặng lẽ phá vỡ mọi nguồn gửi tên miền con hợp lệ mà bạn đã cài đặt. Nếu DMARC đang lỗi và bản ghi của bạn chứa aspf=s hay adkim=s, điều đó một mình có thể là nguyên nhân lỗi.

Cách sửa căn chỉnh DMARC?

Chạy quét miễn phí tại defaults.exposed trước khi chạm vào DNS. Nó hiển thị bản ghi và chính sách DMARC của bạn, SPF và DKIM đã được cài đặt để căn chỉnh hay chưa, và những gì khác đang hỏng — để bạn sửa đúng chân trước.
Kiểm tra từng dịch vụ gửi và đọc Authentication-Results (như trên). Liệt kê mọi nguồn — nhà cung cấp hộp thư, công cụ newsletter, CRM, ứng dụng hóa đơn — và ghi chú theo từng nguồn xem smtp.mailfrom và header.d là tên miền của bạn hay của nhà cung cấp.
Bật ký DKIM tên miền tùy chỉnh cho từng nhà cung cấp — cách sửa bền vững. Mọi dịch vụ gửi nghiêm túc đều cung cấp “xác thực tên miền”: vài bản ghi CNAME cho phép nó ký là d=yourcompany.com (hoặc tên miền con, căn chỉnh trong chế độ relaxed). DKIM căn chỉnh thường là cách sửa dễ hơn và là cách duy nhất tồn tại qua chuyển tiếp, vì chuyển tiếp phá vỡ SPF theo thiết kế.
Để căn chỉnh SPF, bật return-path tùy chỉnh của nhà cung cấp (thường gọi là bounce domain tùy chỉnh) — thường là một CNAME như bounce.yourcompany.com trỏ đến nhà cung cấp. SPF sau đó vượt qua trên tên miền tổ chức của bạn và căn chỉnh. Làm điều này khi được cung cấp, nhưng coi nó là chân thứ hai, không phải thay thế cho DKIM căn chỉnh.
Giữ căn chỉnh ở chế độ relaxed trừ khi bạn có lý do cụ thể, đã hiểu rõ để dùng aspf=s/adkim=s.
Quét lại và xác nhận cả hai chân, rồi tiến tới thực thi. Chính sách DMARC p=none báo cáo nhưng không chặn gì; khi các nguồn gửi thực sự của bạn căn chỉnh, con đường đầy đủ đến chính sách bảo vệ bạn nằm trên trang sửa DMARC, và hướng dẫn từng nhà cung cấp như DMARC trên IONOS bao gồm các thao tác trên bảng điều khiển DNS.

Nên sửa căn chỉnh SPF hay DKIM?

Bạn cần một chân căn chỉnh cho mỗi nguồn gửi. Nếu bạn chỉ có thể làm một, sự lựa chọn không khó:

Cách sửa	Bao gồm	Tồn tại qua chuyển tiếp?
DKIM căn chỉnh (ký tên miền tùy chỉnh)	Vài CNAME trong bảng “xác thực tên miền” của nhà cung cấp	Có — chữ ký đi cùng thư
SPF căn chỉnh (return-path/bounce domain tùy chỉnh)	Một CNAME, nơi nhà cung cấp cung cấp	Không — IP của bộ chuyển tiếp thay thế IP của nhà cung cấp

Trường hợp đặc biệt đáng biết: Google Workspace và Microsoft 365 sẽ ký DKIM thư của bạn theo mặc định với các tên miền dự phòng của họ (gappssmtp.com, onmicrosoft.com) — nên DKIM hiển thị pass trong khi DMARC vẫn lỗi. Đây là trường hợp cụ thể phổ biến nhất của toàn bộ vấn đề này, và nó có hướng dẫn riêng: DKIM vượt qua nhưng DMARC vẫn lỗi: bẫy chữ ký mặc định.

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

Cả SPF và DKIM đều cần căn chỉnh để DMARC vượt qua không? Không — một chân căn chỉnh vượt qua là đủ. Thực hành tốt nhất vẫn là căn chỉnh cả hai, để khi chuyển tiếp phá vỡ chân SPF, chân DKIM vẫn mang kết quả DMARC pass. Trong 261,086,232 tên miền được chấm điểm trong khảo sát 2026-06-29, chỉ 3.87% hoàn thành bộ ba SPF + DMARC + DKIM đầy đủ.

Bảng điều khiển ESP của tôi nói SPF và DKIM đã “xác minh” — tại sao DMARC vẫn lỗi? “Xác minh” thường có nghĩa là gửi của nhà cung cấp vượt qua trên tên miền của nhà cung cấp. Trừ khi bạn hoàn thành các bước tên miền tùy chỉnh của họ (CNAME DKIM, return-path tùy chỉnh), thư xác thực là nhà cung cấp, không phải bạn — và DMARC so sánh với tên miền From của bạn.

Bản ghi SPF strict -all có đủ không khi không có căn chỉnh? Không. Qualifier strict tăng cường kết quả SPF trên tên miền Return-Path, nhưng DMARC vẫn cần tên miền đó là của bạn. Tính đến khảo sát 2026-06-29, chỉ 12,142,351 trong số tên miền xuất bản -all nằm dưới chính sách DMARC thực thi — 42,514,532 còn lại có bản ghi strict mà không có chính sách nào hành động dựa trên đó.

Nên chuyển sang căn chỉnh strict (aspf=s/adkim=s) để bảo mật hơn không? Gần như không bao giờ. Căn chỉnh relaxed đã yêu cầu cùng tên miền có thể đăng ký, điều mà kẻ giả mạo không kiểm soát. Chế độ strict chủ yếu phá vỡ các nguồn gửi tên miền con của chính bạn — kiểm tra nó bất cứ khi nào căn chỉnh lỗi bất ngờ.

DMARC chỉ lỗi trên thư người nhận chuyển tiếp — cùng cách sửa không? Đó là chân SPF chết trong quá trình truyền: IP của máy chủ chuyển tiếp không nằm trong bản ghi SPF của ai cho return-path của bạn. Bạn không thể sửa SPF cho thư được chuyển tiếp; DKIM căn chỉnh là câu trả lời, vì chữ ký tồn tại qua chuyển tiếp nguyên vẹn. Chi tiết trong email chuyển tiếp bị lỗi SPF.

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. Chạy lại quét miễn phí sau khi các CNAME được áp dụng và chuyển tiếp báo cáo được chấm điểm cho chủ doanh nghiệp: có ngày tháng, bằng ngôn ngữ đơn giản, cho thấy SPF, DKIM và DMARC căn chỉnh và vượt qua. Đó là tài liệu họ cần cho đợt tái tục bảo hiểm mạng và bảng câu hỏi bảo mật nhà cung cấp tiếp theo — bằng chứng về cấu hình hoạt động, không chỉ “tôi đã thêm một số bản ghi DNS”.

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