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

"SPF Record Not Found" — แต่คุณมีอยู่? 5 สาเหตุที่แท้จริง (2026)

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

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

ถ้า checker บอกว่า “SPF record not found” แต่คุณแน่ใจว่าคุณเผยแพร่แล้ว record มักจะมองไม่เห็นแทนที่จะหายไป: 1,013,416 โดเมน — ประมาณหนึ่งในทุก 138 ของที่พยายาม SPF — เผยแพร่ SPF records สองรายการขึ้นไป เป็น PermError (RFC 7208 §3.2) ที่ checkers หลายรายรายงานว่า not-found ตาม census ของ Defaults.Exposed จากโดเมน 261 ล้านโดเมน

มีห้าสาเหตุที่แท้จริง ทั้งหมดแก้ไขได้ในนั่งครั้งเดียว: host ผิด duplicate record type DNS หรือ quoting ที่ผิดเพี้ยน nameservers ที่ไม่สม่ำเสมอ หรือ length/CNAME collision ด้านล่าง: การทดสอบ 60 วินาทีสำหรับแต่ละรายการ ในลำดับที่ต้องตรวจสอบ แล้วขั้นตอนการแก้ไข

คุณแน่ใจหรือว่า record มีอยู่จริงๆ?

เริ่มด้วยความเป็นไปได้ที่น่าอาย เพราะมันเป็นอย่างที่พบบ่อยที่สุดอย่างมาก: จากโดเมน 261,086,232 ที่ผ่านการให้คะแนนใน census ของ Defaults.Exposed 121,145,609 — 46.4% — ไม่มี SPF record เลย หลายกรณี “แต่ฉันตั้งค่าสิ่งนี้” กลายเป็น record ที่เพิ่มไปยัง staging zone หรือ DNS provider เก่าที่ไม่ได้เป็น authoritative แล้ว ตรวจสอบ DNS provider ที่ nameservers ของคุณชี้ไปจริงๆ (มักไม่ใช่ registrar ของคุณ) สำหรับ TXT record ที่ขึ้นต้นด้วย v=spf1 ถ้าไม่มีอยู่จริงๆ ข้ามการสืบสวนและไปตรงที่ แก้ไข SPF record ของคุณ

จะตรวจสอบ SPF record อย่างถูกต้องได้อย่างไร?

Web checkers query DNS ผ่าน caching resolver ของตัวเอง เพื่อดูความจริง ถาม authoritative nameserver ของโดเมนของคุณโดยตรง:

# ค้นหา authoritative nameservers
dig NS yourdomain.com +short

# ถามหนึ่งในนั้นโดยตรงสำหรับ TXT records
dig TXT yourdomain.com @ns1.yourdnshost.com +short

บน Windows: nslookup -type=TXT yourdomain.com ns1.yourdnshost.com

กฎการตีความสองข้อ ประการแรก นับบรรทัดที่ขึ้นต้นด้วย v=spf1 — จำนวนสำคัญพอๆ กับเนื้อหา ประการที่สอง ตรวจสอบว่าคุณ query ชื่อที่ถูกต้อง: ผู้รับประเมิน SPF กับโดเมนใน Return-Path (RFC5321.MailFrom “envelope from”) — ไม่ใช่ From address ที่ผู้รับเห็น ถ้า newsletter tool ของคุณ bounce mail ผ่าน bounce.yourdomain.com record ที่สมบูรณ์แบบที่ apex ไม่ใช่ record ที่ผู้รับค้นหา

ห้าสาเหตุที่แท้จริงคืออะไร?

ข้อมูล ณ 2026-06-29

1. Record อยู่ที่ host ผิดหรือไม่?

คลาสสิก: SPF เพิ่มที่ mail.yourdomain.com เมื่ออีเมลอ้างว่ามาจาก yourdomain.com หรือในทางกลับกัน SPF ไม่ inherit ลงมา — record ที่ apex ไม่บอกอะไรเกี่ยวกับ subdomains และในทางกลับกัน เผยแพร่ที่ชื่อที่แน่นอนใน Return-Path ของคุณ vendor ที่ส่งจาก bounce subdomain ของตัวเองต้องการ record บน subdomain นั้น — มักเป็น CNAME หรือ TXT ที่ vendor ให้ (GoDaddy SPF setup guide แสดงตำแหน่งของ fields เหล่านี้)

2. คุณมี SPF records สองรายการหรือไม่?

