DKIM ล้มเหลวหลังจากเปลี่ยนเครื่องมืออีเมล: คู่มือการย้าย CNAME และ Selector (2026)

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

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

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

ลำดับการแก้ไข: สแกนโดเมน จากนั้นตรวจสอบ เป้าหมายที่จัดเก็บ ของ CNAME ใหม่แต่ละรายการด้วย dig — เป้าหมายที่ลงท้ายด้วยชื่อโดเมนของคุณเองคือสัญญาณที่ชัดเจน ซ่อมแซมระเบียนที่ authoritative nameservers ยืนยันว่าเครื่องมือใหม่ลงนามและผ่าน ก่อน กำหนดเส้นทางอีเมลจริงผ่านมัน และเก็บ selector ของเครื่องมือเก่าเผยแพร่จนกว่า traffic จะหมด

ทำไม DKIM ถึงพังเมื่อคุณเปลี่ยนเครื่องมือ?

ไม่มีอะไรเกี่ยวกับ DKIM เองที่เปลี่ยนแปลง — selector ของคุณเปลี่ยนไป เครื่องมือเก่าลงนามด้วย selector ของมัน เครื่องมือใหม่ลงนามด้วย selector ที่แตกต่างกัน โดยปกติมอบหมายผ่าน CNAME สองหรือสามรายการที่เพิ่มระหว่างการ onboarding สี่ข้อผิดพลาดอธิบายความล้มเหลว DKIM หลังการย้ายเกือบทั้งหมด:

แผง DNS ของคุณผนวก zone ของคุณไปยังเป้าหมาย CNAME แผงหลายตัวถือว่า hostname ที่วางเป็น relative และเก็บ target.provider.com.yourdomain.com แทน target.provider.com อย่างเงียบๆ ระเบียนมีอยู่ แผงแสดงเครื่องหมายถูกสีเขียว และมัน resolve ไปสู่ไม่มีอะไร
ความสับสนของ trailing dot บางแผง ต้องการ trailing dot (target.provider.com.) เพื่อหมายถึง “absolute — หยุดผนวก zone ของฉัน”; แผงอื่นปฏิเสธ dot ว่าไม่ถูกต้องและจัดการ absoluteness ของตัวเอง ค่าที่วางเดียวกันถูกต้องในแผงหนึ่งและบิดเบือนในอีกแผง
selector ของเครื่องมือเก่าถูกลบในวันเปลี่ยน อีเมลที่เครื่องมือเก่าลงนามแล้วอยู่ใน retry queue และเส้นทางการส่งต่อเป็นวัน การลบ selector — หรือปิดบัญชีเก่า ซึ่งทำลาย CNAME ที่มอบหมาย — ทำลายอีเมลทั้งหมดเหล่านั้นย้อนหลัง
คุณตรวจสอบที่ nameservers ที่ผิด ถ้าการย้ายรวมการเปลี่ยน nameserver ระเบียนที่แก้ไขแล้วอาจมีอยู่ที่ชุด NS หนึ่งในขณะที่ผู้รับยังคง query อีกชุด

มีเพียง 51.84% ของโดเมน 261 ล้านในสำมะโนที่นำเสนอ DKIM key ที่ค้นพบได้เวลาสแกน (ข้อมูล ณ 2026-06-29)

การย้ายเดียวกันมักทิ้งเศษ SPF ด้วย — 1,013,416 โดเมน ประมาณ 1 ใน 138 ของผู้ที่พยายาม SPF รัน v=spf1 สองระเบียน สัญญาณคลาสสิกที่ การเปลี่ยนผู้ให้บริการเพิ่มระเบียนแทนที่จะรวมหนึ่ง ด้านนั้นของการย้ายมีคู่มือของตัวเอง: SPF หยุดทำงานหลังจากเปลี่ยนผู้ให้บริการอีเมล

ฉันจะระบุระเบียน CNAME ที่บิดเบือนได้อย่างไร?

อย่าเชื่อถือแผง — ถาม DNS ว่ามันเก็บจริงอะไร Query เป้าหมาย CNAME สำหรับแต่ละ selector ที่เครื่องมือใหม่ให้คุณ ตัวอย่างประกอบ เลียนแบบ selector แบบมอบหมายของ SendGrid (รูปร่างเป้าหมายของผู้ให้บริการของคุณจะแตกต่างกัน):

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.yourdomain.com.

