Defaults.Exposed › การแก้ไข › Reverse DNS (PTR)

วิธีแก้ไข Reverse DNS (PTR)

Reverse DNS คือป้ายประจำตัวสำหรับเซิร์ฟเวอร์ที่ส่งอีเมลธุรกิจของคุณ เมื่อผู้ให้บริการที่รับอย่าง Gmail หรือ Microsoft 365 ค้นหาว่าใครอยู่เบื้องหลังที่อยู่ที่ส่งและได้ชื่อที่ตรวจสอบได้ อีเมลของคุณดูถูกกฎหมาย เมื่อไม่มีป้าย — หรือชื่อและหมายเลขไม่ตรงกัน — ใบแจ้งหนี้และใบเสนอราคาจริงๆ ของคุณจะถูกปฏิบัติอย่างน่าสงสัยและถูกทิ้งหรือปฏิเสธเงียบๆ

สรุปสำหรับธุรกิจของคุณ: ใบแจ้งหนี้ ใบเสนอราคา และการตอบกลับลูกค้าของคุณลงเอยในสแปมเงียบๆ หรือไม่มาถึงเลย — ดังนั้นดีลหยุด การชำระเงินมาช้า และลูกค้าคิดว่าคุณเพิกเฉยพวกเขา ไม่มีอะไรแสดงขึ้นเป็นข้อผิดพลาดที่คุณจะสังเกตเห็น

สิ่งนี้อาจทำให้คุณเสียค่าใช้จ่าย

• คุณส่งใบเสนอราคาให้ผู้มีโอกาสเป็นลูกค้าที่น่าสนใจ มันตกอยู่ในสแปม และพวกเขาไปกับคู่แข่งที่ 'ตอบรับจริง' — และคุณไม่รู้เลยว่าอีเมลไม่ได้ไปถึง
• ใบแจ้งหนี้ถึงลูกค้าหายไปในขยะ การชำระเงินมาช้าหลายสัปดาห์ และกระแสเงินสดของคุณได้รับผลกระทบเพราะไม่มีใครเคยเห็นอีเมล
• ลูกค้าบ่นว่าคุณไม่ได้ตอบกลับพวกเขา — แต่คุณทำ ผู้ให้บริการเมลของพวกเขาทิ้งการตอบกลับของคุณเงียบๆ เพราะเซิร์ฟเวอร์ที่ส่งของคุณไม่สามารถพิสูจน์ว่าเป็นใคร
• โดเมนของคุณผ่านการตรวจสอบความปลอดภัยของลูกค้าใหม่ในทุกอย่างอื่น จากนั้นถูกตั้งค่าสถานะเพราะเซิร์ฟเวอร์เมลของคุณไม่มีตัวตนที่เหมาะสม — เรื่องเล็กน้อยที่ทำให้คุณดูไม่ระมัดระวัง
• คุณย้ายไปยัง VPS ราคาถูกหรือแอพใหม่เพื่อส่งจดหมายข่าวและใบแจ้งหนี้ และอัตราการส่งมอบของคุณลดลงชั่วข้ามคืน — เพราะเซิร์ฟเวอร์ส่งใหม่นั้นไม่มีป้ายประจำตัว Reverse DNS และผู้ให้บริการรายใหญ่ไม่เชื่อถืออีกต่อไป

เหตุใดจึงสำคัญ ผู้ให้บริการอีเมลรายใหญ่ทุกรายตรวจสอบตัวตนของเซิร์ฟเวอร์ที่ส่งเมลของคุณ และพวกเขาตรวจสอบในทุกข้อความ หากเซิร์ฟเวอร์นั้นไม่สามารถพิสูจน์ว่าเป็นใคร — หรือหากชื่อและหมายเลขขัดแย้งกัน — อีเมลธุรกิจจริงๆ ของคุณจะถูกปฏิบัติเหมือนอาจเป็นสแปม คุณสูญเสียการตอบกลับ การชำระเงิน และความไว้วางใจ และเพราะไม่มีอะไรตีกลับ คุณมักไม่เคยรู้ว่าทำไม

เวอร์ชันสั้น

เมื่อธุรกิจของคุณส่งอีเมล มันออกไปจากเซิร์ฟเวอร์เมล และเซิร์ฟเวอร์ทุกเครื่องบนอินเทอร์เน็ตมีที่อยู่ตัวเลข — IP Reverse DNS (ระเบียน “PTR”) คือป้ายชื่อของเซิร์ฟเวอร์นั้น: ช่วยให้ใครก็ตามที่เห็นตัวเลขค้นหาชื่อที่เหมาะสมเบื้องหลัง เช่น mail.yourcompany.com

