รายงาน SPF PermError: 100× โดเมนที่ทำลายขีดจำกัด 10 Lookup มากกว่าที่ตัวเลขพื้นผิวแสดง (2026)

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

ตัวเลข ณ วันที่ 2026-06-29 · วิธีการ v7 บวกการประมวลผลราคาสาย 2026-07-03 จากสำมะโนของโดเมน 261 ล้านรายการที่ถูกให้เกรด เราแก้ปัญหาเป้าหมาย SPF include: ทุกรายการที่อ้างถึง 100 ครั้งขึ้นไป — 10,842 เป้าหมายที่ครอบคลุม 95.2% ของการอ้างอิง include ทั้งหมด — และราคาสายที่เก็บรักษาของแต่ละโดเมนกับแผนที่นั้น เป้าหมายส่วนปลายที่ยังไม่ได้แก้ถูกนับเป็นศูนย์และเนื้อหาสายสะท้อนวันที่แก้ ดังนั้นพาดหัวเป็นค่าประมาณอนุรักษ์นิยมที่มีอคติต่ำ: เราพูดว่า “อย่างน้อย” รวมเท่านั้น ไม่ใช่บันทึกของธุรกิจรายบุคคล ดู วิธีที่เราให้เกรด

โดเมนกี่แห่งที่ทำลายขีดจำกัด SPF 10 lookup?

อย่างน้อย 797,263 — เพราะ SPF มีการทำลายตัวเองในตัวสร้างขึ้นในมาตรฐาน และทริกเกอร์ซ่อนอยู่ที่เจ้าของไม่สามารถเห็น RFC 7208 §4.6.4 จำกัดการตรวจสอบ SPF ที่ 10 DNS lookups หลังสิบครั้ง ผู้รับจะหยุดและส่งคืน PermError และบันทึก PermError ไม่ได้ป้องกันอะไรเลย นับเฉพาะ lookups ที่มองเห็นได้ในบันทึกเอง — ตามที่เครื่องมือส่วนใหญ่ทำ และสำมะโนของเราเองทำจนถึงรายงานนี้ — และคุณจะพบผู้กระทำผิดประมาณ 8,000 ราย (7,958 อย่างแม่นยำ) ราคาสาย include: ที่บันทึกเหล่านั้นดึงเข้ามาจริงๆ และจำนวนถึง 797,263: ใหญ่กว่าประมาณ 100 เท่า

ทำไมเจ้าของจึงไม่เห็นมันเข้ามา?

เพราะงบประมาณถูกใช้โดย บันทึกของคนอื่น include:onetool.example.com อ่านเหมือนหนึ่งบรรทัดในแผง DNS ของคุณ — แต่ผู้รับต้องดึงบันทึกนั้นด้วย และนับทุกกลไก lookup ที่มัน มี แบบ recursive บันทึกที่มี includes สามรายการอาจมีค่า 11 รายการ ไม่มีอะไรในโซนของคุณเองที่เปลี่ยนแปลงในวันที่คุณเกิน ผู้ให้บริการซ้อน include หนึ่งรายการเพิ่ม และ SPF ของคุณตายโดยไม่มีคำเตือน

ยิ่งกว่านั้น DMARC ถือว่า PermError เป็นความล้มเหลวบนขา SPF — ดังนั้นโดเมนที่ทำลาย SPF ของตนเองด้วยวิธีนี้กำลังล้มเหลวการยืนยันตัวตนของตนเองครึ่งหนึ่ง

สิ่งที่การกำหนดราคาสายพบ

สิ่งที่พบ	โดเมน
เกินขีดจำกัด 10 lookup, ราคาสาย	797,263
เกินขีดจำกัดนับเฉพาะกลไกที่มองเห็น	7,958
เกินขีดจำกัด ขณะลงท้ายด้วย strict `-all`	112,215
อยู่ที่ 9–10 lookups พอดี — ขอบหน้าผา	2,119,539

สองเรื่องในตารางนั้น — ที่สาม ขอบหน้าผา มีส่วนของตนเองด้านล่าง:

การนับพื้นผิวพลาด ~99% ของความเสียหาย การนับกลไกที่มองเห็นพบ 7,958 การกำหนดราคาสายพบ 797,263 ความเสียหายเกือบทั้งหมดสืบทอดมาจากสิ่งที่ includes รวมถึง
112,215 ของบันทึกที่เสียหายลงท้ายด้วย -all เจ้าของทำทุกอย่างถูกต้อง — ปีนกำแพง เลือกการลงท้ายที่เข้มงวด — และหนึ่ง include มากเกินไปยกเลิกทั้งหมด ดูเข้มงวดและเสียหายเป็นโหมดความล้มเหลวที่รุนแรงที่สุดในการรักษาความปลอดภัยอีเมล

2.1 ล้านโดเมนอยู่ห่างเพียงหนึ่งเครื่องมือจากหน้าผา

