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

DKIM Vượt Qua Nhưng DMARC Lỗi: Bẫy Chữ Ký Mặc Định gappssmtp.com / onmicrosoft.com (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.

Thư của bạn vượt qua DKIM với chữ ký mặc định của nhà cung cấp — d= kết thúc bằng gappssmtp.com (Google Workspace) hoặc onmicrosoft.com (Microsoft 365) — nhưng tên miền đó không khớp với tên miền From, vì vậy DMARC không nhận được kết quả căn chỉnh. Bật ký tên miền tùy chỉnh để sửa. Trong số 12,145,313 tên miền ủy quyền cho máy chủ thư của Google, chỉ 18.5% thực thi DMARC, theo dữ liệu khảo sát 261,086,232 tên miền được chấm điểm của Defaults.Exposed.

Cách sửa là một trong những cách sạch nhất trong xác thực email: bật ký DKIM tên miền tùy chỉnh. Trên Google Workspace đó là màn hình “Authenticate email” của bảng điều khiển Admin — tạo khóa, xuất bản một bản ghi TXT, bật lên. Trên Microsoft 365 đó là trang DKIM của cổng Defender — xuất bản hai CNAME selector, bật. Hai mươi phút làm việc, và DMARC cuối cùng nhận được kết quả căn chỉnh mà nó đã chờ.

Tại sao DKIM vượt qua nhưng DMARC vẫn lỗi?

Vì DMARC không hỏi “có chữ ký DKIM hợp lệ không?” — nó hỏi “có chữ ký DKIM hợp lệ cho tên miền trong header From không?” Điều kiện thứ hai đó được gọi là căn chỉnh, và đó là toàn bộ mục đích của DMARC: chứng minh tên miền mà người nhận thấy là tên miền đã ký.

Theo mặc định, Google Workspace ký thư của bạn với tên miền như yourdomain-com.20230601.gappssmtp.com (dấu thời gian thay đổi theo tên miền) và Microsoft 365 ký với yourtenant.onmicrosoft.com. Cả hai chữ ký đều hợp lệ về mật mã — các công cụ kiểm tra DKIM nói pass — nhưng tên miền d= thuộc về Google hoặc Microsoft, không phải của bạn. Ngay cả dưới căn chỉnh relaxed của DMARC, chỉ yêu cầu các tên miền tổ chức khớp, gappssmtp.com không phải yourdomain.com. Không khớp, không có kết quả căn chỉnh, và nếu SPF cũng không căn chỉnh (thường không thể — máy chủ nhận đánh giá SPF theo tên miền Return-Path, không phải header From, và chuyển tiếp phá vỡ hoàn toàn), DMARC lỗi.

Đây là bẫy xác định của mặc định nhà cung cấp: mặc định giúp bạn deliverability, không phải bảo vệ — căn chỉnh là bước tiếp theo bị thiếu. Dữ liệu khảo sát cho thấy bao nhiêu người gửi dừng ở mặc định: trong số 12,145,313 tên miền ủy quyền cho máy chủ thư của Google qua _spf.google.com (trong 138,927,207 nhà xuất bản SPF trên thế giới), chỉ 18.5% thực thi DMARC. Bức tranh của Microsoft cùng hình dạng: 10,205,070 tên miền ủy quyền spf.protection.outlook.com, 85.0% mang bản ghi SPF strict mà cài đặt M365 cấp cho họ — và chỉ 21.7% thực thi DMARC. So sánh đầy đủ trong bảng xếp hạng SPF nhà cung cấp email.

Bẫy vô hình trong sử dụng hàng ngày: thư được gửi, kiểm tra hộp thư trông ổn, không có lỗi — cho đến khi bạn xuất bản chính sách DMARC và thư của chính bạn bắt đầu thất bại. Quét miễn phí của chúng tôi phát hiện chính xác khoảng trống này.

Làm thế nào để phát hiện bẫy chữ ký mặc định trong Authentication-Results?

Mở thư bạn đã gửi (đến hộp thư Gmail hoặc Outlook), xem nguồn gốc/nguồn thô, và tìm header Authentication-Results. Dấu hiệu là DKIM pass với d= sai — ví dụ nhận bởi Gmail trông như:

Authentication-Results: mx.google.com;
       dkim=pass [email protected];
       spf=pass smtp.mailfrom=yourdomain.com;
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=yourdomain.com

Đọc theo ba câu hỏi:

Trên thư nhận bởi Microsoft, cùng câu chuyện xuất hiện là dkim=pass (signature was verified) header.d=yourtenant.onmicrosoft.com cùng với compauth=fail — mẫu được đề cập trong hướng dẫn từ chối Outlook.

Nếu header của bạn thay vào đó hiển thị cả dkim=pass và spf=pass với DMARC lỗi, bạn đang ở trường hợp căn chỉnh rộng hơn — hướng dẫn DMARC lỗi nhưng SPF và DKIM vượt qua đi qua toàn bộ relaxed vs strict alignment.

Cách bật ký DKIM tên miền tùy chỉnh?

1. Chạy quét miễn phí tại defaults.exposed trước khi chạm vào bất cứ thứ gì. Nó cho thấy tên miền của bạn có DKIM căn chỉnh không, chính sách DMARC thực sự là gì, và liệu còn gì khác (SPF, cú pháp bản ghi DMARC) sẽ vẫn chặn bạn sau cách sửa này — để bạn làm trọn công việc một lần.
2. Xác định bạn đang ký với mặc định nào. Kiểm tra header.d= trong Authentication-Results như trên: gappssmtp.com có nghĩa là mặc định Google Workspace, onmicrosoft.com có nghĩa là mặc định Microsoft 365.
3. Google Workspace: tạo và xuất bản khóa của riêng bạn. Trong bảng điều khiển Admin đến Apps → Google Workspace → Gmail → Authenticate email, chọn tên miền và nhấp Generate New Record (2048-bit trừ khi máy chủ DNS của bạn không thể lưu trữ). Xuất bản bản ghi TXT nó cung cấp tại google._domainkey.yourdomain.com, chờ DNS (tối đa 48 giờ), rồi — bước mọi người bỏ lỡ — nhấp Start authentication. Tạo bản ghi không làm gì cả cho đến khi bạn bật ký. Hướng dẫn đầy đủ: cài đặt DKIM trên Google Workspace.
4. Microsoft 365: xuất bản hai CNAME selector và bật. Trong cổng Defender đến Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM, chọn tên miền tùy chỉnh và tạo khóa. Xuất bản cả hai CNAME — selector1._domainkey và selector2._domainkey, trỏ đến target Microsoft cho bạn thấy (sao chép target chính xác từ cổng — tên miền được bật trước tháng 5/2025 kết thúc bằng .onmicrosoft.com của tenant; cái mới hơn kết thúc bằng .dkim.mail.microsoft) — rồi bật ký. Hai selector không phải tùy chọn: Microsoft xoay vòng khóa giữa chúng. Hướng dẫn đầy đủ: cài đặt DKIM trên Microsoft 365.
5. Xác minh chữ ký mới. Gửi thư mới đến hộp thư bên ngoài và kiểm tra lại Authentication-Results: dkim=pass bây giờ nên hiển thị header.d=yourdomain.com. Nếu bảng điều khiển DNS tự động thêm vùng vào CNAME target hoặc làm hỏng giá trị TXT dài, chữ ký sẽ không chuyển đổi — quirk của bảng điều khiển, không phải nhà cung cấp, gây ra hầu hết lỗi ở đây.
6. Quét lại và đưa kết quả căn chỉnh vào sử dụng. Xác nhận quét hiển thị DKIM căn chỉnh, rồi dùng nó: chính sách DMARC ở p=none không bảo vệ gì. Trên tất cả 261,086,232 tên miền được chấm điểm, chỉ 10.59% thực thi DMARC (dữ liệu tính đến 2026-06-29) — DKIM căn chỉnh là điều làm cho thực thi an toàn để tăng dần. Bắt đầu tại cách sửa DMARC.

Bật DKIM tùy chỉnh có phá vỡ gì không?

Không — đây là cách sửa xác thực email hiếm hoi với về cơ bản không có tác động tiêu cực: thư đã ra với chữ ký mặc định chỉ đơn giản ra với chữ ký tốt hơn, và nhà cung cấp tiếp tục quản lý khóa (Microsoft xoay vòng giữa hai selector tự động). Kiểu thất bại thực sự là làm nửa chừng — xuất bản TXT của Google nhưng không bao giờ nhấp Start authentication, hoặc xuất bản một selector M365 thay vì cả hai. Và đừng xóa bản ghi DNS sau này để “dọn dẹp”; ký dừng lại ngay khi khóa biến mất.

Một lưu ý về phạm vi: điều này sửa thư gửi qua Google hoặc Microsoft. Các công cụ newsletter và CRM cũng ký với mặc định của riêng chúng, và mỗi cái cần DKIM tên miền tùy chỉnh của riêng nó được bật — mẫu đó, và các quy tắc người gửi khối lượng lớn của Gmail giờ yêu cầu nó, được đề cập trong hướng dẫn 550-5.7.26.

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

DKIM hiển thị “pass” trên mọi công cụ kiểm tra — tại sao cần sửa gì? Vì các công cụ trả lời câu hỏi hẹp hơn DMARC hỏi. Chữ ký hợp lệ — nhưng nó là của gappssmtp.com hoặc onmicrosoft.com, không phải của bạn, vì vậy nó không tính gì trong căn chỉnh DMARC. Đây là lý do tại sao nhiều người gửi dừng ở mặc định: trong số 12,145,313 tên miền ủy quyền cho Google, chỉ 18.5% thực thi DMARC (dữ liệu tính đến 2026-06-29).

Căn chỉnh DMARC relaxed có cho phép chữ ký mặc định vượt qua không? Không. Căn chỉnh relaxed chỉ nới lỏng khớp thành các tên miền tổ chức — mail.yourdomain.com căn chỉnh với yourdomain.com. Tên miền tổ chức của chữ ký mặc định là gappssmtp.com hoặc onmicrosoft.com, không có gì chung với tên miền của bạn. Không có chế độ căn chỉnh nào cứu được d= của bên thứ ba.

Chữ ký gappssmtp.com / onmicrosoft.com có xấu không? Có nên xóa không? Không xấu — nó đảm bảo thư của bạn mang một số chữ ký hợp lệ, giúp ích cho lọc spam. Nó chỉ không phải của bạn. Bạn không xóa nó; bạn thay thế nó bằng cách bật ký tên miền tùy chỉnh.

Tên miền của tôi đang trên Microsoft 365 với SPF strict — tôi đã được bảo vệ chưa? Có thể chưa: bản ghi strict đó là mặc định M365 đang làm đúng một việc của nó. Trong số 10,205,070 tên miền ủy quyền spf.protection.outlook.com, 85.0% có SPF strict nhưng chỉ 21.7% thực thi DMARC (dữ liệu tính đến 2026-06-29). SPF cũng hỏng dưới chuyển tiếp, vì nó được đánh giá theo Return-Path thay vì header From — DKIM căn chỉnh là chân sống sót, đó chính xác là lý do cách sửa này quan trọng.

Cách sửa mất bao lâu? Công việc bảng điều khiển là vài phút mỗi nhà cung cấp. DNS là thời gian chờ: Google nói cho phép tối đa 48 giờ trước khi bắt đầu xác thực; CNAME của Microsoft thường hoạt động trong vài giờ. Ước tính một ngày làm việc từ đầu đến cuối, hầu hết là chờ.

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í khi chữ ký mới đã hoạt độ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, ngôn ngữ đơn giản, cho thấy DKIM căn chỉnh với tên miền của họ. Đây là tài liệu 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 tên miền xác thực là chính mình, không phải như tenant phụ của gappssmtp.com.

Kiểm tra căn chỉnh DKIM miễn phí

Xem thư của bạn có ký với tên miền của chính mình không — và chính xác cần sửa gì — một cách riêng tư và chỉ chủ sở hữu mới thấy.

Kiểm tra tên miền → · DMARC lỗi nhưng SPF và DKIM vượt qua → · Sửa DKIM → · Cài đặt DKIM trên Google Workspace → · Chỉ dữ liệu tổng hợp. Dữ liệu được lưu trữ và xử lý tại EU.