Defaults.Exposed › การแก้ไข › Guides

'ลายเซ็น DKIM ไม่ถูกต้อง' — สาเหตุ เรียงตามลำดับที่ควรตรวจสอบ (2026)

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

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

“ลายเซ็น DKIM ไม่ถูกต้อง” มีสาเหตุทั่วไปห้าประการ ที่ควรตรวจสอบตามลำดับ: เนื้อหาที่ถูกแก้ไขระหว่างส่ง, ระเบียน key ที่ถูกตัดทอน, key ที่เผยแพร่ไม่ตรงกับ signer, selector ที่ผิด, และ canonicalization ที่เปราะบาง มีเพียง 10,092,481 ของ 261,086,232 โดเมนที่ได้รับการให้คะแนน (3.87%) ที่มี triad SPF + DKIM + DMARC ที่บังคับใช้ครบ ตามสำมะโน Defaults.Exposed (2026-06-29)

ลำดับการแก้ไขมีความสำคัญเพราะสาเหตุที่พบบ่อยที่สุดไม่ได้อยู่ใน DNS ของคุณเลย ตรวจสอบว่าอะไรเปลี่ยนแปลงข้อความระหว่างส่งก่อน จากนั้นทำงานเข้าด้านใน: ความสมบูรณ์ของระเบียน key, ว่ามันตรงกับสิ่งที่เซิร์ฟเวอร์อีเมลของคุณลงนามจริงๆ หรือไม่, selector, และสุดท้ายการตั้งค่าการลงนาม ลายเซ็นที่ไม่ถูกต้องส่วนใหญ่ถูกแก้ไขที่ขั้นตอนหนึ่งหรือสอง

”ลายเซ็น DKIM ไม่ถูกต้อง” หมายความว่าอะไรจริงๆ?

ทุกข้อความที่ลงนาม DKIM มี header DKIM-Signature ที่ระบุโดเมน (d=), selector (s=), hash ของ body ข้อความ (bh=), และลายเซ็นการเข้ารหัสลับเหนือ body hash บวก header ที่เลือก (b=) ผู้รับดึง key สาธารณะของคุณจาก DNS ที่ <selector>._domainkey.<domain>, คำนวณ hash ทั้งสองใหม่, และตรวจสอบลายเซ็น (RFC 6376) “ลายเซ็นไม่ถูกต้อง” คือภาษาของตัวตรวจสอบและ header สำหรับ: การตรวจสอบนั้นทำงานและล้มเหลว — พบ key แต่คณิตศาสตร์ไม่ผ่าน

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

การทำให้ถูกต้องนั้นหายาก: มีเพียง 51.84% ของโดเมนที่ได้รับการให้คะแนนที่เผยแพร่ DKIM key ที่ค้นพบได้ใน DNS เลย ตามสำมะโน Defaults.Exposed และมีเพียง 3.87% ของ 261 ล้านโดเมนที่ได้รับการให้คะแนนที่รวม SPF, DKIM และนโยบาย DMARC ที่บังคับใช้ — การกำหนดค่าที่กฎ bulk-sender ตอนนี้ถือว่าเป็นเรื่องปกติ ภาพแบบแยกตามขั้นตอนอยู่ใน โมเดลวุฒิภาวะการยอมรับ SPF

สาเหตุทั้งห้าประการตามลำดับมีอะไรบ้าง?

สาเหตุ 1 ถูกทำตัวหนาเพราะมันทำลายลายเซ็นบนข้อความที่ถูกลงนามอย่างสมบูรณ์ gateway ความปลอดภัยต่อท้าย disclaimer, footer การปฏิบัติตามกฎระเบียบถูกประทับหลังจากการลงนาม, mailing list เพิ่ม [listname] ไปยังหัวเรื่อง — body หรือ header ที่ลงนามเปลี่ยน, hash ไม่ตรงอีกต่อไป, และลายเซ็นไม่ถูกต้องโดยไม่ใช่ความผิดของ DNS ของคุณ หากความล้มเหลวสอดคล้องกับอีเมลที่ผ่าน gateway, รายการ, หรือการส่งต่อ ให้เริ่มที่นั่น

