Defaults.Exposed › รายงาน

ทำไม SPF ถึงล้มเหลว? ปัญหา 10-Lookup ของ SaaS สำหรับผู้ส่งอีเมลในสหราชอาณาจักรและสหภาพยุโรป (2026)

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

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

เมื่อ SPF ล้มเหลวสำหรับธุรกิจที่ใช้เครื่องมือ SaaS ในสหราชอาณาจักรหรือสหภาพยุโรป สาเหตุที่น่าจะเป็นไปได้มากที่สุดคือกฎ RFC ที่คุณไม่เคยต้องคิดถึง: เกิน 10 DNS lookups SPF ไม่คืนค่า “fail” — มันคืนค่า PermError ซึ่งหมายความว่า record ถูกปฏิบัติเหมือนว่าไม่มีอยู่ อย่างน้อย 797,263 โดเมนเกินเส้นนั้นแล้ว อีก 2,119,539 อยู่ที่ 9–10 lookups พอดี — ห่างเพียงเครื่องมือหนึ่งตัวจากหน้าผาเดียวกัน

ทำไม SPF ถึงพังเมื่อคุณเพิ่มเครื่องมือ SaaS?

SPF ทำงานโดยการระบุเซิร์ฟเวอร์เมลที่ได้รับอนุญาตให้ส่งในนามโดเมนของคุณ ธุรกิจสมัยใหม่ไม่ได้ใช้เซิร์ฟเวอร์เมลของตัวเอง — พวกเขาใช้ Google Workspace สำหรับอีเมลภายใน Mailchimp สำหรับแคมเปญ HubSpot สำหรับลำดับการขาย Pipedrive สำหรับการสื่อสาร CRM แต่ละแพลตฟอร์มให้บรรทัด include: ให้วางใน DNS ของคุณ

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

คุณจะไม่เห็นสิ่งนี้ใน DNS panel ของคุณ ตัวนับเริ่มทำงานระหว่างการประเมินสด คุณอาจมีบรรทัด include: สามบรรทัดใน record ที่มองเห็นของคุณและยังอยู่ลึกสิบสอง lookups เพราะ SPF record ของแต่ละ vendor ดึง sub-includes ของตัวเอง

มีโดเมนกี่แห่งที่เกินขีดจำกัดแล้ว?

อย่างน้อย 797,263 นั่นคือการนับหลังจากที่เราแก้ไข SPF include: target ทุกรายการที่อ้างอิง 100 ครั้งขึ้นไป — 10,842 เป้าหมายที่แตกต่างกันครอบคลุม 95.2% ของการอ้างอิง include ทั้งหมด — และคำนวณราคา chain เต็มของแต่ละโดเมน การนับพื้นผิว (สิ่งที่คุณจะพบโดยการนับเฉพาะบรรทัดที่มองเห็นใน record) พบประมาณ 7,958 ตัวเลขที่คำนวณ chain ใหญ่กว่า 100 เท่า เพราะ ความเสียหายเกือบทั้งหมดมองไม่เห็นภายใน include targets

สถานการณ์ที่น่าจะส่งผลกระทบต่อธุรกิจในยุโรปมากที่สุด:

ผู้ให้บริการ hosting ของยุโรปและค่าเริ่มต้น SPF ที่อ่อนแอ

ผู้ให้บริการ hosting ที่คุณเริ่มต้นด้วยมีความสำคัญ — เพราะบางแห่งตั้งค่า SPF ค่าเริ่มต้นที่ใช้ lookups ของคุณไปหลายตัวก่อนที่คุณจะเชื่อมต่อเครื่องมือ SaaS ใดๆ

ในบรรดาผู้ให้บริการ hosting รายใหญ่ที่ใช้โดยโดเมนยุโรปในสำมะโนของเรา:

IONOS โดดเด่น: 1.0% ของโดเมนที่โฮสต์ใน IONOS มี DMARC ที่บังคับใช้ ซึ่งหมายความว่าส่วนใหญ่ไม่มีการตรวจสอบตัวตนของผู้ส่งที่มีความหมายเลย โดเมน OVH ทำได้ดีกว่าในการตั้งค่า SPF เข้มงวด (43.7%) แต่ยังตกลงมาที่ 2.2% สำหรับการบังคับใช้ DMARC — SPF เพียงอย่างเดียวโดยไม่มี DMARC ผูกกับ From: header ปกป้องเฉพาะ envelope ไม่ใช่สิ่งที่ผู้รับเห็น

