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

DKIM 'Body Hash Did Not Verify' — Điều Gì Đã Thay Đổi Thư Của Bạn, Và Cách Sửa (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.

“Body hash did not verify” có nghĩa là chữ ký DKIM của bạn hợp lệ khi thư rời khỏi bạn — và có gì đó đã viết lại nội dung thư sau đó. Chữ ký không bị hỏng; thư đã bị sửa đổi trong quá trình truyền. Chỉ 3.87% tên miền — 10,092,481 — hoàn thành bộ ba SPF-DKIM-DMARC đầy đủ, theo dữ liệu khảo sát 261,086,232 tên miền của Defaults.Exposed (2026-06-29).

Cách sửa là một cuộc điều tra, rồi là một quyết định. Tìm hop sửa đổi thư của bạn — gateway thêm tuyên bố từ chối trách nhiệm, thiết bị viết lại liên kết, danh sách gửi thư thêm footer. Sau đó ký sau hop đó, ngừng sửa đổi, hoặc làm cho chữ ký chịu đựng được nó — theo thứ tự đó.

”Body hash did not verify” thực sự có nghĩa là gì?

Chữ ký DKIM (RFC 6376) mang hai hash: bh=, hash của nội dung thư khi được ký, và b=, ký các header cộng hash nội dung đó. Trình xác minh tính lại hash nội dung từ thư nó nhận được; nếu không khớp bh=, xác minh dừng lại với chuỗi mà mọi người dán vào hộp tìm kiếm — header máy chủ nhận như:

Authentication-Results: …; dkim=fail (body hash did not verify)

Đó là chuỗi lý do được ghi lại của Microsoft; 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, kết quả thu hẹp vấn đề rất nhiều. Khóa DNS, selector và cấu hình ký của bạn đều ổn. Mật mã đã làm đúng việc của nó: nội dung đã thay đổi giữa khi ký và khi xác minh — một dòng được thêm vào, một URL bị viết lại, một ký tự được mã hóa lại là đủ. (Một thông báo khác — signature did not verify, no key for signature — có nghĩa là lỗi khác; bắt đầu với “DKIM signature not valid”.) Và nó cấp bách vì chữ ký bị lỗi không thể cung cấp cho DMARC kết quả căn chỉnh: trừ khi SPF vượt qua với căn chỉnh trên cùng thư, thư thất bại DMARC hoàn toàn.

Điều gì đã thay đổi thư của bạn? Những nghi phạm thường gặp

Có gì đó trong đường dẫn gửi đã chỉnh sửa nội dung sau khi người ký của bạn niêm phong nó. Trong thực tế thường là một trong bốn điều:

Ai đã sửa đổi	Họ thay đổi gì	Dấu hiệu nhận biết thường gặp
Gateway gửi đi / smart host (Exchange transport rules, Mimecast, Proofpoint, Barracuda…)	Thêm tuyên bố từ chối trách nhiệm pháp lý, footer marketing, hoặc banner “EXTERNAL:” sau khi máy chủ thư đã ký	Mọi thư trên tuyến đó đều lỗi; gửi trực tiếp bỏ qua gateway thì vượt qua
Thiết bị bảo mật / bảo vệ liên kết	Viết lại URL thành chuyển hướng quét, thêm wrapper theo dõi	Chỉ thư chứa liên kết mới lỗi
Danh sách gửi thư (Google Groups, Mailman…)	Thêm thẻ chủ đề và footer danh sách, đôi khi định dạng lại nội dung	Chỉ thư gửi qua danh sách mới lỗi
Bộ chuyển tiếp / relay mã hóa lại MIME	Chuyển đổi charset, re-wrap dòng — vô hình với người, chết người đối với hash	Lỗi tập trung ở một người nhận hoặc địa chỉ chuyển tiếp

Kiểm tra hàng in đậm trước — máy chủ thư ký, thiết bị edge chỉnh sửa, và mọi thư rời đi với chữ ký đúng được ba mươi mili giây.

Làm thế nào để tìm hop đang sửa đổi thư của tôi?

Chẩn đoán vi phân — so sánh đường dẫn hoạt động với đường dẫn lỗi:

Gửi thư kiểm tra trực tiếp đến hộp thư bạn kiểm soát tại máy chủ nhận lớn (Gmail hoạt động tốt), bỏ qua càng nhiều chuỗi gửi đi của bạn càng tốt.
Gửi thư thứ hai dọc theo đường dẫn lỗi — qua gateway, qua danh sách, đến tên miền của người nhận bị ảnh hưởng.
So sánh các dòng Authentication-Results trong cả hai header đầy đủ. Gửi trực tiếp dkim=pass, đường dẫn lỗi dkim=fail (hoặc dkim=neutral) với body hash did not verify: người sửa đổi nằm giữa hai tuyến đó.
Nhìn vào nội dung nhận: một tuyên bố từ chối trách nhiệm, banner hoặc footer mà bạn không gõ? Liên kết bị viết lại thành tên miền quét? Đó là hop của bạn, được đặt tên — và chuỗi Received: cho thấy relay nào chỉ xuất hiện trong đường dẫn lỗi.

Báo cáo DMARC tổng hợp của bạn kể cùng câu chuyện ở quy mô lớn: một nguồn liên tục báo cáo DKIM lỗi với SPF vượt qua thường là sửa đổi trong quá trình truyền trên tuyến của chính bạn, không phải kẻ tấn công.

Cách sửa?

Chạy quét miễn phí tại defaults.exposed trước khi chạm vào bất cứ thứ gì. Nó xác nhận khóa DKIM được xuất bản và chính sách DMARC của bạn ổn, vì vậy bạn đang gỡ lỗi một vấn đề thực sự — sửa đổi — không phải đuổi theo bóng ma trong DNS. Trang sửa DKIM bao gồm các kiểm tra phía bản ghi.
Ký sau hop đang sửa đổi. Cách sửa đúng về kiến trúc: chuyển ký DKIM sang thiết bị ngoài cùng chạm vào thư. Cửa hàng Exchange-plus-gateway nên ký tại gateway (Mimecast, Proofpoint và các bên ngang hàng đều hỗ trợ) và vô hiệu hóa ký phía trên. Nếu Google Workspace hoặc Microsoft 365 là hop cuối cùng của bạn, ký ở đó và không để gì chỉnh sửa thư sau nó — xem cài đặt DKIM trên Google Workspace hoặc Microsoft 365.
Hoặc ngừng sửa đổi. Lấy chỉnh sửa ra khỏi đường dẫn vận chuyển: tuyên bố từ chối trách nhiệm trong chữ ký máy khách hoặc template thay vì transport rule; banner “EXTERNAL:” giới hạn chỉ cho thư đến (gắn thẻ thư gửi đi của chính bạn là external là lỗi cấu hình hai lần); thư gửi đi đã xác thực được miễn khỏi viết lại liên kết.
Dùng canonicalization relaxed/relaxed (c=relaxed/relaxed). Canonicalization nội dung simple thất bại trên một dòng re-wrap đơn; relaxed chịu được thay đổi khoảng trắng và kết thúc dòng. Hãy thành thật về giới hạn: relaxed tha thứ định dạng, không bao giờ nội dung — một footer được thêm vào vẫn lỗi, và nên như vậy.
Kiểm tra lại cả hai đường dẫn, rồi quét lại. Cả hai tuyến bây giờ nên hiển thị dkim=pass với tên miền của bạn trong d=, và báo cáo quét nên sạch.

Có nên dùng thẻ l= để DKIM bỏ qua nội dung được thêm vào không?

Không — và hãy nghi ngờ bất kỳ hướng dẫn nào gợi ý điều đó. Thẻ l= chỉ hash N byte đầu tiên của nội dung, vì vậy footer được thêm vào không còn phá vỡ chữ ký. Nó “hoạt động” bằng cách để phần cuối thư không được ký: bất kỳ ai giữ thư đã ký hợp lệ đều có thể thêm nội dung tùy ý và chữ ký hợp lệ của bạn vẫn xác minh được trên kết quả. Đó là lỗ hổng giả mạo mặc đồ quần áo của cách sửa — lạm dụng thực tế đã được chứng minh, và một số máy chủ nhận phạt hoặc bỏ qua l= chính xác vì lý do này. Hãy giải quyết sửa đổi; đừng bỏ ký một phần thư của bạn.

Còn danh sách gửi thư — có thể sửa những cái đó không?

Hầu như không thể — và biết điều đó tiết kiệm cho bạn nhiều tuần. Danh sách thêm thẻ chủ đề hoặc footer phá vỡ hash nội dung của bạn theo thiết kế, và bạn không kiểm soát danh sách. Hai điều giúp ích:

Phần dư này chính xác là lý do triển khai DMARC được chia giai đoạn. Chuyển từ p=none qua p=quarantine với ramp pct=, trong khi đọc báo cáo tổng hợp, có nghĩa là thư bị làm hỏng bởi danh sách bị quarantine thay vì bị hủy trong khi bạn đánh giá tác động — chủ đề của từ p=none đến p=reject không mất email hợp lệ.
ARC là cơ chế của máy chủ nhận, không phải của bạn. Authenticated Received Chain cho phép danh sách chứng nhận xác thực trông như thế nào khi đến và máy chủ nhận quyết định có tin tưởng nó không. Không có gì để bạn, người gửi, cấu hình. Các danh sách được quản lý tốt giảm thiểu bằng cách viết lại header From; các danh sách quản lý kém chỉ đơn giản là phá vỡ thư của bạn.

Chuyển tiếp là trường hợp liền kề — nó đáng tin cậy phá vỡ SPF nhưng chỉ đôi khi DKIM, đó là lý do DKIM căn chỉnh là chân chống chuyển tiếp của bạn khi nội dung sống sót: xem email chuyển tiếp lỗi SPF — tại sao bạn không thể sửa.

Tại sao DKIM thường xuyên hỏng khi quá ít tên miền thậm chí có toàn bộ stack?

Vì DKIM là đứa con giữa mỏng manh của bộ ba: SPF là bản ghi DNS tĩnh, DMARC là tuyên bố chính sách, nhưng DKIM phải sống sót qua hành trình. 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ỉ 10,092,481 tên miền — 3.87% trong 261,086,232 được chấm điểm — nắm giữ SPF, DKIM và chính sách DMARC thực thi cùng nhau (mô hình trưởng thành áp dụng SPF phân tích thang bậc). Sửa đúng điều này là phần khó nhất để gia nhập nhóm 3.87% đó.

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

“Body hash did not verify” có phải dấu hiệu ai đó đang giả mạo tên miền của tôi không? Thường không — kẻ giả mạo thường không thể tạo chữ ký DKIM của bạn chút nào, vì vậy thư của họ hiển thị không có chữ ký hoặc no key. Hash nội dung bị lỗi có nghĩa là thư thực sự được ký bởi hạ tầng của bạn đã bị chỉnh sửa sau đó. Kiểm tra gateway của chính bạn trước khi cho rằng có kẻ tấn công.

SPF vượt qua trên những thư này — tôi có ổn không? Có thể, hiện tại: DMARC chỉ cần một kết quả căn chỉnh. Nhưng kết quả SPF vượt qua biến mất ngay khi ai đó chuyển tiếp thư, và nếu nó không căn chỉnh với tên miền From thì nó không bao giờ tính cho DMARC. Với chỉ 3.87% tên miền nắm giữ bộ ba đầy đủ (khảo sát 2026-06-29 của 261,086,232 tên miền), “một chân bị tập tễnh” là trạng thái bình thường — và là cái có thể sửa được.

Chuyển sang canonicalization relaxed/relaxed có sửa được vấn đề tuyên bố từ chối trách nhiệm không? Không. Relaxed chỉ chịu được thay đổi khoảng trắng và re-wrap dòng. Tuyên bố từ chối trách nhiệm được thêm vào là thay đổi nội dung, và hash phải lỗi với nó — đó là DKIM hoạt động đúng. Hãy chuyển điểm ký hoặc chuyển tuyên bố từ chối trách nhiệm.

Lỗi chỉ xảy ra với tên miền của một khách hàng. Tại sao? Phía của họ hầu như chắc chắn sửa đổi thư đến — một thiết bị bảo mật viết lại liên kết hoặc đóng dấu banner trước khi trình xác minh của họ chạy, hoặc một forward nội bộ mã hóa lại nội dung. Gửi cho họ phần chẩn đoán của trang này; cách sửa nằm ở gateway của họ, không phải trong DNS của bạn.

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 hop đang sửa đổi đã được sửa, 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, DKIM và DMARC đứng vững trên một trang. Đâ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 nhà cung cấp tiếp theo — bằng chứng rằng thư rời khỏi công ty giờ đây là thư đến nơi.

Kiểm tra tên miền → · Hướng dẫn “DKIM signature not valid” → · 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.