Defaults.Exposed

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

DKIM "No Key for Signature": วิธีแก้ไข Selector และการหมุนเวียน Key (2026)

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

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

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

การแก้ไขคือระเบียน DNS หนึ่งรายการ ที่พบในส่วนหัวหนึ่งรายการ อ่านแท็ก s= และ d= จากส่วนหัว DKIM-Signature จริงเพื่อเรียนรู้ว่าอีเมลของคุณถูกลงนามด้วย selector ใด เผยแพร่ (หรือซ่อมแซม) ระเบียนที่แน่นอนนั้น และต้องการ CNAME delegation เพื่อให้ผู้ให้บริการหมุนเวียน key ให้คุณ จากนั้นหมุนเวียนตาม runbook ด้านล่าง — ข้อผิดพลาดนี้มักหมายความว่ามีคนลบ selector เก่าเร็วเกินไป

”dkim no key for signature” หมายความว่าอะไร?

ทุกลายเซ็น DKIM มีสองแท็กที่บอกผู้รับว่าจะดึง public key จากที่ไหน: d= (signing domain) และ s= (selector) ผู้รับ query ชื่อ DNS หนึ่งรายการที่สร้างจากพวกเขา — s._domainkey.d — สำหรับ key “No key for signature” หมายความว่า query นั้นส่งคืนว่างเปล่า: ลายเซ็นมีอยู่ แต่ key ที่มันตั้งชื่อไม่มี

การกำหนดคำปรากฏในส่วนหัว Authentication-Results และรายงานรวม DMARC — คำที่แน่นอนแตกต่างตามผู้รับ แต่สองรสชาติมีความสำคัญ:

สตริงผลลัพธ์ (ส่วน ตามที่สังเกตกันทั่วไป)สิ่งที่เกิดขึ้นจริงชั่วคราว?
dkim=temperror (no key for signature)DNS query ล้มเหลวหรือหมดเวลา — ผู้รับไม่สามารถรับคำตอบได้เลยใช่ — การ retry มักผ่าน; ตรวจสอบเฉพาะถ้าต่อเนื่อง
dkim=permerror (no key for signature)DNS query สำเร็จและคำตอบคือ “ไม่มีระเบียนดังกล่าว” — selector ไม่มีอยู่จริงไม่ — ระเบียนหายไปจนกว่าคุณจะเผยแพร่มัน

temperror ครั้งเดียวคือสภาพอากาศ DNS permerror — หรือ temperror ที่ซ้ำหลายวันและผู้รับ — หมายความว่าระเบียนที่ลายเซ็นชี้ไปไม่อยู่ใน zone ของคุณ นั่นคือคู่มือนี้

ผลที่ตามมา: ลายเซ็นที่ตรวจสอบไม่ได้นับเป็นไม่มี DKIM เลย ดังนั้น DMARC ถอยกลับไปหา SPF เพียงอย่างเดียว — และ SPF พังภายใต้การส่งต่อ ถ้าลายเซ็นมีอยู่แต่ ไม่ถูกต้อง แทนที่จะหายไป (body hash, key ที่บิดเบือน) นั่นเป็นความล้มเหลวที่แตกต่างกัน — ดู “ลายเซ็น DKIM ไม่ถูกต้อง”

ฉันจะค้นหาว่าอีเมลของฉันถูกลงนามด้วย selector ใด?

อย่าเดาจากเอกสารของผู้ให้บริการ — อ่านจากข้อความจริง:

  1. ส่งข้อความจากระบบที่ได้รับผลกระทบไปยังกล่องจดหมายที่คุณควบคุม (ที่อยู่ Gmail ทำงานได้ดี)
  2. เปิด source ดิบ (“Show original” ใน Gmail, “View message source” ใน Outlook)
  3. ค้นหาส่วนหัว DKIM-Signature: และอ่านสองแท็ก: s= คือ selector d= คือ signing domain ตัวอย่างประกอบ: DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=mail2026; ...
  4. ระเบียนที่ผู้รับ query คือ s._domainkey.d — ที่นี่ mail2026._domainkey.yourdomain.com ตรวจสอบด้วยตัวเอง: dig TXT mail2026._domainkey.yourdomain.com +short คำตอบว่างเปล่า = ข้อผิดพลาดจริงสำหรับผู้รับทุกราย
  5. ทำซ้ำต่อระบบส่งแต่ละระบบ ข้อความสามารถมีลายเซ็น DKIM หลายรายการ — ผู้ให้บริการกล่องจดหมาย เครื่องมือ newsletter helpdesk — แต่ละรายการมีคู่ s=/d= และระเบียนของตัวเอง แก้ไขรายการที่ล้มเหลว และสังเกต d= ของมัน: เฉพาะลายเซ็นที่ d= ตรงกับโดเมน From ของคุณที่ช่วย DMARC