ตัวเลขที่ควรกังวลผู้อ่านที่ ปัจจุบันโอเค: 2,119,539 โดเมน resolve ไปยัง 9 หรือ 10 lookups พอดี — ต่ำกว่าขีดจำกัดในวันนี้ ตายในวันที่มีคนเชื่อมต่อแพลตฟอร์มอีกหนึ่งแห่ง นั่นคือประมาณ 1 ใน 66 ของผู้เผยแพร่ SPF ทั้งหมด และตรงกับรูปร่างของการแจกแจง: บันทึก SPF เปอร์เซ็นไทล์ที่ 99 อยู่ที่ 9 lookups แล้ว ลงทะเบียนเครื่องมือการตลาดอีกอย่าง วาง “แค่เพิ่ม include นี้” ลง และบันทึกที่ต่ำกว่าขีดจำกัดตอนเช้าอาหารเช้าจะเป็นโมฆะตอนกลางวัน

เป็นความผิดของใคร? ของสแตคมากขึ้น

ผู้ให้บริการรายใหญ่ได้ แบน SPF ของพวกเขาอย่างเงียบๆ — _spf.google.com ของ Google และ spf.protection.outlook.com ของ Microsoft ขยายไปยังรายการ IP ธรรมดาที่มีค่า lookups ภายในเป็นศูนย์ (เราตรวจสอบทั้งคู่กับ DNS สดระหว่างการวิเคราะห์นี้) การระเบิดมาจากที่อื่น: สายของแผงโฮสติ้งที่ซ้อนสามชั้น ผู้ให้บริการระดับภูมิภาคที่ include มีค่า 7–10 lookups โดยตัวเอง และการสะสมที่ซื่อสัตย์ของ SaaS — กล่องจดหมาย บวกจดหมายข่าว บวก CRM บวก helpdesk แต่ละอย่าง “แค่หนึ่ง include” ไม่มีใครเพิ่ม lookup ที่สิบเอ็ดโดยตั้งใจ มันมาในฐานะผลรวมของการตัดสินใจที่สมเหตุสมผล

วิธีตรวจสอบและแก้ไขของคุณ — ฟรี

นับจำนวนจริงของคุณ — ตัวตรวจสอบฟรีของเรา แก้สายของคุณ หรือใช้เครื่องนับ SPF lookup ใดก็ได้
ตัดน้ำหนักที่ตายแล้ว: เครื่องมือที่คุณหยุดใช้ includes ซ้ำซ้อน และ กลไก ptr ที่เลิกใช้แล้ว
แบนเฉพาะสิ่งที่คุณควบคุม การแทนที่ include ที่ลึกด้วยบล็อก IP ใช้ได้กับโครงสร้างพื้นฐานของคุณเอง IP ของบุคคลที่สามเปลี่ยนโดยไม่แจ้ง
ให้ subdomain แก่ผู้ส่งจำนวนมาก จดหมายข่าวจาก news.yourdomain.com มีบันทึกและงบประมาณ 10 lookup ของตัวเอง

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

ขีดจำกัด SPF 10 DNS lookup คืออะไร? RFC 7208 §4.6.4 อนุญาตให้ใช้ DNS lookups สูงสุด 10 ครั้งเพื่อประเมินบันทึก SPF หนึ่งรายการ — นับ lookups ภายใน include: ทุกรายการแบบ recursive การเกินจำนวนนี้ส่งคืน PermError: บันทึกถูกถือว่าไม่ถูกต้องและไม่ให้การป้องกันใดๆ

SPF PermError หมายความว่าอะไร? ข้อผิดพลาดการประเมินถาวร — ผู้รับไม่สามารถประมวลผลบันทึกของคุณ (lookups มากเกินไป หลายบันทึก หรือ syntax เสียหาย) และถือว่าโดเมนของคุณไม่มี SPF ที่ใช้งานได้ DMARC นับเป็นความล้มเหลวบนขา SPF

โดเมนกี่แห่งที่เกินขีดจำกัด SPF lookup? อย่างน้อย 797,263 จาก 139 ล้านผู้เผยแพร่ SPF ตามการประมวลผลราคาสายของเรา — ประมาณ 100× ที่ 7,958 ที่มองเห็นโดยไม่แก้สาย 2,119,539 เพิ่มเติมอยู่ที่ 9–10 lookups หนึ่ง include จากขีดจำกัด

PermError หยุดการส่งอีเมลของฉันหรือไม่? โดยปกติไม่ — ผู้รับดำเนินการโดยไม่มี SPF และเมลของคุณขึ้นอยู่กับ DKIM และชื่อเสียง สิ่งที่หยุดทำงานคือการป้องกัน: นักปลอมแปลงไม่ถูกปฏิเสธอีกต่อไป และการตรวจสอบ DMARC ทุกรายการของเมลของคุณสูญเสียขา SPF มันล่องหนจนกว่าจะแพง

ฉันจะลดจำนวน SPF lookup ของฉันได้อย่างไร? ลบ includes ที่ไม่ได้ใช้และ ptr แบน infrastructure ของคุณเองเป็น ip4:/ip6: ย้ายผู้ส่งจำนวนมากไปยัง subdomain และนับใหม่หลังจากมีเครื่องมือใหม่ทุกชิ้น คู่มือแก้ไข อธิบายผ่านมัน

ค้นหาตัวเลขจริงของคุณ

กลไกที่คุณมองเห็นไม่ใช่จำนวน lookup ของคุณ — ตัวเลขที่แก้แล้วคือสิ่งที่ผู้รับคำนวณ และมันคือการตรวจสอบ 30 วินาที

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