ผู้ให้บริการรับรายใหญ่ — Gmail, Microsoft 365, Yahoo — ตรวจสอบป้ายนั้นในทุกข้อความที่คุณส่ง เซิร์ฟเวอร์ที่ตั้งชื่อตัวเองได้ และที่ชื่อและหมายเลขเห็นด้วยกัน ดูเหมือนเซิร์ฟเวอร์เมลที่ถูกกฎหมาย เซิร์ฟเวอร์ที่ไม่มีป้าย หรือป้ายที่ไม่ตรงกัน ดูเหมือนเครื่องนิรนามที่ใช้แล้วทิ้งที่สแปมเมอร์ใช้ ดังนั้นใบแจ้งหนี้และใบเสนอราคาจริงๆ ของคุณเริ่มต้นทุกการสนทนาภายใต้ความสงสัย — และหลายอย่างแพ้

ส่วนที่น่าหงุดหงิดคือไม่มีอะไรบอกคุณว่ามันเกิดขึ้น ไม่มีการตีกลับ ไม่มีข้อผิดพลาด อีเมลของคุณแค่ทำผลงานได้น้อยอย่างเงียบๆ

สิ่งนี้อาจทำให้คุณสูญเสียอะไร

เหล่านี้คือวิธีประจำวันที่ระเบียน Reverse DNS ที่หายไปหรือไม่ตรงกันกลายเป็นเงินและความไว้วางใจที่ออกไปจากประตู เราไม่เคยตั้งชื่อธุรกิจจริง — เหล่านี้คือรูปแบบที่เราเห็นในข้อมูล

• ใบเสนอราคาที่ไม่เคยลง คุณส่งใบเสนอราคาโดยละเอียดให้ผู้มีโอกาสเป็นลูกค้าที่ขอในเช้านั้น ผู้ให้บริการของพวกเขาไม่สามารถยืนยันเซิร์ฟเวอร์ส่งของคุณได้ ดังนั้นจึงทิ้งข้อความในสแปม พวกเขาไม่ขุดผ่านขยะ บ่ายนั้นพวกเขารับใบเสนอราคาของคู่แข่ง — ใบเสนอราคาที่ “แสดงขึ้นจริงๆ” คุณคิดว่ามันเป็นลีดช้า ในความเป็นจริงอีเมลของคุณไม่เคยถูกเห็น
• ใบแจ้งหนี้ในความว่างเปล่า คุณออกใบแจ้งหนี้ให้ลูกค้าดี มันลงในโฟลเดอร์ขยะ สามสิบวันต่อมาคุณติดตามการชำระเงินที่เกินกำหนดโดยไม่ใช่ความผิดของพวกเขา — และตอนนี้มีการสนทนาที่อึดอัด ความสัมพันธ์ที่ตึงเครียด และช่องว่างกระแสเงินสดที่หลีกเลี่ยงได้ทั้งหมด
• “คุณไม่เคยตอบกลับ” ลูกค้าโกรธที่คุณเพิกเฉยคำถามของพวกเขา คุณไม่ได้ทำ — คุณตอบในวันเดียวกัน ผู้ให้บริการเมลของพวกเขาทิ้งการตอบกลับของคุณเงียบๆ เพราะเซิร์ฟเวอร์ส่งของคุณดูไม่น่าไว้วางใจ คุณดูไม่มืออาชีพสำหรับสิ่งที่คุณทำถูกต้องจริงๆ
• เซิร์ฟเวอร์ส่ง DIY ที่เป็นพิษทุกอย่างเงียบๆ เพื่อประหยัดเงิน เมลของคุณ (หรือแค่จดหมายข่าวและใบแจ้งหนี้อัตโนมัติ) เริ่มออกไปผ่าน VPS ราคาถูกหรือแอพส่งใหม่ เซิร์ฟเวอร์นั้นไม่เคยได้รับป้าย Reverse DNS อัตราการส่งมอบของคุณลดลงชั่วข้ามคืน — และเพราะไม่มีข้อความแสดงข้อผิดพลาด ใช้เวลาหลายเดือนกว่าจะสงสัยสาเหตุ
• ตั้งค่าสถานะในการตรวจสอบความปลอดภัย ทีม IT ของลูกค้ารายใหญ่รันการตรวจสอบตามปกติบนโดเมนของคุณระหว่างการเตรียมการ ทุกอย่างอื่นปกติดี แต่เซิร์ฟเวอร์เมลของคุณไม่มีตัวตนที่เหมาะสม มันเป็นจุดทางเทคนิคเล็กน้อย แต่ดูเหมือนความไม่ระมัดระวัง — และตอนนี้คุณกำลังแก้ไขภายใต้แรงกดดันเส้นตาย หรืออธิบาย เมื่อโดเมนของคู่แข่งเพิ่งผ่านไป