ทำไมระเบียน selector ถึงหายไป?

สี่สาเหตุอธิบายข้อผิดพลาดเหล่านี้เกือบทั้งหมด — ตรวจสอบตามลำดับนี้:

  1. มันไม่เคยถูกเผยแพร่ signer ถูกเปิด (หรือเป็นค่าเริ่มต้น) ด้วย selector ที่ไม่มีใครเพิ่มใน DNS ทั่วไปกับเครื่องมือและ gateway ใหม่ที่ลงนามโดยไม่คาดคิด
  2. มันถูกลบระหว่างการหมุนเวียน มีคนทำความสะอาด selector เก่าขณะที่ข้อความที่ลงนามด้วยมันยังอยู่ระหว่างการส่ง รอ retry หรือรอการส่งต่อ อีเมลนั้นลงนามด้วย s=old แล้ว การลบ old._domainkey ทำลายข้อความทั้งหมดเหล่านั้นย้อนหลัง
  3. UI DNS ของคุณบิดเบือนเป้าหมาย CNAME ผู้ให้บริการหลายรายมอบหมายผ่าน CNAME (s1._domainkey.yourdomain.com → s1.domainkey.u123.esp.com) และแผง DNS หลายตัวผนวก zone ของคุณไปยังเป้าหมายอย่างเงียบๆ — เก็บ s1.domainkey.u123.esp.com.yourdomain.com ซึ่ง resolve ไปสู่ไม่มีอะไร ตรวจสอบ เป้าหมาย: dig CNAME s1._domainkey.yourdomain.com +short กับดักเดียวกันนี้โจมตีระหว่างการย้ายเครื่องมือ — ดู DKIM ล้มเหลวหลังจากเปลี่ยนเครื่องมืออีเมล
  4. ผู้ให้บริการหมุนเวียน zone ของคุณไม่ได้ DKIM key ของผู้ให้บริการที่วางเป็นระเบียน TXT แบบ static (แทน CNAME ของพวกเขา) ถูกทิ้งโดยการหมุนเวียนตามกำหนด — signer ย้ายไปยัง selector ที่คุณไม่เคยเผยแพร่ มีเพียง 51.84% ของโดเมน 261 ล้านในสำมะโนที่นำเสนอ DKIM key ที่ค้นพบได้เวลาสแกน (ข้อมูล ณ 2026-06-29)

