DKIM 'Body Hash Did Not Verify' — อะไรเปลี่ยนข้อความของคุณ และวิธีแก้ไข (2026)

เผยแพร่ 2026-07-08

ตัวเลข ณ วันที่ 2026-06-29 · ระเบียบวิธี v7 ข้อมูลสำมะโนรวมทั่ว 261 ล้านโดเมนที่ได้รับการให้คะแนน ดู วิธีที่เราให้คะแนน

“Body hash did not verify” หมายความว่าลายเซ็น DKIM ของคุณถูกต้องเมื่อข้อความออกไปจากคุณ — และบางอย่างเขียนทับเนื้อหาข้อความในภายหลัง ลายเซ็นไม่ได้พัง ข้อความถูกแก้ไขระหว่างการส่ง มีเพียง 3.87% ของโดเมน — 10,092,481 — ที่ครบ triad SPF-DKIM-DMARC ตามสำมะโน Defaults.Exposed ของ 261,086,232 โดเมน (2026-06-29)

การแก้ไขคือการล่าหา แล้วตัดสินใจ ค้นหา hop ที่แก้ไขอีเมลของคุณ — gateway ที่ผนวก disclaimer อุปกรณ์ที่เขียนลิงก์ใหม่ รายการส่งจดหมายที่เพิ่ม footer จากนั้นลงนาม หลังจาก hop นั้น หยุดการแก้ไข หรือทำให้ลายเซ็นทนทานต่อมัน — ตามลำดับนั้น

”Body hash did not verify” หมายความว่าอะไรจริงๆ?

ลายเซ็น DKIM (RFC 6376) มีแฮชสองรายการ: bh= แฮชของ เนื้อหา ข้อความที่ลงนาม และ b= ที่ลงนามส่วนหัวบวกแฮชเนื้อหานั้น ผู้ตรวจสอบคำนวณแฮชเนื้อหาใหม่จากข้อความที่ได้รับ ถ้าไม่ตรงกับ bh= การตรวจสอบหยุดด้วยสตริงที่ทุกคนวางลงในช่องค้นหา — ส่วนหัวผู้รับเช่น:

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

นั่นคือสตริงเหตุผลที่บันทึกไว้ของ Microsoft Gmail มักแสดงการวินิจฉัยเดียวกันว่า dkim=neutral (body hash did not verify) ไม่ว่าจะเป็นแบบใด ข้อสรุปจำกัดปัญหาอย่างมาก DNS key, selector และการกำหนดค่าการลงนามของคุณทั้งหมดดี การเข้ารหัสทำงานของมัน: เนื้อหาเปลี่ยนระหว่างการลงนามและการตรวจสอบ — บรรทัดที่ผนวกหนึ่งบรรทัด URL ที่เขียนใหม่หนึ่งรายการ อักขระที่เข้ารหัสใหม่หนึ่งตัวก็เพียงพอ (ข้อความที่แตกต่างกัน — signature did not verify, no key for signature — หมายถึงความล้มเหลวที่แตกต่างกัน เริ่มด้วย “ลายเซ็น DKIM ไม่ถูกต้อง”) และมันเร่งด่วนเพราะลายเซ็นที่ล้มเหลวไม่สามารถให้ DMARC ผ่านด้วยการจัดตำแหน่ง: เว้นแต่ SPF ผ่าน ด้วยการจัดตำแหน่ง บนข้อความเดียวกัน อีเมลจะล้มเหลว DMARC โดยตรง

อะไรเปลี่ยนข้อความของคุณ? ผู้ต้องสงสัยปกติ

บางสิ่งในเส้นทางการส่งแก้ไขเนื้อหาหลังจาก signer ของคุณปิดผนึกมัน ในทางปฏิบัติเป็นหนึ่งในสี่สิ่ง:

ใครแก้ไขมัน	สิ่งที่พวกเขาเปลี่ยน	เบาะแสทั่วไป
Outbound gateway / smart host (Exchange transport rules, Mimecast, Proofpoint, Barracuda…)	ผนวก legal disclaimer, marketing footer หรือแบนเนอร์ “EXTERNAL:” หลังจาก mail server ลงนามแล้ว	ทุกข้อความบนเส้นทางนั้นล้มเหลว การส่งโดยตรงที่ข้าม gateway ผ่าน
อุปกรณ์รักษาความปลอดภัย / link protection	เขียน URL ใหม่เป็น redirect การสแกน เพิ่ม tracking wrapper	เฉพาะข้อความที่มีลิงก์ล้มเหลว
รายการส่งจดหมาย (Google Groups, Mailman…)	เพิ่มแท็กหัวข้อและ footer รายการ บางครั้ง reflow เนื้อหา	เฉพาะอีเมลที่ส่ง ผ่านรายการ ล้มเหลว
Forwarder / relay re-encoding MIME	แปลง charset, re-wrap บรรทัด — มองไม่เห็นสำหรับมนุษย์ ร้ายแรงต่อแฮช	ความล้มเหลวรวมกลุ่มที่ผู้รับรายหนึ่งหรือที่อยู่สำหรับส่งต่อ

