กลไก SPF ptr คืออะไร — และทำไมยังอยู่ใน 950,631 บันทึก? (2026)

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

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

ptr คือกลไก SPF ที่อนุญาตผู้ส่งโดยการ reverse-DNS lookup — และมาตรฐาน SPF เองได้บอกว่า “อย่าใช้มัน” ตั้งแต่ปี 2014 ผ่านไป 12 ปี 950,631 โดเมนยังคงเผยแพร่มัน นั่นคือประมาณ 1 ใน 146 ของ 139 ล้านบันทึก SPF บนอินเทอร์เน็ตที่ถือกลไกที่ข้อกำหนดเลิกใช้ก่อนที่โดเมนบางส่วนเหล่านั้นจะถูกลงทะเบียน

ptr ถูกออกแบบมาเพื่อทำอะไร

ptr บอกว่า: “ยอมรับเมลจากเซิร์ฟเวอร์ใดก็ตามที่ reverse DNS resolve กลับไปยังโดเมนของฉัน” มันฟังดูสง่างาม — ไม่มีรายการ IP ที่ต้องดูแล ในทางปฏิบัติมันต้องการให้ผู้รับทำ reverse lookup บน connecting IP จากนั้นยืนยันไปข้างหน้าทุก hostname ที่กลับมา RFC 7208 (§5.5) เลิกใช้มันด้วยคำพูดธรรมดา: กลไกนี้ “ช้า ไม่น่าเชื่อถือเท่ากลไกอื่นในกรณีข้อผิดพลาด DNS และวางข้อกำหนดทรัพยากรขนาดใหญ่บนเซิร์ฟเวอร์ชื่อ .arpa” — และสั่งว่ามัน “SHOULD NOT ถูกใช้”

ทำไมมันยังเป็นกับดักในปี 2026

สามเหตุผลที่กลไกที่เลิกใช้แล้ว 12 ปียังคงสำคัญ:

มันเผาผลาญงบประมาณ lookup ของคุณ ทุก ptr นับต่อเพดานแข็งของ SPF ที่ 10 DNS lookups ต่อการตรวจสอบ — ขีดจำกัดที่เมื่อเกินแล้ว ยกเลิกบันทึกทั้งหมดด้วย PermError กลไกที่ไม่ทำอะไรที่น่าเชื่อถือยังคงมีค่าจากงบประมาณที่ include: จริงของคุณต้องการ
มันล้มเหลวอย่างไม่แน่นอน Reverse DNS คือมุมที่ดูแลน้อยที่สุดของเครือข่ายส่วนใหญ่ เมื่อ ptr lookup หมดเวลาหรือการยืนยันไปข้างหน้าล้มเหลว เมลที่ถูกต้องของคุณสูญเสีย SPF pass ที่มันพึ่งพา
ผู้รับบางรายข้ามมันทั้งหมด เนื่องจากมาตรฐานเลิกใช้มัน การใช้งานบางอย่างเพียงแค่ละเว้น ptr — ดังนั้นผู้ส่งที่ถูกตั้งใจจะอนุญาตไม่เคยได้รับการป้องกันตั้งแต่แรก

มันมาจากที่ไหน

ไม่มีใครเลือก ptr ในวันนี้ มันมาโดยการสืบทอด: คู่มือการตั้งค่าที่เขียนในปี 2009 เทมเพลตที่คัดลอกจาก server config เก่า บันทึก “ที่ใช้งานได้” ที่ย้ายอย่างสมบูรณ์ผ่านการย้ายโฮสติ้งสามครั้ง นั่นคือรูปแบบที่สำมะโนของเราเห็นจากกลไกที่เลิกใช้แต่ยังมีอยู่ทุกอัน: คำแนะนำเก่าไม่ตาย มันถูกคัดลอก-วาง โดเมนที่พา ptr ไม่ได้ประมาท — พวกเขาทำตามคำแนะนำที่เกษียณแล้ว 12 ปีที่แล้ว

วิธีแก้ไข — ฟรี ห้านาที

ค้นหาบันทึก SPF ของคุณ (dig TXT yourdomain.com หรือ ตรวจสอบฟรี)
ถ้ามี ptr ระบุว่าเซิร์ฟเวอร์ใดพึ่งพามัน
แทนที่ ptr ด้วยรูปแบบที่แม่นยำ: บล็อก ip4:/ip6: สำหรับเซิร์ฟเวอร์ที่คุณควบคุม หรือ include: ที่ผู้ให้บริการของคุณบันทึก
ขณะที่คุณอยู่ในนั้น ยืนยันว่าบันทึกลงท้ายด้วยตัวกำหนดจริง — ดู ~all เทียบกับ -all

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

ptr ใน SPF record หมายความว่าอะไร? มันอนุญาตเซิร์ฟเวอร์ใดก็ตามที่ reverse DNS resolve เข้าสู่โดเมนของคุณ RFC 7208 §5.5 เลิกใช้มันในปี 2014 ว่าช้าและไม่น่าเชื่อถือ และบอกว่า SHOULD NOT ถูกใช้ — แต่ 950,631 โดเมนยังเผยแพร่มัน ณ วันที่ 2026-06-29

กลไก SPF ptr ถูกต้องหรือไม่? มันยังคง parse ได้ และผู้รับบางรายยังประเมินมัน — แต่มาตรฐานแนะนำต่อต้านมันในทุกกรณี ผู้รับบางรายละเว้นมัน และมันใช้หนึ่งใน ten DNS lookups ของคุณ ไม่มีการกำหนดค่าสมัยใหม่ที่ ptr เป็นคำตอบที่ถูกต้อง

ฉันควรใช้อะไรแทน ptr? บล็อก ip4:/ip6: สำหรับเซิร์ฟเวอร์ที่คุณควบคุม หรือ include: ที่ผู้ให้บริการของคุณบันทึก ทั้งสองเป็น deterministic เร็ว และน่าเชื่อถือ — ทุกอย่างที่ ptr ไม่ใช่

ptr นับต่อขีดจำกัด SPF 10 lookup หรือไม่? ใช่ — ทุก ptr มีค่าอย่างน้อยหนึ่งใน ten DNS lookups ที่ผู้รับจะทำก่อนที่จะยอมแพ้ด้วย PermError บนบันทึกที่ซ้อนกันด้วยกลไก include: แล้ว กลไกที่ตายแล้วอาจเป็นสิ่งที่ผลักให้คุณเกิน

ตรวจสอบบันทึกของคุณสำหรับผี

กลไกที่เลิกใช้แล้ว 12 ปี ยังคงนั่งอยู่ใน DNS ของคุณ เป็นประเภทที่ไม่มีใครมองหา การมองหาใช้เวลาครึ่งนาที

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