สาเหตุหลัก และ error message ที่ misleading ที่สุดใน email authentication RFC 7208 §3.2 ชัดเจน: โดเมนต้องมี SPF record เพียงหนึ่งรายการ สองรายการขึ้นไปคือ PermError — ผู้รับถือว่า SPF ของคุณเป็นโมฆะ Checkers บางรายรายงานสถานะนั้นอย่างถูกต้อง (“multiple records found”) รายอื่นรายงาน net effect: ไม่พบ SPF record ที่ถูกต้อง คุณเห็น record ใน panel ของคุณและสรุปว่า checker เสียหาย มันไม่ใช่ — คุณมี record มากเกินหนึ่งรายการ

census พบ 1,013,416 โดเมนที่มี SPF records สองรายการขึ้นไป — ประมาณหนึ่งในทุก 138 ของโดเมนที่พยายาม SPF — ทุกรายการที่ SPF ปิดอยู่จริง มักเกิดขึ้นระหว่างการเปลี่ยน provider: wizard ของ provider ใหม่เพิ่ม record ใหม่แทนที่จะแก้ไขอันเก่า การแก้ไขคือการรวม ไม่ใช่ record ที่สอง: รวมทุกอย่างลงใน v=spf1 … ~all บรรทัดเดียวและลบส่วนที่เหลือ data report ของเรา SPF records สองรายการเท่ากับไม่มี อธิบายว่าโดเมนล้านรายการมาถึงที่นี่ได้อย่างไร ถ้ามันเริ่มหลัง migration ดู SPF stopped working after switching provider ขณะรวม อย่า concatenate ทุก include: อย่างตาบอด — แต่ละรายการใช้ DNS lookups กับขีดจำกัดที่เข้มงวด 10 รายการของ SPF ซื้อ not-found สำหรับ PermError: too many DNS lookups

3. คุณเผยแพร่ record type ผิด — หรือ UI ทำให้เสียหรือไม่?

SPF ยุคแรกมี DNS record type ของตัวเอง (type 99 ชื่อตรงๆ ว่า “SPF”) มันถูก deprecated: RFC 7208 กำหนด TXT และผู้รับไม่ query type 99 DNS panels บางรายยังเสนอ “SPF” ใน dropdown record-type เลือกมันและ record ของคุณเป็นจริง ถูกต้อง และมองไม่เห็น ตรวจสอบ type column และ republish เป็น TXT

น้องของมันที่ subtle คือ quoting การวาง value ที่มี quotes ลงใน field ที่เพิ่ม quotes ของตัวเองทำให้ได้ ""v=spf1 …"" — ซึ่งไม่ขึ้นต้นด้วย v=spf1 อีกต่อไป ดังนั้นสำหรับ verifier มันไม่มีอยู่ dig output ของคุณแสดงความจริง DNS panel มักซ่อนมัน cosmetically

4. มัน “ยัง propagating” จริงหรือ?

“รอ 24–48 ชั่วโมงเพื่อ propagate” คือคำแนะนำที่ over-prescribed ที่สุดใน DNS Propagation คือเพียง caches ที่หมดอายุ: เมื่อ TTL ของ record หมดอายุ (โดยทั่วไป 1 ชั่วโมง ไม่ค่อยมากกว่า 24) ทุก resolver สามารถเห็นคำตอบใหม่ ยังไม่พบหลังจาก 24 ชั่วโมง? Propagation ไม่ใช่สาเหตุ

สองผู้ต้องสงสัยจริง: negative caching — resolver ที่ค้นคุณ ก่อน ที่คุณเพิ่ม record cache คำตอบ “ไม่มี record นั้น” จนกว่า negative TTL จะหมดอายุ — และ nameservers ที่ไม่สม่ำเสมอ หลัง migration ซึ่ง domain ยังระบุ nameservers ของ provider เก่าควบคู่กับใหม่และโลกครึ่งหนึ่งอ่าน zone ที่คุณไม่ได้แก้ไขอีกต่อไป Query แต่ละ nameserver ที่ระบุโดยตรง ถ้าคำตอบต่างกัน คุณพบแล้ว แก้ไข NS delegation ของ registrar เพื่อให้เฉพาะ provider ที่คุณแก้ไขจริงเป็น authoritative

5. Record ยาวเกินไป หรือถูก CNAME block หรือไม่?

string เดียวใน TXT record จำกัดที่ 255 ตัวอักษร SPF records ที่ยาวกว่าถูกกฎหมายแต่ต้องแบ่งเป็น quoted strings หลายรายการ ภายใน record เดียว — และ DNS provider interfaces มักทำการ split ผิดพลาด ตัด value หรือแบ่งกลางกลไกเพื่อให้ไม่ parse อีกต่อไป ถ้า record ของคุณยาว ตรวจสอบ dig output สำหรับ value ที่หยุดกลางๆ