ตรวจสอบแถวที่ตัวหนาก่อน — mail server ลงนาม อุปกรณ์ขอบแก้ไข และทุกข้อความออกไปพร้อมลายเซ็นที่ถูกต้องสำหรับสามสิบมิลลิวินาที

ฉันจะค้นหา hop ที่แก้ไขอีเมลของฉันได้อย่างไร?

การวินิจฉัยเชิงอนุพันธ์ — เปรียบเทียบเส้นทางที่ใช้งานได้กับเส้นทางที่ล้มเหลว:

ส่งข้อความทดสอบ โดยตรง ไปยังกล่องจดหมายที่คุณควบคุมที่ผู้รับหลัก (Gmail ทำงานได้ดี) โดยข้าม chain ขาออกของคุณมากที่สุดเท่าที่ทำได้
ส่งข้อความที่สองตาม เส้นทางที่ล้มเหลว — ผ่าน gateway ผ่านรายการ ไปยังโดเมนผู้รับที่ได้รับผลกระทบ
เปรียบเทียบบรรทัด Authentication-Results ในส่วนหัวทั้งหมดทั้งคู่ การส่งโดยตรง dkim=pass เส้นทางที่ล้มเหลว dkim=fail (หรือ dkim=neutral) พร้อม body hash did not verify: ตัวแก้ไขอยู่ระหว่างสองเส้นทางนั้น
ดูเนื้อหาที่ได้รับ: disclaimer, แบนเนอร์ หรือ footer ที่คุณไม่ได้พิมพ์? ลิงก์ที่เขียนใหม่เป็นโดเมนสแกนนิ่ง? นั่นคือ hop ของคุณ มีชื่อ — และ chain Received: แสดงว่า relay ใดปรากฏเฉพาะในเส้นทางที่ล้มเหลว

รายงานรวม DMARC ของคุณบอกเรื่องเดียวกันในขนาด: แหล่งที่รายงาน DKIM fail กับ SPF pass อย่างสม่ำเสมอมักเป็นการแก้ไขระหว่างการส่งบนเส้นทางของคุณเอง ไม่ใช่ผู้โจมตี

ฉันจะแก้ไขมันได้อย่างไร?

สแกนฟรีที่ defaults.exposed ก่อนแตะอะไรเลย ยืนยันว่า DKIM key และนโยบาย DMARC ที่เผยแพร่ของคุณถูกต้อง เพื่อให้คุณแก้ไขปัญหาจริงหนึ่งอย่าง — การแก้ไข — ไม่ใช่ไล่ผีใน DNS หน้า แก้ DKIM ครอบคลุมการตรวจสอบด้านระเบียน
ลงนามหลังจาก hop ที่แก้ไข การแก้ไขที่ถูกต้องทางสถาปัตยกรรม: ย้ายการลงนาม DKIM ไปยังอุปกรณ์ที่อยู่นอกสุดที่แตะข้อความ ร้านค้า Exchange-plus-gateway ควรลงนามที่ gateway (Mimecast, Proofpoint และเพื่อนรองรับทั้งหมด) และปิดการลงนามต้นน้ำ หาก Google Workspace หรือ Microsoft 365 เป็น hop สุดท้ายของคุณ ลงนามที่นั่นและอย่าให้อะไรแก้ไขอีเมลหลังจากนั้น — ดู ตั้งค่า DKIM บน Google Workspace หรือ Microsoft 365
หรือหยุดการแก้ไข นำการแก้ไขออกจากเส้นทางการขนส่ง: disclaimer ในลายเซ็น client หรือเทมเพลตแทน transport rule แบนเนอร์ “EXTERNAL:” กำหนดขอบเขตสำหรับอีเมลขาเข้าเท่านั้น (การติดแท็กอีเมลขาออกของคุณเองว่าเป็นภายนอกเป็นการกำหนดค่าผิดพลาดสองครั้ง); อีเมลขาออกที่ผ่านการยืนยันตัวตนยกเว้นจากการเขียนลิงก์ใหม่
ใช้ relaxed/relaxed canonicalization (c=relaxed/relaxed) simple body canonicalization ล้มเหลวบนบรรทัดที่ wrap ใหม่หนึ่งบรรทัด relaxed ทนต่อการเปลี่ยนแปลง whitespace และ line-ending ซื่อสัตย์เกี่ยวกับขีดจำกัด: relaxed ยกโทษ การจัดรูปแบบ ไม่ใช่ เนื้อหา — footer ที่ผนวกยังคงล้มเหลว ตามที่ควรจะเป็น
ทดสอบทั้งสองเส้นทางใหม่ จากนั้นสแกนใหม่ ทั้งสองเส้นทางควรแสดง dkim=pass พร้อมโดเมนของคุณใน d= และรายงานการสแกนควรสะอาด