ฉันจะแก้ไข “ลายเซ็น DKIM ไม่ถูกต้อง” ได้อย่างไร?

1. สแกนฟรีที่ defaults.exposed ก่อนแตะ DNS มันแสดงว่าระเบียน key ที่เผยแพร่ของคุณมีอยู่ มีรูปแบบถูกต้อง และสมบูรณ์หรือไม่ — แยก “DNS ของคุณเสีย” (สาเหตุ 2–4) ออกจาก “DNS ของคุณดี ข้อความกำลังถูกเปลี่ยน” (สาเหตุ 1) ในขั้นตอนเดียว
2. อ่าน header Authentication-Results ของข้อความที่ล้มเหลว body hash did not verify → สาเหตุ 1 ไปที่ คู่มือ body-hash — ผู้ต้องสงสัยทั่วไปคือ footer gateway และ disclaimer, และการแก้ไขคือการลงนามหลังการแก้ไข no key for signature → สาเหตุ 4 ไปที่ คู่มือ selector ความล้มเหลวของลายเซ็นธรรมดา → ดำเนินการต่อ
3. ตรวจสอบ key ที่เผยแพร่ว่าถูกตัดทอนหรือไม่ ค้นหา <selector>._domainkey.<yourdomain> เป็น TXT (dig TXT selector._domainkey.example.com) RSA public key ขนาด 2048-bit ยาวกว่าขีดจำกัด 255 ตัวอักษรของ TXT string เดียว ดังนั้นจึงต้องเผยแพร่เป็น quoted string หลายตัวที่ผู้รับต่อกัน — และ UI web ของ DNS provider เป็นที่รู้จักกันดีว่าตัดทอน paste อย่างเงียบๆ, ทำให้การแยก เสียหาย, หรือฉีดช่องว่างและ quote เข้าไปในค่า p= เปรียบเทียบตัวอักษรต่อตัวอักษรกับ key ที่ signer ของคุณสร้าง; คำแนะนำการตั้งค่า DKIM ของเราครอบคลุม quirk ต่อผู้ให้บริการ
4. ยืนยันว่า key ที่เผยแพร่ตรงกับ signer หลังจากการหมุน key, การย้ายระบบผู้ให้บริการ, หรือการเชื่อมต่อ ESP ใหม่ มันเป็นเรื่องปกติที่ signer จะถือ private key ใหม่ในขณะที่ DNS ยังคงให้บริการ public key เก่า — ทุกลายเซ็นตรวจสอบกับ key ที่ผิดและล้มเหลว Copy ระเบียนปัจจุบันจาก console ของผู้ให้บริการใหม่ ดีกว่า: ที่ผู้ให้บริการเสนอ การมอบหมาย CNAME ให้ใช้มัน — ผู้ให้บริการหมุน key ในด้านของพวกเขาและความล้มเหลวทั้งคลาสนี้หายไป และอย่าลบ selector เก่าจนกว่า traffic ที่ลงนามด้วยมันจะหมด
5. แก้ไขการตั้งค่าการลงนาม ไม่ใช่แค่ระเบียน ตั้งค่า canonicalization เป็น c=relaxed/relaxed ซึ่งทนต่อการ reformat ช่องว่างและการ refold header ที่เซิร์ฟเวอร์กลางทำอย่างถูกต้อง; canonicalization simple ล้มเหลวกับการเปลี่ยนแปลงที่มนุษย์แม้แต่มองไม่เห็น และอย่าใช้ tag body-length l=: มันมีไว้เพื่อให้ footer ผ่าน แต่มันปล่อยให้ ใครก็ตาม ต่อท้ายเนื้อหาในข้อความที่ลงนามของคุณโดยไม่ทำลายลายเซ็น — เป็น attack vector จริง — และมันยังไม่รอดส่วนใหญ่ของการแก้ไข gateway ไม่มี l= ทั้งปลอดภัยกว่าและเชื่อถือได้มากกว่า
6. สแกนใหม่ จากนั้นตรวจสอบการจัดตำแหน่ง ลายเซ็นที่ถูกต้องช่วย DMARC ได้ก็ต่อเมื่อโดเมน d= จัดตำแหน่งกับโดเมน From ของคุณ — ลายเซ็นที่ตรวจสอบเป็น d=yourcompany.gappssmtp.com ผ่าน DKIM และยังล้มเหลว DMARC หากนั่นคือคุณ ดู กับดักลายเซ็นเริ่มต้น จากนั้นทำงานผ่านสิ่งอื่นๆ ที่การสแกนตั้งค่าสถานะบน หน้า แก้ DKIM

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

