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

SPF PermError: วิธีแก้ไข "DNS Lookups มากเกินไป" โดยไม่ทำลายอีเมลของคุณ (2026)

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

ตัวเลข ณ 2026-06-29 · methodology v7. ข้อมูล census รวมจากโดเมน 261 ล้านโดเมน ดู วิธีที่เราให้คะแนน

อย่างน้อย 797,263 โดเมนเกิน 10-DNS-lookup limit ของ SPF ตาม census ของ Defaults.Exposed จาก 261,086,232 โดเมน — จาก 139 ล้าน SPF publishers เกินสิบ lookups ผู้รับหยุดและส่งคืน PermError: SPF ของคุณเป็นโมฆะ และ DMARC นับ PermError ว่าเป็น fail

การแก้ไขมีลำดับที่เข้มงวด และคู่มือส่วนใหญ่เข้าใจผิดกลับด้าน นับ lookups ที่ resolved จริง; ลบ includes ที่ตายแล้วและไม่ได้ใช้ — นั้นอย่างเดียวแก้ไข records ส่วนใหญ่; ย้าย bulk senders ไปยัง subdomains พร้อม SPF budget ของตัวเอง; flatten เฉพาะเป็นทางเลือกสุดท้าย และเฉพาะด้วย automated re-flattening เพราะ static flattening เสื่อมสภาพและทำให้การส่งเสียหายอย่างเงียบๆ

”SPF PermError: too many DNS lookups” หมายความว่าอะไร?

RFC 7208 §4.6.4 จำกัดการตรวจสอบ SPF ทุกครั้งที่ 10 DNS lookups เกินสิบ ผู้รับหยุดและส่งคืน PermError — record ทั้งหมดถูกถือว่าเสียหาย ไม่ใช่แค่ส่วนที่เกิน budget ส่วนเดียวกันยังเพิ่ม ceiling ที่น้อยคนรู้: มากสุด 2 “void lookups” (queries ที่ส่งคืนไม่มีคำตอบหรือ NXDOMAIN) ดังนั้น include: entries ตายสองสามรายการสำหรับ services ที่ยกเลิกสามารถทำให้ SPF ของคุณเป็นโมฆะเองได้

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

ตัวเลข census หนึ่งแสดงว่า failure mode นี้โหดร้ายแค่ไหน: 112,215 โดเมนเผยแพร่ strict -all record ที่เป็นโมฆะเพราะ lookup overflow — จาก 54,655,923 โดเมนที่เผยแพร่ -all เลย เจ้าของทำส่วนที่ยาก — เลือก ending แบบเข้มงวด — และ include หนึ่งรายการมากเกินไปปิด record ทั้งหมด พวกเขาดูเข้มงวด แต่เสียหาย ดูข้อมูลครบที่ SPF PermError report

ทำไม SPF ของฉันถึงเสียทั้งที่ฉันไม่ได้เปลี่ยนอะไร?

เพราะ budget ส่วนใหญ่ถูกใช้โดย records ของคนอื่น ทุก include: ถูกประเมินแบบ recursive และทุก lookup mechanism ภายในมัน นับกับสิบของคุณ บรรทัดหนึ่งใน DNS panel ของคุณอาจมีค่าสี่หรือห้า lookups เมื่อ resolved provider เพิ่ม include หนึ่งรายการอีก และ SPF ของคุณตายโดยไม่มีการเปลี่ยนแปลงใดๆ ใน zone ของคุณ

