THAI DATA CLOUD
Domainname Manual

SPF Lookup เกิน 10 ครั้ง: แก้ PermError ให้อีเมลผ่าน DMARC

แก้ปัญหา SPF Lookup เกิน 10 ครั้งจนได้ PermError (too many DNS lookups) นับ include ด้วย dig ตัดของที่ไม่ใช้ แยกผู้ส่งไปซับโดเมน และไม่พึ่ง flattening

โดย ทีมงาน THAI DATA CLOUD อัปเดต อ่าน 9 นาที

แชร์FacebookXLINELinkedIn
SPF Lookup — SPF Lookup เกิน 10 ครั้ง: แก้ PermError ให้อีเมลผ่าน DMARC
SPF Lookup เกิน 10 ครั้ง: แก้ PermError ให้อีเมลผ่าน DMARC

คำตอบสั้น ๆ: แก้ปัญหา SPF Lookup เกิน 10 ครั้งจนได้ PermError (too many DNS lookups) นับ include ด้วย dig ตัดของที่ไม่ใช้ แยกผู้ส่งไปซับโดเมน และไม่พึ่ง flattening

คู่มือนี้อธิบาย SPF Lookup ทีละขั้นตอน พร้อมคำสั่งที่ใช้ได้จริงและปัญหาที่พบบ่อย

SPF Lookup คือการค้น DNS ที่เกิดขึ้นระหว่างที่เซิร์ฟเวอร์ปลายทางตรวจระเบียน SPF ของโดเมนคุณ มาตรฐาน RFC 7208 จำกัดให้กลไกที่ต้องค้น DNS รวมกันได้ไม่เกิน 10 ครั้งต่อการตรวจหนึ่งครั้ง ถ้าเกิน ผลคือ permerror หรือข้อความ too many DNS lookups ซึ่งไม่นับเป็น SPF ผ่าน และ DMARC จะเหลือ DKIM เป็นทางรอดทางเดียว

ปัญหานี้มักเกิดกับองค์กรที่เพิ่มบริการส่งอีเมลไปเรื่อย ๆ เช่น ระบบอีเมลหลัก ระบบจดหมายข่าว CRM Helpdesk และระบบออกใบแจ้งหนี้ แต่ละบริการให้ใส่ include: และ include หนึ่งตัวอาจซ้อน include ต่ออีกหลายชั้น เมื่ออ่านคู่มือนี้จบ คุณจะนับจำนวน SPF Lookup ได้เอง รู้ว่าตัดอะไรได้ และมีระเบียน SPF ใหม่ที่ต่ำกว่า 10 พร้อมเผื่อที่ว่างไว้

ลำดับการตรวจ SPF ของเซิร์ฟเวอร์ผู้รับ นับ SPF Lookup ทีละ include เมื่อเกิน 10 ได้ permerror แล้ว DMARC เหลือแค่ DKIM
เมื่อ lookup เกิน 10 ผลคือ permerror ทั้งโดเมน ไม่ใช่เฉพาะบริการที่เพิ่มเข้ามาล่าสุด

สิ่งที่ต้องเตรียม

ขั้นตอนที่ 1: รู้ว่าอะไรนับเป็น SPF Lookup

ตาม RFC 7208 ส่วน 4.6.4 กลไก include, a, mx, ptr, exists และตัวปรับ redirect นับครั้งละ 1 lookup รวมถึงที่ซ้อนอยู่ใน include ทุกชั้นด้วย ส่วน ip4, ip6 และ all ไม่นับเพราะไม่ต้องค้น DNS

มีอีกสองกติกาที่คนมักลืม หนึ่ง การค้นที่ได้ผลว่างหรือไม่พบโดเมน (void lookup) ไม่ควรเกิน 2 ครั้ง มิฉะนั้นอาจได้ permerror เช่นกัน มักเกิดจาก include ของบริการที่เลิกใช้แล้ว สอง กลไก mx นับ 1 lookup แต่ระเบียน MX ที่ได้ต้องไม่เกิน 10 ชื่อ

ตารางแสดงกลไกในระเบียน SPF ที่นับเป็น SPF Lookup เช่น include, a, mx, ptr, exists, redirect และที่ไม่นับเช่น ip4, ip6, all
ip4 และ ip6 ไม่กินโควตา จึงเหมาะกับ IP ของเซิร์ฟเวอร์ที่คุณดูแลเอง

ขั้นตอนที่ 2: ดึงระเบียน SPF ปัจจุบันและตรวจว่ามีระเบียนเดียว