ฉันควรใช้แท็ก l= เพื่อให้ DKIM ละเว้นเนื้อหาที่ผนวกหรือไม่?

ไม่ — และระวังคู่มือใดก็ตามที่แนะนำมัน แท็ก l= แฮชเฉพาะ N ไบต์แรกของเนื้อหา ดังนั้น footer ที่ผนวกจะไม่ทำลายลายเซ็นอีกต่อไป มัน “ทำงานได้” โดยทิ้งส่วนท้ายของข้อความของคุณ ไว้โดยไม่ลงนาม: ใครก็ตามที่ถือข้อความที่ลงนามอย่างถูกต้องสามารถผนวกเนื้อหาใดๆ และลายเซ็นที่ถูกต้องของคุณยังคงตรวจสอบกับผลลัพธ์ นั่นคือช่องโหว่การปลอมแปลงที่สวมใส่เสื้อผ้าของการแก้ไข — การละเมิดในทางปฏิบัติได้รับการแสดงให้เห็น และผู้รับบางรายลงโทษหรือเพิกเฉย l= ด้วยเหตุผลนี้เอง แก้การแก้ไข อย่า unsign บางส่วนของอีเมลของคุณ

แล้วรายการส่งจดหมาย — ฉันสามารถแก้ไขได้ไหม?

ส่วนใหญ่ไม่ — และการรู้เรื่องนี้ช่วยประหยัดเวลาหลายสัปดาห์ รายการที่เพิ่มแท็กหัวข้อหรือ footer ทำลายแฮชเนื้อหาของคุณโดยการออกแบบ และคุณไม่ได้ควบคุมรายการ สองสิ่งช่วยได้:

สิ่งที่เหลือนี้คือเหตุผลที่การ rollout DMARC เป็นขั้นตอน การย้ายจาก p=none ผ่าน p=quarantine ด้วยการ ramp pct= ขณะอ่านรายงานรวม หมายความว่าข้อความที่รายการบิดเบือนถูก quarantine แทนที่จะถูกทำลายขณะที่คุณประเมินผลกระทบ — หัวข้อของ จาก p=none ถึง p=reject โดยไม่สูญเสียอีเมลที่ถูกต้อง
ARC เป็นกลไกของผู้รับ ไม่ใช่ของคุณ Authenticated Received Chain ให้ รายการ รับรองว่าการยืนยันตัวตนมีหน้าตาอย่างไรเมื่อมาถึงและ ผู้รับ ตัดสินใจว่าจะเชื่อถือมันหรือไม่ ไม่มีอะไรสำหรับคุณ ผู้ส่ง ที่จะกำหนดค่า รายการที่บริหารจัดการดีลดโดย rewriting ส่วนหัว From รายการที่บริหารจัดการไม่ดีแค่ทำลายอีเมลของคุณ

การส่งต่อเป็นกรณีที่อยู่ติดกัน — มันทำลาย SPF อย่างน่าเชื่อถือแต่ DKIM เป็นครั้งคราวเท่านั้น ซึ่งเป็นเหตุผลที่ DKIM ที่จัดตำแหน่งเป็นขาที่ทนต่อการส่งต่อของคุณเมื่อเนื้อหารอดชีวิต: ดู อีเมลที่ส่งต่อล้มเหลว SPF — ทำไมคุณไม่สามารถแก้ไขมันได้

ทำไม DKIM ถึงพังบ่อยเมื่อโดเมนน้อยมากที่มีสแต็กเต็มรูปแบบ?