ผู้ให้บริการขอ s1.domainkey.u1234567.wl123.sendgrid.net — แต่เป้าหมายที่เก็บลงท้ายด้วย .yourdomain.com แผงผนวก zone ชื่อนั้น resolve ไปสู่ไม่มีอะไร ดังนั้นผู้รับไม่พบ key เวอร์ชันที่ถูกต้อง:

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.

(trailing dot ใน dig output ปกติ — มันทำเครื่องหมายชื่อที่ qualified อย่างสมบูรณ์) ถ้าเป้าหมายถูกต้อง ติดตามหนึ่งขั้น: dig TXT s1._domainkey.yourdomain.com +short ควรส่งคืน key ของผู้ให้บริการ คำตอบว่างพร้อม CNAME ที่ถูกต้องหมายความว่าปัญหาอยู่ที่ฝั่งผู้ให้บริการของการมอบหมาย — เสร็จสิ้นขั้นตอนการตรวจสอบของพวกเขา หรือดู DKIM “no key for signature” สำหรับการวินิจฉัยระดับ selector

Runbook การย้าย: ก่อน ระหว่าง หลัง

ความล้มเหลวมักไม่ใช่ระเบียน — มันคือลำดับ การย้าย DKIM ไปผิดที่ cutover เพราะการตรวจสอบเกิดขึ้น หลังจาก การสลับ เมื่ออีเมลจริงล้มเหลวแล้ว

ระยะ	สิ่งที่ต้องทำ	ประตูก่อนดำเนินการต่อ
ก่อนการสลับ	เพิ่ม DKIM CNAME ของเครื่องมือใหม่ (และระเบียน bounce-domain) จากนั้นพิสูจน์: `dig` เป้าหมายของ CNAME แต่ละรายการจากนอกเครือข่ายของคุณ เสร็จขั้นตอนการตรวจสอบของเครื่องมือเอง และส่งทดสอบผ่านเครื่องมือใหม่ไปยังกล่องจดหมายที่คุณควบคุม	ข้อความทดสอบแสดง `dkim=pass` โดยที่ `d=` = โดเมนของคุณ — อย่ากำหนดเส้นทางอีเมลจริงผ่านเครื่องมือที่ไม่ได้ตรวจสอบ
วันสลับ	ย้าย traffic จริงไปยังเครื่องมือใหม่ อย่าแตะสิ่งของเครื่องมือเก่า: ปล่อย selector, CNAME และบัญชีมีชีวิต	อีเมลของเครื่องมือใหม่ผ่านที่ผู้รับจริง เครื่องมือเก่ายังคงผ่านสำหรับสิ่งที่ยังไหลผ่านมัน
หลังจากระบาย	ดูรายงานรวม DMARC จนกว่า selector ของเครื่องมือเก่าจะหยุดปรากฏ (retry queue และการส่งต่อทำงานเป็นวัน — อนุญาตหนึ่งสัปดาห์หรือมากกว่า) จากนั้นเลิกใช้ระเบียนและบัญชีของมัน	selector เก่าไม่มีในรายงาน ≥ 7 วันก่อนการลบ

แถวที่ตัวหนาคือที่ที่การย้ายถูกบันทึกหรือสูญเสีย: การตรวจสอบทุกรายการในนั้นสามารถทำได้หลายวันก่อน cutover โดยไม่มีความเสี่ยงต่ออีเมลสด

ฉันจะแก้ไข DKIM หลังการสลับได้อย่างไร?