เส้นทางในทั้งหมดนี้: ค่าใช้จ่ายตกอยู่กับคุณ มองไม่เห็นขณะเกิดขึ้น และการแก้ไขฟรี

มันคืออะไรจริงๆ

DNS ปกติเปลี่ยนชื่อเป็นตัวเลข: คุณพิมพ์ yourcompany.com และ DNS ส่งคืนที่อยู่ IP ที่จะเชื่อมต่อ DNS ย้อนกลับ ทำตรงกันข้าม — มันเปลี่ยนตัวเลขกลับเป็นชื่อ จาก IP 203.0.113.10 การค้นหาย้อนกลับ (ระเบียน “PTR”) ตอบ mail.yourcompany.com

ทำไมผู้รับถึงสนใจ: เมื่อเซิร์ฟเวอร์เมลของคุณเชื่อมต่อกับ Gmail เพื่อส่งข้อความ Gmail เห็น IP ที่เชื่อมต่อ สิ่งแรกที่ตัวกรองเมลที่จริงจังทำคือถามว่า “เครื่องนี้เป็นใคร?” — โดยการค้นหาย้อนกลับบน IP นั้น เซิร์ฟเวอร์เมลธุรกิจจริงมีคำตอบ (mail.yourcompany.com) เครื่องสแปมที่ใช้แล้วทิ้งมักไม่มี หรือมีชื่อทั่วไปที่ผู้ให้บริการกำหนดเช่น host-203-0-113-10.someisp.net ดังนั้นการมีอยู่และคุณภาพของป้ายเป็นหนึ่งในสัญญาณความน่าเชื่อถือแรกๆ ที่ใช้กับเมลของคุณ — ก่อนที่ SPF, DKIM หรือเนื้อหาข้อความจะถูกมองด้วยซ้ำ

มันตรวจสอบเซิร์ฟเวอร์เมล ไม่ใช่เว็บไซต์ของคุณ สิ่งนี้ทำให้คนสับสน ที่อยู่ของเว็บไซต์ของคุณมักอยู่เบื้องหลัง CDN หรือพร็อกซี (เช่น Cloudflare) และจะไม่มีป้ายที่ตรงกันเลย — และนั่นก็โอเค เพราะ Reverse DNS สำหรับอีเมลเกี่ยวกับ IP ของเซิร์ฟเวอร์เมล MX ซึ่งเป็นเครื่องที่แยกต่างหากโดยสิ้นเชิง การตรวจสอบนี้ค้นหาเซิร์ฟเวอร์เมลหลักของโดเมน (ระเบียน MX ที่มีลำดับความสำคัญต่ำสุด) แก้ไขเป็น IP และตรวจสอบป้ายบน IP นั้น

ครึ่งหนึ่งที่การตั้งค่าส่วนใหญ่ทำผิด: มันต้องตรงกันทั้งสองทาง การมีชื่อไม่พอด้วยตัวเอง Gmail และตัวกรองรายใหญ่อื่นๆ ทำสิ่งที่เข้มงวดกว่า เรียกว่า forward-confirmed reverse DNS (FCrDNS):

1. ค้นหา IP → ได้ชื่อ (เช่น mail.yourcompany.com)
2. ตอนนี้ค้นหาชื่อนั้นย้อนกลับ → มันต้องแก้ไขเป็น IP เดิมที่คุณเริ่มต้น

หากสองทิศทางเห็นด้วย เซิร์ฟเวอร์ได้รับการยืนยันและเชื่อถือได้อย่างเต็มที่ หากมีชื่อแต่ชี้ไปที่อื่น (หรือไปที่ไหนเลย) เซิร์ฟเวอร์จะเชื่อถือเพียงครึ่งเดียว — ป้ายที่ไม่รอดการมองครั้งที่สองได้รับการปฏิบัติอ่อนกว่าที่คุณหวัง

นั่นคือวิธีที่การตรวจสอบนี้ให้คะแนน:

• Forward-confirmed (FCrDNS): IP ตั้งชื่อโฮสต์ และโฮสต์นั้นชี้กลับไปยัง IP เดิม คะแนนเต็ม — นี่คือการกำหนดค่าที่ถูกต้อง และเป็นสิ่งที่ผู้รับไว้วางใจ
• ป้ายมีอยู่แต่ไม่ได้รับการยืนยัน: มีระเบียน PTR แต่ชื่อไม่แก้ไขกลับไปยัง IP ของเซิร์ฟเวอร์เมล เครดิตบางส่วนเท่านั้น — ดูเหมือนกำหนดค่าแต่ตัวกรองรายใหญ่จะไม่เชื่อถืออย่างเต็มที่
• ไม่มีป้ายเลย: ไม่มีระเบียน PTR บน IP ของเซิร์ฟเวอร์เมล ไม่มีเครดิต และค่าใช้จ่ายด้านการส่งมอบเป็นจริง

วิธีแก้ไข (ฟรี ประมาณ 10 นาทีของเวลาของใครบางคน)

ส่งส่วนนี้ให้ใครก็ตามที่เป็นเจ้าของที่อยู่ IP ของเซิร์ฟเวอร์เมลของคุณ — โดยปกติคือผู้ให้บริการอีเมลหรือโฮสติ้ง หรือศูนย์ข้อมูลของคุณสำหรับกล่องโฮสต์เอง — และสังเกตว่าการแก้ไขฟรี นี่คือการตั้งค่าอีเมลหนึ่งอย่างที่คุณแทบจะไม่สามารถเปลี่ยนได้เองในแผง DNS ปกติ เพราะ Reverse DNS ถูกควบคุมโดยผู้ที่เป็นเจ้าของ IP ไม่ใช่ผู้ที่เป็นเจ้าของโดเมน เราเรียกเก็บเงินสำหรับการตรวจสอบว่ามันยังคงถูกต้องเท่านั้น ไม่ใช่เพื่อทำการเปลี่ยนแปลง

ขั้นตอนที่ 1 — ค้นหา IP ของเซิร์ฟเวอร์เมลส่ง ระบุโฮสต์ MX หลักของโดเมน (เซิร์ฟเวอร์เมลที่มีหมายเลขลำดับความสำคัญต่ำสุด) และแก้ไขเป็น IP:

dig MX yourcompany.com        # ค้นหาโฮสต์ MX หลัก (ลำดับความสำคัญต่ำสุด)
dig A mail.yourcompany.com    # แก้ไขโฮสต์นั้นเป็น IP

IP นั้นคือสิ่งที่ต้องการป้าย อย่าใช้ IP ของเว็บไซต์ — มันเป็นเครื่องที่แตกต่างและมักอยู่เบื้องหลัง CDN ที่จะไม่มีวันตรงกัน

ขั้นตอนที่ 2 — ขอให้เจ้าของ IP ตั้งระเบียน PTR Reverse DNS อยู่กับผู้ที่ควบคุมบล็อก IP ดังนั้นคำขอไปที่:

• Google Workspace / Gmail: จัดการโดยอัตโนมัติสำหรับเซิร์ฟเวอร์ของ Google เอง — หากโดเมนที่ส่งผ่าน Google เท่านั้นยังแสดงว่าล้มเหลว ให้ยกระดับกับ Google support (ในทางปฏิบัติสิ่งเหล่านี้ผ่าน)
• Microsoft 365: จัดการโดยอัตโนมัติสำหรับเซิร์ฟเวอร์ของ Microsoft เช่นกัน
• เซิร์ฟเวอร์เมลโฮสต์เองหรือ VPS: เปิด ticket กับผู้ให้บริการโฮสติ้งหรือศูนย์ข้อมูลของคุณ ขอให้พวกเขาตั้ง PTR (Reverse DNS) สำหรับ IP ของคุณเป็นชื่อโฮสต์เมล ผู้ให้บริการส่วนใหญ่เปิดเผยสิ่งนี้ในแผงควบคุมของพวกเขา
• แอพส่งของบุคคลที่สาม (จดหมายข่าว / ใบแจ้งหนี้ / CRM): หากส่งจากเซิร์ฟเวอร์ร่วมของตัวเอง ผู้ให้บริการจัดการ Reverse DNS — ไม่มีอะไรให้คุณตั้ง และคุณสามารถเพิกเฉยสิ่งนี้สำหรับการรับส่งข้อมูลนั้น

บอกพวกเขาว่าต้องการระเบียนอะไร เช่น: 203.0.113.10 → mail.yourcompany.com

ขั้นตอนที่ 3 — ทำให้ forward-confirm (นี่คือขั้นตอนที่คนส่วนใหญ่พลาด) ชื่อโฮสต์ใน PTR ต้องแก้ไขกลับไปยัง IP เดิมผ่านระเบียน A ปกติที่คุณควบคุมใน DNS ของคุณเอง ดังนั้น:

• PTR บอกว่า 203.0.113.10 → mail.yourcompany.com (ผู้ให้บริการของคุณตั้งสิ่งนี้)
• ระเบียน A บอกว่า mail.yourcompany.com → 203.0.113.10 (คุณตั้งสิ่งนี้ใน DNS เช่น Cloudflare → DNS → เพิ่มระเบียน A, ชื่อ mail, เนื้อหา 203.0.113.10)

ทั้งสองทิศทางต้องชี้ไปหากัน เมื่อนั้นเท่านั้นจึงจะ forward-confirmed และเชื่อถือได้อย่างเต็มที่

ขั้นตอนที่ 4 — ตรวจสอบโดเมนของคุณใหม่ ยืนยันว่าเซิร์ฟเวอร์เมลตอนนี้แสดง forward-confirmed reverse DNS และการตรวจสอบผ่าน การเปลี่ยนแปลง DNS แพร่กระจายภายในไม่กี่นาทีถึงไม่กี่ชั่วโมง

ข้อผิดพลาดทั่วไป

• ตั้งป้ายบน IP ของเว็บไซต์แทน IP ของเซิร์ฟเวอร์เมล Reverse DNS สำหรับอีเมลเกี่ยวกับเซิร์ฟเวอร์ MX การใส่ PTR บนที่อยู่เว็บ/CDN ของคุณไม่ช่วยอะไรสำหรับการส่งมอบ — เครื่องผิดได้รับป้าย
• หยุดที่ “PTR มีอยู่” ชื่อด้วยตัวเองได้รับความไว้วางใจเพียงบางส่วน หากไม่แก้ไขกลับไปยัง IP เดิม ตัวกรองที่เข้มงวด (Gmail, M365, Yahoo) จะไม่เชื่อถืออย่างเต็มที่ ทำ forward-confirmation เสมอ (ขั้นตอนที่ 3)
• ลืมระเบียน A หลังจากผู้ให้บริการตั้ง PTR ผู้ให้บริการตั้งครึ่งย้อนกลับ คุณต้องตั้งครึ่งไปข้างหน้าใน DNS ของคุณเอง คนทำอย่างเดียวและคิดว่าเสร็จแล้ว
• ถามผิดฝ่าย ส่งคำขอไปยังผู้ลงทะเบียนโดเมนหรือโฮสต์ DNS แทนเจ้าของ IP ทำให้ได้ “เราทำไม่ได้” — เพราะพวกเขาทำไม่ได้จริงๆ มันต้องไปที่ผู้ที่เป็นเจ้าของ IP
• ชื่อโฮสต์ทั่วไปของผู้ให้บริการ PTR เช่น host-203-0-113-10.someisp.net มีอยู่ในทางเทคนิคแต่ไม่ทำอะไรสำหรับแบรนด์หรือความไว้วางใจของคุณ ใช้ชื่อโฮสต์จริงบนโดเมนของคุณเองที่ forward-confirms

สิ่งนี้อยู่ที่ไหน

Reverse DNS คือตัวตนของเซิร์ฟเวอร์; SPF, DKIM และ DMARC คือการอนุญาตและชั้นป้องกันการแอบอ้างของโดเมน พวกมันตอบคำถามที่แตกต่างกัน และผู้ให้บริการรายใหญ่ตรวจสอบทั้งหมด SPF แสดงรายการบริการที่อาจส่งในนามของคุณ DKIM ลงนามข้อความของคุณด้วยลายเซ็นเข้ารหัสเพื่อให้ไม่สามารถดัดแปลงได้ DMARC เชื่อมทั้งสองเข้าด้วยกันและบอกผู้รับว่าต้องทำอะไรกับเมลที่ล้มเหลว — และปกป้องชื่อ “จาก” ที่ลูกค้าของคุณเห็นจริงๆ Reverse DNS อยู่ใต้ทั้งหมดนั้น รับรองว่าเครื่องที่ส่งเป็นเซิร์ฟเวอร์เมลจริงที่มีชื่อตั้งแต่แรก ทำ SPF, DKIM และ DMARC ให้ถูกต้องเพื่อการป้องกันการแอบอ้างที่แข็งแกร่งที่สุด ทำ Reverse DNS ให้ถูกต้องเพื่อให้เซิร์ฟเวอร์ส่งใหม่หรือโฮสต์เองไม่ถูกไม่เชื่อถืออย่างเงียบๆ ก่อนที่ส่วนอื่นจะมีโอกาส การแก้ไขทุกอย่างฟรี

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