dig +short TXT example.com | grep -i "v=spf1"

ต้องได้ผลเพียงบรรทัดเดียว ถ้ามีสองระเบียนที่ขึ้นต้นด้วย v=spf1 เช่น ระเบียนหนึ่งของระบบอีเมลหลักและอีกระเบียนของระบบจดหมายข่าว ผลคือ permerror ทันทีไม่ว่าจะนับ lookup ได้เท่าไร ให้รวมเป็นระเบียนเดียว ถ้าระเบียนยาวเกิน 255 ตัวอักษร DNS จะแบ่งเป็นหลายสตริงในระเบียนเดียวกัน ซึ่งถูกต้อง ไม่ใช่สองระเบียน

ขั้นตอนที่ 3: ไล่นับ SPF Lookup ทีละชั้นด้วย dig

คัดลอกชื่อหลัง include: ทุกตัวมาค้นต่อ แล้วค้นชื่อที่ซ้อนอยู่ข้างในอีกจนหมด จดตัวเลขลงตาราง กลไก a, mx, ptr ในระเบียนหลักนับตัวละ 1 และ include ทุกตัวในทุกชั้นนับตัวละ 1

dig +short TXT _spf.mailhost.example
dig +short TXT spf.newsletter.example

เครื่องมือตรวจ SPF ออนไลน์ช่วยนับได้เร็ว แต่ควรนับเองอย่างน้อยหนึ่งครั้งเพื่อรู้ว่าบริการใดกินโควตาเท่าไร เพราะผู้ให้บริการแก้ระเบียนของตนได้ตลอดเวลา ตัวเลขที่เคยพอดีอาจเกินในเดือนถัดไป

หน้าจอเทอร์มินัลใช้ dig ดึงระเบียน SPF แล้วไล่ include ที่ซ้อนกัน นับ SPF Lookup ได้ 12 ครั้งซึ่งเกินขีดจำกัด
ระเบียนหลักใช้ 8 lookup แต่ include ที่ซ้อนอีก 4 ตัวทำให้รวมเป็น 12

ขั้นตอนที่ 4: ตัดกลไกที่ไม่จำเป็นเพื่อลด SPF Lookup

  • บริการที่เลิกใช้แล้ว: ถ้ารายงาน DMARC ไม่พบอีเมลจากบริการนั้นหลายเดือน ให้ลบ include ทิ้ง
  • ptr: RFC 7208 ระบุว่าไม่ควรใช้ เพราะช้าและไม่น่าเชื่อถือ ลบออกได้เลย
  • a: ถ้าเว็บเซิร์ฟเวอร์ไม่ได้ส่งอีเมลเอง ไม่จำเป็นต้องมี
  • mx: ถ้าเซิร์ฟเวอร์ที่ส่งอีเมลมี IP คงที่ เช่น 203.0.113.10 ให้ใช้ ip4:203.0.113.10 แทน ซึ่งไม่นับ lookup

สามข้อหลังเป็นการแทน lookup ด้วย IP ของตัวคุณเอง ซึ่งคุณรู้เมื่อ IP เปลี่ยน ต่างจากการแทน IP ของผู้ให้บริการรายอื่นในขั้นตอนที่ 6

ขั้นตอนที่ 5: ย้ายผู้ส่งบางรายออกจาก SPF ของโดเมนหลัก

SPF ตรวจโดเมนของที่อยู่ซองจดหมาย (Return-Path หรือ envelope from) ไม่ใช่ที่อยู่ From ที่ผู้รับเห็น บริการจดหมายข่าวและ CRM หลายรายใช้ Return-Path เป็นโดเมนของตนเองหรือซับโดเมนแบบ bounce.example.com ที่ชี้ CNAME ไปหาผู้ให้บริการ กรณีนี้ include ของบริการนั้นในโดเมนหลักไม่ถูกใช้งานเลย ตัดออกได้ ตรวจได้จาก header Return-Path ของอีเมลจริงจากแต่ละบริการ (ดูอ่าน Email Header)

อีกทางคือให้อีเมลการตลาดส่งจากซับโดเมน เช่น news.example.com ซึ่งมีระเบียน SPF และโควตา 10 lookup ของตัวเอง และให้ทุกบริการลงนาม DKIM ด้วยโดเมนของคุณ เพราะ DMARC ผ่านได้ด้วย DKIM ที่ตรงโดเมนแม้ SPF จะไม่ผ่าน