สแกนฟรีที่ defaults.exposed ก่อนแตะ DNS ระบบอ่านระเบียนสดของคุณและแสดงสิ่งที่ผู้รับเห็นจริงๆ — รวมถึงเป้าหมาย CNAME ที่ zone ผนวกและ selector ที่ไม่ resolve
ระบุรายการระเบียน DKIM ที่เครื่องมือใหม่คาดหวัง จาก admin console ของมัน — สำหรับผู้ให้บริการกล่องจดหมาย คู่มือการตั้งค่า Google Workspace และ Microsoft 365 แสดงว่าอยู่ที่ไหน newsletter และเครื่องมือ CRM แสดง CNAME ของพวกเขาภายใต้การยืนยันตัวตนโดเมน (ดู Mailchimp/Brevo/Klaviyo ล้มเหลว DMARC)
ตรวจสอบค่าที่จัดเก็บของแต่ละระเบียนด้วย dig CNAME <name> +short และเปรียบเทียบกับสิ่งที่เครื่องมือขอทีละตัวอักษร เป้าหมายที่ลงท้ายด้วยโดเมนของคุณเอง = zone ผนวก; ป้อนใหม่ และถ้าแผงยังคงผนวก เพิ่ม trailing dot (หรือลบมัน ถ้าแผงปฏิเสธ dot)
ตรวจสอบที่ authoritative nameservers dig +short NS yourdomain.com จากนั้นทำซ้ำการตรวจสอบ CNAME @<นั้น nameserver> ถ้าการย้ายเปลี่ยน nameservers ตรวจสอบทั้งสองชุด — ผู้รับอาจยัง query รายการเก่าจนกว่าการมอบหมายจะแพร่กระจาย
รันการตรวจสอบของเครื่องมือใหม่และส่งข้อความทดสอบ ส่วนหัว Authentication-Results ควรแสดง dkim=pass โดยที่ d= เท่ากับโดเมนของคุณ — pass บนโดเมนเริ่มต้นของเครื่องมือไม่จัดตำแหน่งสำหรับ DMARC
ปล่อย selector ของเครื่องมือเก่าเผยแพร่จนกว่าอีเมลจะหมด จากนั้นเลิกใช้งานพวกเขาโดยเจตนา จากนั้นสแกนใหม่ และทำงานผ่านสิ่งอื่นที่ตั้งค่าสถานะบนหน้า แก้ DKIM

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

ฉันต้องการ trailing dot บน DKIM CNAME ของฉันหรือไม่? มันขึ้นอยู่กับแผงทั้งหมด Dot หมายถึง “ชื่อ absolute — อย่าผนวก zone ของฉัน”; บางแผงต้องการมัน บางแผงเพิ่มให้คุณ บางแผงปฏิเสธมัน การทดสอบเดียวที่สำคัญคือ output ของ dig CNAME <selector>._domainkey.yourdomain.com +short หลังจากบันทึก: ถ้าเป้าหมายลงท้ายด้วยโดเมนของคุณเอง แผงผนวก zone และคุณต้องการ dot

ฉันสามารถลบระเบียน DKIM ของเครื่องมือเก่าในวันสลับได้ไหม? ไม่ อีเมลที่เครื่องมือเก่าลงนามยังอยู่ใน retry queue และเส้นทางการส่งต่อ และการลบ key ที่มันชี้ไปทำลายข้อความเหล่านั้นย้อนหลัง เก็บ selector เก่าสดจนกว่าพวกเขาจะหยุดปรากฏในรายงานรวม DMARC ของคุณ — หนึ่งสัปดาห์หรือมากกว่า — และอย่าปิดบัญชีเก่าก่อนถึงเวลานั้นด้วย

แผง DNS และเครื่องมือใหม่ทั้งคู่บอกว่า “ตรวจสอบแล้ว” แต่ผู้รับยัง DKIM ล้มเหลว อย่างไร? สองกรณีทั่วไป: เครื่องมือตรวจสอบกับการตรวจสอบที่แคชในขณะที่ authoritative nameservers ให้บริการสิ่งอื่น (query พวกเขาโดยตรงด้วย dig @<ns>) หรือ DKIM ผ่านแต่บนโดเมนการลงนาม เริ่มต้น ของเครื่องมือแทนที่จะเป็นของคุณ ดังนั้น DMARC ยังล้มเหลวการจัดตำแหน่ง การสแกนแยกความแตกต่างระหว่างสอง

ระเบียน DKIM ของทั้งสองเครื่องมือสามารถอยู่ร่วมกันในช่วง overlap ได้ไหม? ใช่ — และควรเป็นเช่นนั้น DKIM ไม่มีกฎระเบียนเดี่ยว: แต่ละ selector คือชื่อ DNS ของตัวเอง ดังนั้นระเบียนของทั้งสองเครื่องมืออยู่เคียงข้างกันโดยไม่มีความขัดแย้ง ซึ่งทำให้กฎ keep-old-selectors-through-the-drain ไม่มีค่าใช้จ่าย (SPF คือตรงกันข้าม — v=spf1 สองระเบียนทำให้เป็นโมฆะ ซึ่งเป็นเหตุผลที่ คู่มือการย้าย SPF เกี่ยวกับการรวม)

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

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

ตรวจสอบ DKIM ของคุณฟรี

ดูว่า selector ของเครื่องมือใหม่ resolve และสิ่งที่ต้องแก้ไขอยู่คืออะไร — เป็นส่วนตัวและเฉพาะเจ้าของ

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