Microsoft 365 เป็นข้อยกเว้นในทางดี: 85.0% ของโดเมนที่โฮสต์ใน Microsoft ใช้ SPF เข้มงวด ส่วนใหญ่เพราะ wizard ขั้นตอนเมลของ Microsoft ตั้งค่า -all ไว้เป็นค่าเริ่มต้น Google Workspace ตั้งค่า ~all (softfail) เป็นค่าเริ่มต้น ทิ้ง 92% ของโดเมนไว้โดยไม่มีการป้องกันที่เข้มงวด

วิธีวินิจฉัยความล้มเหลว SPF ของคุณใน 60 วินาที

การตรวจสอบที่เร็วที่สุดคือเครื่องมือฟรีที่ประเมิน lookup chain เต็ม — ไม่ใช่แค่ record ที่มองเห็น รัน nslookup -type=TXT yourdomain.com ที่ command line และนับทุก include: ที่คุณเห็น จากนั้นค้นหา record เหล่านั้นและนับของพวกเขา ถ้าคุณหมดนิ้วก่อนหมด includes คุณอยู่ในโซนอันตราย

วิธีที่เชื่อถือได้กว่า: ตรวจสอบโดเมนของคุณที่นี่ — scanner ประเมิน chain ที่แก้ไขเต็ม ตั้งธง PermError และแสดงกลไกใดที่ใช้งบประมาณ lookup ของคุณ

ผลการวินิจฉัยสามอย่าง:

• PermError — คุณเกินสิบแล้ว อีเมลทุกฉบับที่คุณส่งล้มเหลวการตรวจสอบ SPF ที่ผู้รับ
• ที่ 9–10 lookups — คุณอยู่บนหน้าผา การรวม SaaS ครั้งต่อไปทำให้คุณตกลงมา
• Softfail (~all) แทน hardfail (-all) — คุณอยู่ต่ำกว่าขีดจำกัดแต่ record ตั้งค่าอนุญาตเกินไปที่จะให้การป้องกันจริง ดู รายงาน SPF misconfiguration สำหรับภาพรวมทั้งหมดของ -all vs ~all

วิธีแก้ไข SPF เมื่อคุณใช้เครื่องมือ SaaS หลายตัว

มีสามวิธี ตามลำดับความถาวร:

1. ตรวจสอบและตัดแต่ง เริ่มต้นด้วยการระบุทุก include: ใน record ปัจจุบันของคุณ ลบแพลตฟอร์มที่คุณไม่ได้ใช้อีกต่อไป — ESP เก่า เครื่องมือ CRM จากสัญญาก่อนหน้า แพลตฟอร์มที่คุณทดสอบแต่ละทิ้ง สิ่งนี้ฟรีและมักกู้ lookups ได้หลายตัว แต่ละ include: ที่ลบออกอาจขจัด 1–3 sub-lookups

2. Flatten SPF record ของคุณ SPF flattening แก้ไข include: targets ทั้งหมดเป็น IP ranges ที่เบื้องหลังและเขียนโดยตรงใน record เป็กลไก ip4: และ ip6: กลไก IP ไม่เรียก lookups ดังนั้น record ที่ flatten แล้วสามารถระบุแหล่งส่งหลายสิบแห่งและยังคงอยู่ที่ศูนย์ lookups ข้อเสีย: คุณต้อง re-flatten เมื่อ vendor อัปเดต IP การส่งของตน ซึ่งเกิดขึ้นโดยไม่แจ้ง ธุรกิจส่วนใหญ่ใช้บริการ SPF flattening แบบจ่ายเงิน (PowerDMARC, EasyDMARC, Dmarcian และอื่นๆ เสนอสิ่งนี้) หรือสร้างขั้นตอนการตรวจสอบ

3. ใช้ SPF macros RFC 7208 macros ช่วยให้คุณสร้าง records ที่ทำ DNS lookup เดียวต่อการตรวจสอบและตอบสนองแบบไดนามิก แทนที่จะเป็น chain ของ includes Macros ต้องการการรองรับ DNS hosting และความพยายามในการใช้งาน แต่เป็นโซลูชันที่สะอาดทางสถาปัตยกรรมสำหรับองค์กรที่มีผู้ส่ง SaaS มาก

หลังจากแก้ไข SPF จับคู่กับ การบังคับใช้ DMARC — SPF โดยไม่มี DMARC ตรวจสอบตัวตนเฉพาะผู้ส่ง envelope ไม่ใช่ที่อยู่ header From: ที่ผู้รับเห็น

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

ทำไม SPF record ของฉันถึงผ่านเครื่องมือ DNS แต่ยังล้มเหลวใน email headers? เครื่องมือ DNS lookup ส่วนใหญ่นับเฉพาะกลไกที่มองเห็นใน record ของคุณเอง ไม่ใช่ sub-lookups ที่กลไกเหล่านั้นเรียก คุณสามารถมีบรรทัด include: สองบรรทัดและยังเกินขีดจำกัดถ้าแต่ละ record ของ vendor มีอีกหลายบรรทัด เฉพาะเครื่องมือที่คำนวณ chain (หรือเซิร์ฟเวอร์เมลที่รับ) ที่นับความลึกเต็ม ตรวจสอบโดเมนของคุณ เพื่อดูการนับ chain จริง