ขั้นตอนที่ 6: เขียนระเบียนใหม่ และเลี่ยง SPF flattening อัตโนมัติ

รวมทุกอย่างเป็นระเบียนเดียว ตั้งเป้า SPF Lookup ไม่เกิน 8 ครั้งเพื่อเผื่อที่ให้ผู้ให้บริการเพิ่ม include ในอนาคต ก่อนแก้ให้ลด TTL ของระเบียนลงล่วงหน้า (ดูวางแผน TTL)

example.com.  3600  IN  TXT  "v=spf1 ip4:203.0.113.10 ip4:198.51.100.0/24 include:_spf.mailhost.example include:spf.billing.example.com ~all"

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

ตารางเปรียบเทียบระเบียน SPF ก่อนแก้ที่มี SPF Lookup 12 ครั้งกับหลังแก้ที่เหลือ 6 ครั้งโดยไม่ใช้ flattening
ตัดของเลิกใช้ แทน a/mx ด้วย ip4 ของตัวเอง และย้ายจดหมายข่าวไปซับโดเมน

ขั้นตอนที่ 7: ทดสอบหลังแก้

รอให้ TTL เดิมหมด แล้วรัน dig +short TXT example.com ยืนยันค่าใหม่และนับ SPF Lookup อีกรอบ ส่งอีเมลทดสอบจากทุกบริการไปยังกล่อง Gmail แล้วเปิด Show original ต้องเห็น SPF: PASS และ DMARC: PASS หรือดูใน header Authentication-Results ว่า spf=pass จากนั้นติดตามรายงาน DMARC อีก 1–2 สัปดาห์ว่าไม่มีแหล่งส่งที่ถูกต้องตกหล่น

ปัญหาที่พบบ่อยเกี่ยวกับ SPF Lookup

SPF permerror ต่างจาก softfail และ fail อย่างไร?

softfail (~all) และ fail (-all) หมายถึงระเบียนอ่านได้แต่ IP ผู้ส่งไม่อยู่ในรายการ ส่วน permerror หมายถึงระเบียนเองใช้ไม่ได้ เช่น SPF Lookup เกิน 10 ครั้งหรือมีสองระเบียน ทำให้อีเมลทุกฉบับจากทุกบริการไม่ได้ผล SPF pass ผู้รับบางรายจึงลดความน่าเชื่อถือของอีเมลทั้งโดเมน

ใช้ทั้ง Microsoft 365 และ Google Workspace ต้องมี SPF สองระเบียนหรือไม่?

ไม่ต้องและห้ามทำ ให้ใส่ include ของทั้งสองบริการในระเบียน v=spf1 เดียวกัน แล้วนับจำนวน lookup รวมใหม่ เพราะ include ของผู้ให้บริการรายใหญ่บางรายซ้อนอยู่หลายชั้น

ทำไมเครื่องมือออนไลน์แต่ละตัวนับ SPF Lookup ได้ไม่เท่ากัน?

ผู้ให้บริการแก้ระเบียน SPF ของตนได้ตลอด เครื่องมือที่ใช้ข้อมูลแคชเก่าจึงนับต่างกัน และบางเครื่องมือไม่นับ void lookup หรือนับ mx ต่างกัน ให้ยึดผลจากการไล่ dig ด้วยตัวเองและผลจริงใน header ของอีเมลที่ได้รับ

ควรปิดท้ายด้วย ~all หรือ -all?

-all ขอให้ปฏิเสธอีเมลที่ไม่อยู่ในรายการ ส่วน ~all ขอให้รับแต่ทำเครื่องหมายว่าน่าสงสัย เมื่อมี DMARC แล้ว ผลสุดท้ายขึ้นกับนโยบาย DMARC เป็นหลัก ใช้ -all เมื่อมั่นใจว่าระบุผู้ส่งครบแล้วเท่านั้น

ถ้าโดเมนของคุณมีบริการส่งอีเมลหลายตัวจนจัดการ SPF ไม่ไหว หรืออยากย้ายมาใช้ Cloud Mail Server ที่ตั้ง SPF, DKIM และ DMARC ให้ครบ ติดต่อทีมงาน THAI DATA CLOUD อ่านกติกาการนับฉบับเต็มได้ที่ RFC 7208 ส่วน 4.6.4

อ่านเพิ่มเติมเกี่ยวกับ SPF Lookup

แชร์FacebookXLINELinkedIn

มีคำถามเรื่องบริการ? ติดต่อทีมงาน