“ลายเซ็น DKIM ไม่ถูกต้อง” เหมือนกับ “body hash did not verify” หรือไม่? ข้อความ body-hash เป็นหนึ่งกรณีย่อยที่เฉพาะเจาะจง: body เปลี่ยนหลังจากการลงนาม (footer, disclaimer, mailing list rewrite) “ลายเซ็นไม่ถูกต้อง” คือคำตัดสินครอบคลุมสำหรับการตรวจสอบที่ล้มเหลวใดๆ รวมถึง key ที่ไม่ดีและการเปลี่ยน header — ซึ่งเป็นเหตุผลที่ขั้นตอนที่ 2 ด้านบนคือการอ่าน header และเหตุใดกรณี body-hash จึงมี คู่มือของตัวเอง

ลายเซ็น DKIM ที่ไม่ถูกต้องหมายความว่าอีเมลของฉันกำลังถูกปฏิเสธหรือไม่? ไม่ใช่โดยตัวเอง — ผู้รับปฏิบัติต่อลายเซ็นที่เสียเหมือนกับที่หายไป ความเสียหายมาผ่าน DMARC: ถ้า SPF ไม่ผ่านด้วยการจัดตำแหน่งด้วย ข้อความล้มเหลว DMARC และนโยบายที่คุณเผยแพร่มีผล ณ วันที่ 2026-06-29 ของสำมะโน มีเพียง 3.87% ของ 261,086,232 โดเมนที่ได้รับการให้คะแนนที่มี SPF, DKIM และนโยบาย DMARC ที่บังคับใช้ร่วมกัน — แต่ Gmail และ Microsoft ตอนนี้คาดหวังสิ่งนั้นจาก sender ดังนั้น DKIM ที่เสียจะทำให้ deliverability เสียแม้ก่อนการปฏิเสธ

ฉันควรใช้ DKIM key ขนาด 1024-bit หรือ 2048-bit? 2048-bit — key 1024-bit อยู่ต่ำกว่าคำแนะนำการเข้ารหัสลับปัจจุบันและผู้รับบางรายลด score ลง ข้อจำกัดคือการปฏิบัติการล้วนๆ: key 2048-bit ไม่ใส่ใน TXT string 255 ตัวอักษรเดียว ดังนั้นจึงต้องแยกอย่างถูกต้อง (สาเหตุ 2 ด้านบน) การมอบหมาย CNAME ให้ผู้ให้บริการของคุณหลีกเลี่ยงปัญหาการแยกทั้งหมด

DKIM ของฉันผ่านบน checker แต่ DMARC ยังล้มเหลว — ทำไม? เกือบแน่นอนคือการจัดตำแหน่ง: ลายเซ็นผ่านการตรวจสอบ แต่โดเมน d= (เช่น yourcompany.gappssmtp.com หรือ yourtenant.onmicrosoft.com) ไม่ตรงกับโดเมน From ของคุณ ดังนั้น DMARC จึงใช้มันไม่ได้ เปิดใช้งานการลงนามด้วยโดเมนที่กำหนดเองของผู้ให้บริการ — คำแนะนำครบถ้วนอยู่ใน คู่มือกับดักลายเซ็นเริ่มต้น

ฉันสามารถปิด DKIM ถ้ามันยังคงล้มเหลวได้หรือไม่? ไม่ — ตั้งแต่คำสั่ง bulk-sender ปี 2024, Gmail และ Yahoo ต้องการ DKIM สำหรับ sender จำนวนมาก และนโยบาย DMARC ที่บังคับใช้จริงๆ ต้องการ DKIM เพราะ SPF เพียงอย่างเดียวพังภายใต้การส่งต่อ แก้ไขลายเซ็น; สาเหตุด้านบนทั้งหมดแก้ไขได้ในช่วงบ่าย

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

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

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