SPF ที่ล้มเหลวหมายความว่าอีเมลของฉันไปอยู่ในสแปมหรือไม่? PermError (lookups มากเกินไป) หมายความว่าฝั่ง SPF ของการตรวจสอบตัวตนคืนผลลัพธ์ที่ไม่มี — ไม่มีอยู่จริงๆ DMARC ประเมินทั้ง SPF และ DKIM ถ้า DKIM ผ่าน DMARC ยังสามารถผ่านแม้จะมี SPF PermError ถ้าทั้งคู่ไม่ผ่าน DMARC ล้มเหลว และผลลัพธ์ขึ้นอยู่กับนโยบาย DMARC ของคุณ ที่ p=none อีเมลยังส่งได้แต่ความล้มเหลวถูกบันทึก ที่ p=quarantine หรือ p=reject อีเมลถูกกรองหรือถูกตีกลับ แก้ไข SPF เพื่อไม่ต้องพึ่ง DKIM เพียงอย่างเดียว

SaaS stack ทั่วไปใช้ lookups กี่ตัว? p99 SPF record ในสำมะโนของเรานั่งอยู่ที่ 9 lookups — ถึงขีดจำกัดพอดี — ก่อนเพิ่มอะไร Google Workspace record เพิ่ม 3–4 lookups Mailchimp เพิ่ม 1–2 HubSpot เพิ่ม 1–3 ขึ้นอยู่กับการกำหนดค่าปัจจุบัน เครื่องมือกระแสหลักสามตัวบวกค่าเริ่มต้นของผู้ให้บริการ hosting มักพอที่จะเกินสิบ

SPF flattening ปลอดภัยหรือไม่? ใช่ ถ้าคุณทำให้เป็นปัจจุบัน Flattening แปลง include: chains เป็น IP ranges คงที่ — ถ้า vendor หมุน IP การส่งและคุณไม่ re-flatten คุณจะเริ่มปฏิเสธเมลของพวกเขา ธุรกิจส่วนใหญ่ใช้บริการ flattening ที่จัดการซึ่งตรวจสอบการเปลี่ยนแปลง IP แทนการดูแลด้วยตนเอง

SPF ของฉันเป็นแบบนี้มาหลายปีแล้ว ทำไมถึงล้มเหลวกะทันหัน? เพราะ vendor ของคุณอัปเดต SPF record ของพวกเขา ไม่ใช่ของคุณ ทุกครั้งที่แพลตฟอร์ม SaaS เพิ่ม IP range การส่งใหม่หรือซ้อน include อื่น ค่าใช้จ่าย chain ของคุณเพิ่มขึ้นโดยไม่มีการเปลี่ยนแปลงจากปลายของคุณ ขีดจำกัด 10-lookup ถูกประเมินสดเมื่อรับข้อความ ดังนั้นการเปลี่ยนแปลง vendor ในเช้าวันอังคารสามารถทำลาย SPF ของคุณภายในบ่ายวันอังคาร

การแก้ไข SPF ปรับปรุงการส่งอีเมลหรือไม่? มันลบแหล่งที่มาของความล้มเหลวในการตรวจสอบตัวตน ซึ่งเป็นข้อกำหนดเบื้องต้นสำหรับการส่งที่สม่ำเสมอ — โดยเฉพาะเนื่องจาก Google และ Yahoo บังคับใช้ DMARC alignment สำหรับผู้ส่งจำนวนมาก SPF เพียงอย่างเดียวไม่ใช่ภาพทั้งหมด: จับคู่กับ DKIM และ DMARC สำหรับการตรวจสอบตัวตนอีเมลเต็มรูปแบบ

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

ถ้าคุณไม่แน่ใจว่า SPF record ของคุณเกินขีดจำกัด lookup — หรือตั้งค่าอ่อนเกินไปที่จะปกป้องโดเมนของคุณ — รันการตรวจสอบฟรี มันประเมิน chain ที่แก้ไขเต็มและแสดงว่างบประมาณถูกใช้ไปที่ไหน

ตรวจสอบโดเมนของคุณ → · แก้ไข SPF → · รายงาน SPF PermError → · รายงาน SPF misconfiguration → · โมเดลความครบกำหนดการนำ SPF ไปใช้ → · แก้ไข DMARC → · เฉพาะข้อมูลรวม ข้อมูลจัดเก็บและประมวลผลในสหภาพยุโรป