platforms รายใหญ่ไม่ใช่ปัญหา: Google และ Microsoft ทั้งคู่ flatten SPF ของตัวเอง — _spf.google.com และ spf.protection.outlook.com expand เป็น IP lists ธรรมดาที่มีค่า zero internal lookups (verified กับ live DNS, July 2026) blowouts ในโลกจริงมาจาก hosting-panel include chains ที่ซ้อนหลาย layers และจาก SaaS stacking ที่ซื่อสัตย์ — mailbox บวก newsletter บวก CRM บวก helpdesk แต่ละรายการ “แค่ include หนึ่งรายการ” ไม่มีใครเพิ่ม lookup ที่สิบเอ็ดโดยตั้งใจ มันมาเป็นผลรวมของการตัดสินใจที่สมเหตุสมผล นั่นคือเหตุผลที่ขอบ cliff แออัดมาก: 2,119,539 โดเมนอยู่ที่ 9–10 resolved lookups — ประมาณ 1 ใน 66 ของ SPF publishers ทั้งหมด โอเควันนี้ เป็นโมฆะวันที่มีคนวาง include อีกรายการ SPF record p99 resolve ไปยัง 9 lookups แล้ว ถ้า stack ของคุณ SaaS-heavy คู่มือ SPF failing for SaaS tools ครอบคลุมเวอร์ชัน vendor-by-vendor

ส่วนใดของ SPF record ที่นับว่าเป็น DNS lookups?

นับ resolved total ไม่ใช่บรรทัดที่มองเห็น สี่ includes อาจเป็นสี่ lookups หรือสิบสี่

จะแก้ไข “too many DNS lookups” โดยไม่ทำลายอีเมลได้อย่างไร?

1. รัน free scan ก่อนแตะ DNS มัน resolve include chain ครบของคุณและแสดง lookup count จริง ดังนั้นคุณแก้ไขปัญหาจริง — ไม่ใช่ record ตามที่ปรากฏใน panel (ถ้ามันบอกว่าคุณไม่มี SPF เลย นั่นคือ failure ที่ต่างกัน — ดู “SPF record not found”)
2. ลบ includes ที่ตายแล้วและไม่ได้ใช้ก่อน tool ที่คุณเลิกใช้ในปี 2023 old host’s include ที่รอดจาก migration, duplicates, ptr mechanism ใดๆ Dead includes เป็นพิษสองชั้น: พวกมัน burn lookup budget และ มักเป็นแหล่ง void lookups ที่ปกติ records ที่เกิน budget ส่วนใหญ่กลับมาต่ำกว่า 10 ในขั้นตอนนี้เพียงขั้นตอนเดียว ถ้า record ของคุณยังมี mechanisms ของ provider ก่อนหน้า ทำตาม migration cleanup guide
3. ตรวจสอบว่า include ที่เหลือแต่ละรายการทำอะไรอยู่ ผู้รับประเมิน SPF กับ Return-Path (RFC5321.MailFrom) domain ไม่ใช่ From header — และ SaaS tools หลายรายการใส่ bounce domain ของตัวเอง บน Return-Path ดังนั้น include ของพวกมันใน record ของคุณไม่ทำอะไรนอกจากใช้ budget เก็บ includes เฉพาะสำหรับ services ที่ใช้โดเมนของคุณเป็น Return-Path สำหรับส่วนที่เหลือ เปิดใช้งาน custom-domain DKIM ของ vendor แทน
4. ย้าย bulk senders ไปยัง subdomains Newsletters จาก news.yourdomain.com transactional mail จาก mail.yourdomain.com แต่ละ subdomain มี SPF record ของตัวเองพร้อม 10-lookup budget ใหม่ และปัญหาใน stream หนึ่งหยุดไม่ให้ bleeding ไปยัง stream อื่น
5. เฉพาะหลังจากนั้นพิจารณา flattening — และเฉพาะ automated flattening ดูด้านล่าง
6. สแกนอีกครั้งเพื่อยืนยัน ว่าคุณอยู่ต่ำกว่า 10 อย่างสบาย — มุ่งหา headroom ไม่ใช่ 10 พอดี มิฉะนั้นคุณเพิ่งกลับไปเข้าร่วมโดเมน 2.1 ล้านบนขอบ cliff จากนั้นทำงานผ่านสิ่งอื่นที่ scan flags บนหน้า แก้ไข SPF

ควร flatten SPF record หรือไม่?

Flattening แทนที่ includes ด้วย ip4:/ip6: blocks พื้นฐาน ซึ่งมีค่า lookups เป็นศูนย์ มันทำงาน — และทำด้วยมือ มันคือ delivery outage แบบ delayed-action

