SPF PermError หลังเพิ่มบริการอาจเกิดจากรูปแบบระเบียนหรือขีดจำกัดการค้น DNS ต้องยืนยันเหตุผลก่อนแก้ การนับ include ที่มองเห็นในบรรทัดแรกไม่พอ เพราะ include และ redirect อาจพาไปยังระเบียนอื่น ต้องตรวจเส้นทางประเมินของโดเมนที่ใช้จริง
เริ่มจากระเบียนที่ผู้รับตรวจ
เก็บ smtp.mailfrom และผลของข้อความ แล้วตรวจ TXT ที่เป็นทางการของโดเมนนั้น RFC 7208 จำกัดจำนวนกลไกและตัวปรับที่ทำให้ค้น DNS ระหว่างประเมินไว้สิบรายการ รวมการซ้อน ไม่ใช่ทุกคำใน SPF จะถูกนับแบบเดียวกัน จึงต้องใช้การวิเคราะห์ตามมาตรฐานแทนคาดจากจำนวนแอป
- เก็บค่าปัจจุบันและเจ้าของแต่ละแหล่งส่ง แยกบริการใหม่ที่เพิ่งเพิ่มออกจากระบบเก่าที่ยังต้องใช้
- ตรวจ include และ redirect แบบต่อเนื่องพร้อมระบุจุดผิด ถ้าพบรูปแบบผิดให้แก้ตรงนั้น ไม่เรียกทุก PermError ว่าเกินขีดจำกัด
- ลบเฉพาะแหล่งที่ยืนยันว่าเลิกใช้แล้ว หากใช้วิธีปรับแต่งของผู้ให้บริการให้ทำตามคำแนะนำ ไม่คัด IP ปัจจุบันมาเก็บถาวรโดยไม่มีผู้ดูแล
ตัวอย่างสมมติของระบบเก่า
ร้านมีบริการการตลาดเก่าสองราย หนึ่งรายยังส่งอัตโนมัติอีกรายยกเลิกแล้ว เมื่อเพิ่มรายใหม่จึงต้องถามเจ้าของระบบก่อนลบ การเอาค่าเก่าทั้งหมดออกเพื่อให้คะแนนผ่านอาจทำให้ข้อความที่ยังจำเป็นเสีย ตัวอย่างนี้ไม่ระบุจำนวนค้นของผู้ให้บริการใด ต้องตรวจค่าจริง
ตรวจด้วยว่ากำลังแก้ authoritative DNS ที่ใช้งานอยู่ ไม่ใช่หน้าของผู้จดโดเมนที่ไม่ได้ให้บริการ DNS การเห็นค่าถูกในหน้าจอหนึ่งยังไม่พิสูจน์ว่าระบบภายนอกใช้ค่านั้น อย่าสร้างเวลารอคงที่ครอบคลุมทุกกรณี ให้ตรวจการปรากฏของค่าที่ต้องการและการใช้จริงของข้อความใหม่
ยืนยันให้ครบแหล่ง
หลังแก้ ส่งฉบับใหม่จากแหล่งสำคัญและตรวจ SPF พร้อม DKIM กับ DMARC การผ่านของแหล่งหนึ่งไม่ปิดงานทั้งโดเมน ถ้ายังมีผลต่างให้เก็บข้อมูลแต่ละฉบับแยกกัน รายงานต้องชี้ว่าระบบใดถูกตรวจแล้วและระบบใดยังขาดหลักฐาน ไม่ใช้การลดจำนวนระเบียนเป็นเป้าหมายโดยไม่คำนึงถึงงานธุรกิจ
แหล่งข้อมูลและการตรวจสอบ
RFC 7208: ขีดจำกัด DNS ของ SPF
ทดสอบอีเมลของคุณ กับกล่องทดสอบที่มีให้ ผลเป็นเพียงตัวอย่างที่สังเกต ไม่รับประกันกล่องของลูกค้าทั้งหมด อ่านขอบเขตใน วิธีทดสอบ และตรวจรายชื่อบริการที่รองรับในหน้าทดสอบปัจจุบัน