เพราะ DKIM คือลูกกลางที่เปราะบางของ triad: SPF เป็นระเบียน DNS แบบ static DMARC เป็นคำแถลงนโยบาย แต่ DKIM ต้องรอด การเดินทาง มีเพียง 51.84% ของโดเมนที่ได้รับการให้คะแนนที่เผยแพร่ DKIM key ที่ค้นพบได้ใน DNS เลย ตามสำมะโน Defaults.Exposed และมีเพียง 10,092,481 โดเมน — 3.87% ของ 261,086,232 ที่ให้คะแนน — ที่ถือ SPF, DKIM และนโยบาย DMARC ที่บังคับใช้ร่วมกัน (แบบจำลองความสมบูรณ์การนำ SPF ไปใช้ แบ่งบันไดออก) การทำให้การแก้ไขนี้ถูกต้องเป็นส่วนที่ยากที่สุดในการเข้าร่วม 3.87% นั้น

คำถามที่พบบ่อย

“Body hash did not verify” เป็นสัญญาณว่ามีคนปลอมแปลงโดเมนของฉันหรือไม่? โดยปกติไม่ — นักปลอมแปลงมักไม่สามารถสร้างลายเซ็น DKIM ของคุณได้เลย ดังนั้นอีเมลของพวกเขาจะแสดงไม่มีลายเซ็นหรือ no key แฮชเนื้อหาที่ล้มเหลวหมายความว่าข้อความที่ลงนามจริงโดยโครงสร้างพื้นฐานของคุณถูกแก้ไขในภายหลัง ตรวจสอบ gateway ของคุณเองก่อนสรุปว่าเป็นผู้โจมตี

SPF ผ่านบนข้อความเหล่านี้ — ฉันยังโอเคอยู่ไหม? ตอนนี้อาจจะ: DMARC ต้องการเพียง pass ที่จัดตำแหน่งหนึ่งรายการ แต่ pass ของ SPF หายไปในทันทีที่ใครส่งต่อข้อความ และถ้ามันไม่จัดตำแหน่งกับโดเมน From ของคุณ มันไม่เคยนับสำหรับ DMARC ด้วยเพียง 3.87% ของโดเมนที่ถือ triad เต็มรูปแบบ (สำมะโน 2026-06-29 ของ 261,086,232 โดเมน) “ขาหนึ่งเดินกะเผลก” คือสถานะปกติ — และเป็นสถานะที่แก้ไขได้

การเปลี่ยนไปใช้ relaxed/relaxed canonicalization จะแก้ไขปัญหา disclaimer ของฉันไหม? ไม่ Relaxed ทนต่อการเปลี่ยน whitespace และ line-wrapping เท่านั้น disclaimer ที่ผนวกเป็นการเปลี่ยนเนื้อหา และแฮชต้องล้มเหลวบนมัน — นั่นคือ DKIM ทำงานอย่างถูกต้อง ย้ายจุดลงนามหรือย้าย disclaimer

ความล้มเหลวเกิดขึ้นเฉพาะกับโดเมนของลูกค้าหนึ่งราย ทำไม? ฝั่งของพวกเขาเกือบแน่นอนแก้ไขอีเมลขาเข้า — อุปกรณ์รักษาความปลอดภัยที่เขียนลิงก์ใหม่หรือประทับแบนเนอร์ ก่อน ที่ผู้ตรวจสอบของพวกเขาทำงาน หรือการส่งต่อภายในที่เข้ารหัสเนื้อหาใหม่ ส่งให้พวกเขาส่วนการวินิจฉัยของหน้านี้ การแก้ไขอยู่ที่ gateway ของพวกเขา ไม่ใช่ใน DNS ของคุณ

ส่งรายงานให้เจ้าของ

หากคุณแก้ไขปัญหานี้สำหรับลูกค้าหรือนายจ้างของคุณ ปิดลูปด้วยหลักฐาน เมื่อแก้ไข hop ที่แก้ไขแล้ว รันใหม่ การสแกนฟรี และส่งต่อรายงานที่ได้รับการให้คะแนนให้เจ้าของธุรกิจ: มีวันที่ ภาษาธรรมดา DKIM และ DMARC ยืนอยู่บนหน้าเดียว มันคือสิ่งประดิษฐ์ที่พวกเขาต้องการสำหรับการต่ออายุประกันภัยไซเบอร์และแบบสอบถามผู้จัดหาถัดไป — หลักฐานว่าอีเมลที่ออกจากบริษัทเป็นอีเมลที่มาถึง

ตรวจสอบโดเมนของคุณ → · คู่มือ “ลายเซ็น DKIM ไม่ถูกต้อง” → · แก้ DKIM → · วิธีที่เราให้คะแนน → · ข้อมูลรวมเท่านั้น ข้อมูลถูกจัดเก็บและประมวลผลในสหภาพยุโรป