แยกจากกัน DNS ห้าม TXT record ที่ชื่อที่มี CNAME อยู่แล้ว ถ้า mail.yourdomain.com เป็น CNAME ไปยัง provider ของคุณ คุณไม่สามารถใส่ SPF ที่นั่นด้วย — บาง panels รับมันแล้ว serve เฉพาะ CNAME วาง record ที่ CNAME ชี้ไป (ถ้าคุณควบคุมมัน) หรือปรับโครงสร้างเพื่อให้ชื่อที่ส่งไม่ใช่ CNAME Providers ที่มี TXT handling สะอาดทำทั้งสองอย่างง่ายกว่า — ดู Cloudflare SPF setup guide

จะแก้ไขได้อย่างไร ทีละขั้นตอน?

1. รัน free scan ที่ defaults.exposed — มันอ่าน DNS live ของคุณและบอกว่าคุณอยู่ในสถานะใดในห้าสถานะก่อนที่คุณจะแตะสิ่งใด
2. ยืนยันว่า nameservers ไหน authoritative (dig NS) และว่าทุกรายการเห็นตรงกัน
3. Query TXT ที่ authoritative nameserver สำหรับ Return-Path domain ที่แน่นอน
4. นับบรรทัด v=spf1: ศูนย์ → เผยแพร่หนึ่งรายการ สองรายการขึ้นไป → รวมเป็นหนึ่ง
5. ตรวจสอบว่า type คือ TXT ค่าขึ้นต้นด้วย v=spf1 พอดี และไม่มี stray quotes หรือ truncation
6. รอหนึ่ง TTL แล้วสแกนอีกครั้งเพื่อยืนยันว่ามัน resolve อย่างสะอาดทุกที่

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

ทำไม checker ถึงบอกว่า “not found” ทั้งที่ฉันเห็น record ใน DNS panel? มักเป็นสาเหตุ 2 หรือ 4: v=spf1 record ที่สองทำให้ทั้งคู่เป็นโมฆะ — PermError ที่บาง tools รายงานว่า not-found สถานะที่ 1,013,416 โดเมนอยู่ ณ 2026-06-29 — หรือ panel ของคุณไม่ใช่ DNS ที่ authoritative จริงๆ

Checkers จะเห็นการแก้ไขของฉันเร็วแค่ไหน? หนึ่ง TTL — โดยทั่วไปหนึ่งชั่วโมง มากสุด 24 เกินนั้น “propagation” ไม่ใช่คำอธิบาย ตรวจสอบห้าสาเหตุใหม่ เริ่มจากความสม่ำเสมอของ nameserver

ฉันควรใช้ “SPF” record type ที่ DNS panel ของฉันเสนอหรือไม่? ไม่ Type 99 ถูก deprecated; RFC 7208 กำหนด TXT เท่านั้น type-99 record มองไม่เห็นสำหรับผู้รับสมัยใหม่

ตอนนี้พบ record แล้ว — ทำไมอีเมลของฉันยังล้มเหลว SPF? เพราะ SPF ถูกตรวจสอบกับ Return-Path domain ไม่ใช่ From header และ record ต้องระบุเซิร์ฟเวอร์ที่ส่งให้คุณจริงๆ พบแล้วคือขั้นตอนแรก คู่มือ แก้ไข SPF record ของคุณ ครอบคลุมการผ่าน

การไม่มี SPF record เป็นเรื่องปกติจริงๆ หรือ? ใช่ — 121,145,609 โดเมน 46.4% ของ 261,086,232 ที่ผ่านการให้คะแนนใน census ของ Defaults.Exposed (ณ 2026-06-29) ไม่มี SPF เลย Not-found คือสถานะ default ของอินเทอร์เน็ต

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

เมื่อ record resolve อย่างสะอาด รัน scan อีกครั้งและส่ง graded report ให้เจ้าของธุรกิจหรือลูกค้าที่โดเมนนี้เป็นของ มันแสดงในภาษาอังกฤษธรรมดาว่าอะไรที่เสีย สิ่งที่คุณแก้ไข และที่โดเมนอยู่ตอนนี้ — หลักฐานที่พวกเขาจะถูกขอสำหรับการต่ออายุ cyber-insurance และ supplier security questionnaires report คือใบเสร็จสำหรับงาน

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

ดูว่าโดเมนของคุณอยู่ในสถานะ not-found ใดในห้าสถานะ — แบบส่วนตัวและเจ้าของเท่านั้น

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