Defaults.Exposed › Cách khắc phục › Guides
'DKIM Signature Not Valid' — Các Nguyên Nhân, Theo Thứ Tự Kiểm Tra (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.
“DKIM signature not valid” có năm nguyên nhân phổ biến, tốt nhất kiểm tra theo thứ tự: nội dung bị sửa đổi trong quá trình truyền, bản ghi khóa bị cắt ngắn, khóa được xuất bản không khớp với người ký, sai selector, và canonicalization quá mỏng manh. Chỉ 10,092,481 trong 261,086,232 tên miền được chấm điểm (3.87%) nắm giữ bộ ba SPF + DKIM + DMARC-thực-thi đầy đủ, theo dữ liệu khảo sát Defaults.Exposed (2026-06-29).
Thứ tự sửa quan trọng vì nguyên nhân phổ biến nhất không nằm trong DNS của bạn chút nào. Kiểm tra những gì đã thay đổi thư trong quá trình truyền trước, sau đó làm việc từ ngoài vào trong: tính toàn vẹn của bản ghi khóa, liệu nó có khớp với những gì máy chủ thư của bạn thực sự đang ký không, selector, và cuối cùng là cài đặt ký. Hầu hết chữ ký không hợp lệ được sửa ở bước một hoặc hai.
”DKIM signature not valid” thực sự có nghĩa là gì?
Mỗi thư được ký DKIM mang một header DKIM-Signature đặt tên tên miền (d=), selector (s=), hash của nội dung thư (bh=), và chữ ký mật mã trên hash nội dung cộng các header được chọn (b=). Máy chủ nhận lấy khóa công khai của bạn từ DNS tại <selector>._domainkey.<domain>, tính lại cả hai hash, và kiểm tra chữ ký (RFC 6376). “Signature not valid” là cách diễn đạt của công cụ kiểm tra và header cho: xác minh đó đã chạy và thất bại — khóa được tìm thấy, nhưng phép tính không ra đúng.
Mệnh đề cuối cùng đó là vàng chẩn đoán. Trình xác minh không thể tìm khóa của bạn sẽ nói điều khác — thường là header như dkim=fail (no key for signature) — và đó là vấn đề selector, được bao gồm trong DKIM “no key for signature” — sửa selector và xoay vòng. Và trình xác minh tính lại hash nội dung khác thường nói rõ: body hash did not verify — Microsoft báo cáo nó là dkim=fail (body hash did not verify), trong khi Gmail thường hiển thị cùng chẩn đoán đó là dkim=neutral (body hash did not verify). Dù cách nào, nó trỏ đến sửa đổi nội dung, được bao gồm trong “body hash did not verify” — điều gì đã thay đổi thư của bạn. Đọc từ ngữ chính xác trong header Authentication-Results trước khi chạm vào bất cứ điều gì: nó cho bạn biết bạn đang nắm nguyên nhân nào trong năm nguyên nhân.
Làm đúng điều này hiếm: chỉ 51.84% tên miền được chấm điểm xuất bản khóa DKIM có thể phát hiện trong DNS, theo dữ liệu khảo sát Defaults.Exposed, và chỉ 3.87% trong 261 triệu tên miền được chấm điểm kết hợp SPF, DKIM và chính sách DMARC thực thi — cấu hình mà các quy tắc người gửi khối lượng lớn hiện nay giả định. Bức tranh theo giai đoạn nằm trong mô hình trưởng thành áp dụng SPF.
Năm nguyên nhân là gì, theo thứ tự?
| # | Nguyên nhân | Dấu hiệu nhận biết | Cách sửa |
|---|---|---|---|
| 1 | Nội dung bị sửa đổi trong quá trình truyền — footer gateway, tuyên bố từ chối trách nhiệm pháp lý, thẻ chủ đề danh sách gửi thư | body hash did not verify trong Authentication-Results; thư bên ngoài lỗi, thư trực tiếp vượt qua | Ký sau sửa đổi, hoặc ngừng sửa đổi — xem hướng dẫn body-hash |
| 2 | Khóa dài bị cắt ngắn hoặc làm hỏng | p= được xuất bản ngắn hơn rõ ràng so với khóa bạn tạo; mọi máy chủ nhận đều lỗi | Xuất bản lại khóa 2048-bit dưới dạng chuỗi TXT được chia đúng cách |
| 3 | Khóa được xuất bản không khớp với người ký | Lỗi bắt đầu ngay sau xoay vòng, di chuyển hoặc thay đổi nhà cung cấp | Sao chép lại bản ghi hiện tại từ bảng điều khiển admin của người ký; ưu tiên ủy quyền CNAME |
| 4 | Sai hoặc thiếu selector | no key for signature — tra cứu bản thân thất bại | Xuất bản selector mà người ký thực sự dùng — xem hướng dẫn selector |
| 5 | Canonicalization mỏng manh hoặc thẻ l= | Lỗi không liên tục trên thư được định dạng lại không đáng kể | c=relaxed/relaxed; xóa l= hoàn toàn |
Nguyên nhân 1 được in đậm vì nó phá vỡ chữ ký trên các thư được ký hoàn hảo. Một gateway bảo mật thêm tuyên bố từ chối trách nhiệm, một footer tuân thủ được đóng dấu sau khi ký, một danh sách gửi thư thêm [listname] vào chủ đề — nội dung hoặc header đã ký thay đổi, các hash không còn khớp, và chữ ký không hợp lệ không phải do lỗi của DNS của bạn. Nếu lỗi tương quan với thư đã đi qua gateway, danh sách, hoặc hop lưu trữ, hãy bắt đầu từ đó.
Cách sửa “DKIM signature not valid”?
- 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 khóa được xuất bản của bạn có mặt, đúng định dạng và đầy đủ không — phân tách “DNS của bạn bị hỏng” (nguyên nhân 2–4) từ “DNS của bạn ổn, thư đang bị thay đổi” (nguyên nhân 1) chỉ trong một bước.
- Đọc header
Authentication-Resultscủa thư đang lỗi.body hash did not verify→ nguyên nhân 1, đến hướng dẫn body-hash — những nghi phạm thường là footer gateway và tuyên bố từ chối trách nhiệm, và cách sửa là ký sau sửa đổi.no key for signature→ nguyên nhân 4, đến hướng dẫn selector. Lỗi chữ ký đơn giản → tiếp tục. - Kiểm tra bản ghi khóa được xuất bản có bị cắt ngắn không. Tra cứu
<selector>._domainkey.<yourdomain>dưới dạng TXT (dig TXT selector._domainkey.example.com). Khóa công khai RSA 2048-bit dài hơn giới hạn 255 ký tự của một chuỗi TXT đơn, vì vậy nó phải được xuất bản dưới dạng nhiều chuỗi trích dẫn mà máy chủ nhận nối lại — và UI web của nhà cung cấp DNS nổi tiếng với việc lặng lẽ cắt ngắn khi dán, làm hỏng cách chia, hoặc chèn khoảng trắng và dấu ngoặc kép vào giá trịp=. So sánh từng ký tự với khóa người ký của bạn đã tạo; hướng dẫn cài đặt DKIM của chúng tôi bao gồm các quirk theo từng nhà cung cấp. - Xác nhận khóa được xuất bản khớp với người ký. Sau khi xoay vòng khóa, di chuyển nhà cung cấp, hoặc kết nối lại ESP, thường là người ký giữ khóa riêng mới trong khi DNS vẫn phục vụ khóa công khai cũ — mọi chữ ký đều xác minh theo khóa sai và lỗi. Sao chép lại bản ghi hiện tại từ bảng điều khiển admin của nhà cung cấp. Tốt hơn: khi nhà cung cấp cung cấp ủy quyền CNAME, hãy dùng nó — nhà cung cấp xoay vòng khóa về phía họ và toàn bộ loại lỗi này biến mất. Và không bao giờ xóa selector cũ cho đến khi lưu lượng được ký với nó đã được xử lý.
- Sửa cài đặt ký, không chỉ bản ghi. Đặt canonicalization thành
c=relaxed/relaxed, điều này chịu được việc re-wrap khoảng trắng và re-fold header mà các máy chủ trung gian thực hiện một cách hợp lệ; canonicalizationsimplethất bại trên các thay đổi mà con người không thể nhìn thấy. Và không dùng thẻl=body-length: nó được tạo ra để cho phép footer đi qua, nhưng nó cho phép bất kỳ ai thêm nội dung vào thư đã ký mà không phá vỡ chữ ký — một vectơ tấn công thực sự — và nó vẫn không tồn tại qua hầu hết các sửa đổi gateway. Không cól=vừa an toàn hơn vừa đáng tin cậy hơn. - Quét lại, sau đó kiểm tra căn chỉnh. Chữ ký hợp lệ chỉ giúp DMARC nếu tên miền
d=căn chỉnh với tên miền From — chữ ký xác thực làd=yourcompany.gappssmtp.comvượt qua DKIM và vẫn thất bại DMARC. Nếu đó là bạn, xem bẫy chữ ký mặc định, sau đó xử lý mọi thứ khác mà quét gắn cờ trên trang sửa DKIM.
Câu hỏi thường gặp
“DKIM signature not valid” có giống “body hash did not verify” không? Thông báo body-hash là một trường hợp con cụ thể: nội dung thay đổi sau khi ký (footer, tuyên bố từ chối trách nhiệm, viết lại danh sách). “Signature not valid” là kết quả bao quát cho bất kỳ xác minh thất bại nào, bao gồm khóa xấu và thay đổi header — đó là lý do bước 2 ở trên là đọc header, và tại sao trường hợp body-hash có hướng dẫn riêng.
Chữ ký DKIM không hợp lệ có nghĩa là thư của tôi bị từ chối không? Không phải tự nó — máy chủ nhận coi chữ ký bị hỏng như chữ ký bị thiếu. Thiệt hại đến qua DMARC: nếu SPF cũng không vượt qua với căn chỉnh, thư thất bại DMARC và chính sách được xuất bản của bạn áp dụng. Tính đến khảo sát 2026-06-29, chỉ 3.87% trong 261,086,232 tên miền được chấm điểm nắm giữ SPF, DKIM và chính sách DMARC thực thi cùng nhau — nhưng Gmail và Microsoft giờ mong đợi chính xác điều đó từ người gửi, vì vậy chân DKIM bị hỏng ảnh hưởng deliverability ngay cả trước khi bị từ chối.
Nên dùng khóa DKIM 1024-bit hay 2048-bit? 2048-bit — khóa 1024-bit dưới các khuyến nghị mật mã hiện tại và một số máy chủ nhận chấm điểm thấp hơn. Vấn đề hoàn toàn là vận hành: khóa 2048-bit không vừa trong một chuỗi TXT 255 ký tự, vì vậy nó phải được chia đúng cách (nguyên nhân 2 ở trên). Ủy quyền CNAME cho nhà cung cấp của bạn hoàn toàn bỏ qua vấn đề chia này.
DKIM của tôi vượt qua trên công cụ kiểm tra nhưng DMARC vẫn lỗi — tại sao?
Hầu như chắc chắn là căn chỉnh: chữ ký xác thực, nhưng tên miền d= của nó (ví dụ, yourcompany.gappssmtp.com hoặc yourtenant.onmicrosoft.com) không khớp với tên miền From, vì vậy DMARC không thể sử dụng nó. Bật ký tên miền tùy chỉnh của nhà cung cấp — hướng dẫn đầy đủ nằm trong hướng dẫn bẫy chữ ký mặc định.
Có thể tắt DKIM nếu nó tiếp tục lỗi không? Không — kể từ các quy định người gửi khối lượng lớn năm 2024, Gmail và Yahoo yêu cầu DKIM cho người gửi khối lượng, và chính sách DMARC thực thi thực tế cần DKIM vì SPF một mình hỏng dưới chuyển tiếp. Hãy sửa chữ ký; các nguyên nhân trên đều có thể sửa trong một buổi chiều.
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 các thay đổi của bạn 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, DKIM hiển thị màu xanh. Đây 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 — sự khác biệt giữa “tôi đã sửa một thứ DNS” và tài liệu trước-và-sau được ghi lại nói rằng tên miền xác thực thư của nó.
Kiểm tra tên miền → · Hướng dẫn “Body hash did not verify” → · 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.