PTR ต้องตรวจที่ IP สาธารณะที่ส่งอีเมลถึงปลายทาง ไม่ใช่เลือก IP เว็บของร้านโดยอัตโนมัติ ถ้าใช้ relay ผู้ให้บริการอาจส่งจากอีกที่อยู่ และการตั้ง DNS ย้อนกลับมักต้องให้ผู้ดูแล IP ดำเนินการ การเพิ่ม TXT ในโดเมนไม่ใช่การแทน PTR
หาจุดส่งที่ยืนยันได้
ใช้บันทึก SMTP หรือส่วนหัวจากผู้รับที่เชื่อถือได้ จดวันและเส้นทาง เพราะบริการร่วมอาจมีหลาย IP หากยังไม่รู้แหล่งจริงให้ขอผู้ให้บริการยืนยันก่อน คู่มือ Gmail มีข้อกำหนดความสัมพันธ์ระหว่างชื่อย้อนกลับและการค้นเดินหน้า แต่ผลของ IP เดียวไม่ยืนยันทั้งกลุ่ม
- ตรวจ PTR ของ IP ที่พบ แล้วตรวจ A หรือ AAAA ของชื่อนั้นว่ามีความสัมพันธ์ตามข้อกำหนดปลายทางหรือไม่
- ถ้าผิด ให้หาเจ้าของโครงสร้าง IP และส่งข้อมูลที่ชัดเจน ผู้จดโดเมนอาจไม่มีสิทธิ์แก้ระเบียนย้อนกลับ
- หลังแก้ ส่งใหม่ผ่านทางเดียวกันและตรวจการตอบรับพร้อมการยืนยันอื่น อย่าใช้ PTR ผ่านเป็นคำรับรองว่าอีเมลต้องอยู่ Inbox
ตัวอย่างสมมติของเว็บใหม่
บริษัทเปลี่ยนเซิร์ฟเวอร์ฟอร์มและให้ส่งตรงจากเครื่องใหม่ เว็บไซต์เปิดได้แต่ข้อความมีปัญหา ผู้ดูแลต้องยืนยัน IP ส่งและประสานเจ้าของ IP การแก้ A ของหน้าเว็บอย่างเดียวอาจไม่แตะ PTR เลย ตัวอย่างนี้ไม่ระบุรหัสปฏิเสธที่ใช้กับ PTR ทุกกรณี
สำหรับบริการจดหมายข่าวแบบจัดการ ร้านอาจไม่ต้องตั้ง PTR เอง แต่ควรทราบใครรับผิดชอบและข้อมูลใดขอได้ อย่านำคู่มือเครื่องส่วนตัวไปใช้กับระบบร่วมโดยไม่ตรวจขอบเขต และอย่าถือว่าซื้อ IP เฉพาะแล้วได้ความเชื่อถือทันที เพราะเพิ่มหน้าที่ดูแลและต้องมีเหตุผลใช้งานจริง
เขียนผลให้ตรงตัวตน
รายงานระบุ IP ชื่อที่ตรวจ และเวลาที่พบความสัมพันธ์ หากทางส่งมีหลายแหล่งให้บอกว่าตรวจครบหรือไม่ DNS ถูกต้องของเว็บไซต์ไม่พิสูจน์ DNS ของอีเมล ขณะเดียวกัน PTR ถูกต้องก็ไม่บอกความต้องการของเนื้อหา ต้องใช้หลักฐานแต่ละส่วนในคำถามที่มันตอบได้เท่านั้น
แหล่งข้อมูลและการตรวจสอบ
RFC 5321: ตัวตนเซิร์ฟเวอร์ SMTP
ทดสอบอีเมลของคุณ กับกล่องทดสอบที่มีให้ ผลเป็นเพียงตัวอย่างที่สังเกต ไม่รับประกันกล่องของลูกค้าทั้งหมด อ่านขอบเขตใน วิธีทดสอบ และตรวจรายชื่อบริการที่รองรับในหน้าทดสอบปัจจุบัน