Providers หมุน sending IPs เป็นประจำและไม่ประกาศกับใคร IP list แบบ static ถูกต้องวันที่คุณวางและเงียบๆ ผิดภายในไม่กี่เดือน — และเพราะ failure แสดงขึ้นเป็น คนอื่น ไม่ได้รับอีเมลของคุณ คุณรู้ช้า ถ้า pruning และ subdomains พาคุณต่ำกว่าขีดจำกัด หยุดตรงนั้น อย่า copy IP blocks ของบุคคลที่สามลงใน record ของคุณด้วยมือเป็นการแก้ไขถาวร

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

SPF PermError หมายความว่าอีเมลของฉันหยุดส่งหรือไม่? ไม่ทันที — นั่นคือสิ่งที่ทำให้มันอันตราย DMARC นับ PermError ว่าเป็น SPF fail ดังนั้นการส่งพึ่งพา DKIM ทั้งหมด ถ้า DKIM ขาดหายไปหรือเสียระหว่างส่ง คุณกำลัง fail DMARC จาก 139 ล้าน SPF publishers ใน census (ณ 2026-06-29) อย่างน้อย 797,263 อยู่ในสถานะนี้ — ส่วนใหญ่ไม่รู้

Record ของฉันมีแค่สี่ includes — มันจะเกิน 10 lookups ได้อย่างไร? Includes นับ recursive: ทุกอย่างภายในแต่ละ include (และภายใน includes ของมัน) ถูกเรียกเก็บจาก budget ของคุณ ดังนั้นสี่บรรทัดที่มองเห็นอาจ resolve เป็นสิบสี่ lookups นับด้วย resolving tool ไม่ใช่สายตา — การ resolve chains คือวิธีที่ PermError report พบโดเมนที่เสียมากกว่า ~100× ที่การนับ surface แสดง

ฉัน end record ด้วย -all — ฉันน่าจะได้รับการป้องกันหรือเปล่า? เฉพาะถ้า record ประเมิน census ของเรา (ณ 2026-06-29) พบโดเมน 112,215 โดเมนที่ strict -all records เป็นโมฆะจาก lookup overflow qualifier แบบเข้มงวดบน PermError record ป้องกันอะไรไม่ได้

ขีดจำกัดคือ 10 lookups ต่อ include หรือสำหรับ record ทั้งหมด? การประเมินทั้งหมด: RFC 7208 §4.6.4 จำกัดการตรวจสอบครบที่ 10 บวกมากสุด 2 void lookups แต่ละ subdomain มี record และ budget ของตัวเอง — นั่นคือเหตุผลที่ขั้นตอน 4 ทำงาน

ip4 และ ip6 entries นับสู่ขีดจำกัดหรือไม่? ไม่ — IP mechanisms ไม่มีค่า ซึ่งนั่นคือเหตุผลว่าทำไม flattening ลดจำนวนพอดี

ส่ง report ให้เจ้าของ

ถ้าคุณแก้ไขสิ่งนี้สำหรับลูกค้าหรือนายจ้างของคุณ จบงานด้วยหลักฐาน รัน free scan อีกครั้งหลังจากการเปลี่ยนแปลงของคุณและส่ง graded report ให้เจ้าของธุรกิจ: ภาษาธรรมดา มีวันที่ PermError หายไป นั่นคือ artifact ที่พวกเขาต้องการสำหรับการต่ออายุ cyber-insurance และ customer security questionnaire ครั้งต่อไป — ความแตกต่างระหว่าง “ฉันเปลี่ยน DNS records” และ before-and-after ที่มีการบันทึก

ตรวจสอบโดเมนของคุณฟรี

ดู resolved lookup count จริงของคุณ — และทุกอย่างอื่น SPF, DKIM และ DMARC — แบบส่วนตัวและเจ้าของเท่านั้น

ตรวจสอบโดเมนของคุณ → · แก้ไข SPF → · SPF failing for SaaS tools → · ตั้งค่า SPF บน GoDaddy → · วิธีที่เราให้คะแนน → · ข้อมูลรวมเท่านั้น ข้อมูลจัดเก็บและประมวลผลใน EU