ฉันจะแก้ไข “no key for signature” ได้อย่างไร?

  1. สแกนฟรีที่ defaults.exposed ก่อนแตะ DNS ระบบอ่าน DKIM, SPF และระเบียน DMARC สดของคุณและแสดงสิ่งที่ผู้รับเห็นจริงๆ — รวมถึงว่า selector resolve หรือไม่ และเป้าหมาย CNAME ถูกบิดเบือนหรือไม่
  2. เผยแพร่ selector ที่ signer ใช้จริง — ค่า s= จากส่วนหัว ไม่ใช่อยู่ใน runbook เก่า รับระเบียนจาก admin console ของผู้ให้บริการของคุณ (การตั้งค่า DKIM บน Google Workspace · การตั้งค่า DKIM บน Microsoft 365) และเพิ่มที่ s._domainkey.yourdomain.com พอดี
  3. ต้องการ CNAME delegation มากกว่าการวาง TXT key ถ้าผู้ให้บริการของคุณเสนอ DKIM CNAME ให้ใช้: key อยู่ใน zone ของพวกเขา ดังนั้นพวกเขาหมุนเวียนมันโดยไม่ให้คุณแตะ DNS อีกครั้ง — สาเหตุที่ 4 กลายเป็นไปไม่ได้ แพลตฟอร์ม newsletter เกือบทั้งหมดทำงานแบบนี้; ดู Mailchimp/Brevo/Klaviyo ล้มเหลว DMARC
  4. ตรวจสอบจากนอกแผงของคุณ dig TXT s._domainkey.yourdomain.com +short (หรือ dig CNAME … สำหรับ selector ที่มอบหมาย) จากเครื่องนอกเครือข่ายของคุณ แผงที่แสดงระเบียนไม่พิสูจน์อะไรถ้า zone ให้บริการสิ่งอื่น
  5. สแกนใหม่และส่งข้อความทดสอบใหม่ Authentication-Results ควรอ่าน dkim=pass ตอนนี้ จากนั้นทำงานผ่านสิ่งอื่นที่การสแกนตั้งค่าสถานะบนหน้า แก้ DKIM — ลายเซ็นที่ผ่านซึ่งไม่จัดตำแหน่งกับโดเมน From ของคุณยังล้มเหลว DMARC

ฉันจะหมุนเวียน DKIM key โดยไม่เกิดข้อผิดพลาดนี้ได้อย่างไร?

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

ขั้นตอนการดำเนินการประตูก่อนขั้นตอนถัดไป
1. เพิ่มเผยแพร่ selector ใหม่ (s2._domainkey…) ควบคู่กับรายการเก่าdig ยืนยันว่ามัน resolve จากภายนอก
2. สลับชี้ signer ไปยัง selector ใหม่ข้อความทดสอบแสดง s=s2 และ dkim=pass
3. รอปล่อย selector เก่า เผยแพร่ขณะที่ traffic ที่บินอยู่ รอ retry และส่งต่อหมดลง≥ 7 วัน ดูรายงานรวม DMARC จนกว่า selector เก่าจะหยุดปรากฏ
4. เลิกใช้ลบ key เก่า — หรือดีกว่า เผยแพร่ใหม่ด้วยแท็ก p= ว่าง: “เลิกใช้” ไม่ใช่ “ไม่เคยมีอยู่”อย่าเริ่มสิ่งนี้ที่ cutover — การลบก่อนเวลาเป็นสาเหตุ #1 ของ “no key for signature”

ด้วย CNAME delegation ผู้ให้บริการของคุณรัน runbook นี้พอดีใน zone ของตัวเองและคุณไม่เคยเห็นมัน — ข้อโต้แย้งที่แข็งแกร่งที่สุดสำหรับการมอบหมาย

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

“No key for signature” เป็น temperror หรือ permerror? สตริงทั้งสองมีอยู่: temperror คือ DNS lookup ที่ล้มเหลวหรือหมดเวลา — ชั่วคราว มักหายไปเมื่อ retry — ในขณะที่ permerror หมายความว่า DNS ตอบว่า “ไม่มีระเบียนดังกล่าว” temperror ที่ซ้ำหลายผู้รับมักกลายเป็นระเบียนที่หายไปจริงๆ ด้วย ตรวจสอบด้วย dig และเชื่อถือคำตอบ ไม่ใช่ label

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

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

ตัวตรวจสอบของผู้ให้บริการบอกว่า DKIM ได้รับการกำหนดค่า แต่ผู้รับยังรายงาน no key อย่างไร? เกือบตลอดเวลาคือกับดัก CNAME-target: แผง DNS ของคุณผนวก zone ของคุณไปยังเป้าหมาย (…esp.com.yourdomain.com) ดังนั้นระเบียนมีอยู่แต่ชี้ไปไม่มีที่ไหน dig CNAME selector._domainkey.yourdomain.com +short แสดงเป้าหมายที่จัดเก็บแบบขาวดำ — เปรียบเทียบกับสิ่งที่ผู้ให้บริการขอทีละตัวอักษร

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

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

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

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

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