SPF Flattening: แก้ขีดจำกัด 10 Lookup

อธิบายขีดจำกัด 10 Lookup

SPF (Sender Policy Framework) ล้มเหลวด้วย permerror เมื่อเซิร์ฟเวอร์อีเมลผู้รับต้องทำ DNS lookup เกิน 10 ครั้งเพื่อ resolve เรคคอร์ด SPF ของคุณ สิ่งนี้เกิดจากคำสั่ง include ที่ซ้อนกัน หากเรคคอร์ดของคุณ include ผู้ให้บริการรายหนึ่ง และผู้ให้บริการนั้น include บริการอีกอย่าง ทุกขั้นจะนับรวมในขีดจำกัด เพื่อแก้ปัญหา คุณต้องใช้ SPF flattening ซึ่งแทนที่ lookup แบบเรียกซ้ำเหล่านี้ด้วยรายการที่อยู่ IP แบบคงที่

ในฐานะวิศวกรที่ดูแลความสามารถในการส่งถึง ปัญหานี้มักโผล่ขึ้นมาในช่วง "vendor sprawl" บริษัทเริ่มจากผู้ให้บริการ transactional รายเดียว เพิ่มเครื่องมือการตลาด เพิ่ม CRM แล้วจู่ ๆ เรคคอร์ด SPF ก็เป็นเหมือนบ้านไพ่ เมื่อ lookup ครั้งที่ 11 ถูกเรียก เซิร์ฟเวอร์ผู้รับจะหยุดค้นหาและคืนข้อผิดพลาดถาวร นั่นหมายความว่าอีเมลของคุณไม่ได้แค่ถูกทำเครื่องหมายเป็นสแปม แต่อาจถูกปฏิเสธทั้งหมดเพราะการตรวจสอบการยืนยันตัวตนล้มเหลวตั้งแต่ระดับพื้นฐาน

ขีดจำกัด Lookup ทำงานอย่างไร

ตาม RFC 7208 ขีดจำกัดนี้มีไว้ป้องกันการโจมตีแบบ Denial of Service (DoS) ต่อโครงสร้างพื้นฐาน DNS หากไม่มีขีดจำกัด ผู้ประสงค์ร้ายอาจสร้างการอ้างอิงแบบวงกลมหรือ include chain ยาวมากที่บังคับให้เซิร์ฟเวอร์ผู้รับส่งคำค้นหลายร้อยครั้งสำหรับอีเมลเพียงฉบับเดียว

อะไรนับเป็น lookup

ไม่ใช่ทุก mechanism ในเรคคอร์ด SPF ของคุณที่ไม่มีต้นทุน ต่อไปนี้ทำให้เกิดคำค้น DNS

• include: ตัวการที่พบบ่อยที่สุด สั่งให้เซิร์ฟเวอร์ไปดูเรคคอร์ด SPF ของโดเมนอื่น
• a: ค้นหาเรคคอร์ด A ของโดเมน
• mx: ค้นหาเรคคอร์ด MX ของโดเมน
• ptr: ค้นหา reverse DNS (แต่เลิกใช้แล้วและควรหลีกเลี่ยง)
• exists: ค้นหาโดเมนที่ระบุเพื่อดูว่ามีอยู่หรือไม่

mechanism อย่าง ip4 และ ip6 ไม่นับเป็น lookup เพราะที่อยู่ IP ถูกระบุไว้ในเรคคอร์ดโดยตรง

โครงสร้างของ Lookup Chain

พิจารณาเรคคอร์ด SPF สมมตินี้

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendhq.cc ~all

เมื่อมองผิวเผิน นี่คือ 3 lookup แต่หาก _spf.google.com มีคำสั่ง include อีกสามรายการ และ spf.protection.outlook.com มีสี่รายการ คุณก็ถึง 10 lookup แล้ว หากเรคคอร์ดของ SendHQ มี include ด้วย คุณก็ชนขีดจำกัด นี่คือ "include chain"

ระบุ Permerror

หากไม่แน่ใจว่าชนขีดจำกัดหรือยัง คุณใช้ SendHQ Email DNS Checker เพื่อตรวจสอบเรคคอร์ดของคุณได้ ในล็อกดิบหรือเครื่องมือวิเคราะห์เฮดเดอร์ คุณจะเห็นผลลัพธ์ประมาณนี้

spf=permerror (too many DNS lookups)

ซึ่งต่างจาก softfail (~all) หรือ fail (-all) permerror หมายความว่าการตรวจสอบ SPF ทำไม่สำเร็จ เมื่อเป็นเช่นนี้ ผู้รับยืนยันไม่ได้ว่าผู้ส่งได้รับอนุญาตหรือไม่ ซึ่งมักทำให้อีเมลถูกทิ้งหรือถูกตัวกรองที่เข้มงวดทำเครื่องหมาย

SPF Flattening คืออะไร

SPF flattening คือกระบวนการ resolve mechanism include, a และ mx ทั้งหมดให้เป็นรายการแบบแบนของที่อยู่ ip4 และ ip6

ตัวอย่าง: ก่อนและหลัง

ก่อน (แบบเรียกซ้ำ):

v=spf1 include:_spf.example.com include:_spf.vendor.com ~all

(สมมติว่า _spf.example.com resolve เป็น 1.2.3.4 และ _spf.vendor.com resolve เป็น 5.6.7.8)

หลัง (แบบแบน):

v=spf1 ip4:1.2.3.4 ip4:5.6.7.8 ~all

เมื่อแปลงเรคคอร์ดเป็นรายการ IP จำนวน lookup ลดจาก 2 (หรือมากกว่า) เหลือ 0 เซิร์ฟเวอร์ผู้รับเห็น IP ทันทีและตรวจสอบผู้ส่งได้โดยไม่ต้องทำคำค้น DNS เพิ่ม

ข้อแลกเปลี่ยนของ Flattening

Flattening เป็นวิธีแก้ที่ทรงพลัง แต่สร้างภาระการบำรุงรักษาที่มาก

1. ปัญหา IP ที่ล้าสมัย

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

หากคุณ flatten เรคคอร์ดเหล่านั้นมาไว้ใน DNS ของคุณเอง คุณจะต้องรับผิดชอบ IP เหล่านั้น หากผู้ให้บริการเปลี่ยน IP แล้วคุณไม่อัปเดตรายการที่ flatten ไว้ อีเมลของคุณจะไม่ผ่านการยืนยันตัวตน SPF นี่คือเหตุผลหลักที่การ flatten ด้วยมือเป็นเรื่องอันตรายสำหรับอีเมล transactional ปริมาณสูง

2. ขีดจำกัดความยาวของเรคคอร์ด

เรคคอร์ด DNS มีความยาวสูงสุด สตริงเดียวในเรคคอร์ด TXT จำกัดที่ 255 อักขระ แม้จะต่อสตริงหลายชุดได้ แต่ตัวแยกวิเคราะห์ DNS รุ่นเก่าบางตัวมีปัญหากับเรคคอร์ดที่ยาวมาก หาก flatten ผู้ให้บริการมากเกินไป เรคคอร์ด SPF ของคุณอาจใหญ่เกินกว่าจะประมวลผลได้ถูกต้อง

วิธีแก้ Include Chain

หากชนขีดจำกัด 10 lookup ให้ทำตามลำดับวิธีแก้นี้ จากปลอดภัยที่สุดไปจนถึงรุนแรงที่สุด

ขั้นที่ 1: ตรวจสอบและตัดทิ้ง

ตรวจเรคคอร์ดของคุณหาผู้ให้บริการเก่า หลายทีมยังมีคำสั่ง include ของบริการที่เลิกใช้ไปสามปีแล้ว ให้ลบผู้ให้บริการที่ไม่ได้ส่งอีเมลแทนคุณอีกต่อไป

ขั้นที่ 2: ใช้ซับโดเมนแยกสำหรับทราฟฟิกแต่ละประเภท

นี่คือวิธีแก้เชิงสถาปัตยกรรมที่เป็นมืออาชีพที่สุด แทนที่จะใส่ทุกบริการไว้บนโดเมนหลัก ให้แยกตามหน้าที่

• โดเมนหลัก (example.com): อีเมลองค์กร (Google Workspace/Outlook)
• ซับโดเมน transactional (mail.example.com): SendHQ หรือ Amazon SES
• ซับโดเมนการตลาด (news.example.com): Mailchimp หรือ Klaviyo

แต่ละซับโดเมนมีเรคคอร์ด SPF และขีดจำกัด 10 lookup ของตัวเอง วิธีนี้แยกความเสี่ยงและป้องกันไม่ให้ SPF chain ที่ซับซ้อนของเครื่องมือการตลาดทำให้อีเมล transactional สำคัญของคุณพัง

ขั้นที่ 3: Dynamic SPF Flattening

Dynamic flattening คือบริการที่เฝ้าดู include chain ของผู้ให้บริการของคุณแบบเรียลไทม์ และอัปเดตเรคคอร์ด DNS ของคุณด้วยที่อยู่ IP ปัจจุบันโดยอัตโนมัติ วิธีนี้แก้ปัญหา "IP ที่ล้าสมัย" ด้วยการทำให้การอัปเดตเป็นอัตโนมัติผ่าน API

SPF ในบริบทของการส่งอีเมลยุคใหม่

ต้องเข้าใจว่า SPF เป็นเพียงส่วนหนึ่งของปริศนาการยืนยันตัวตน เพื่อให้เซิร์ฟเวอร์ผู้รับยอมรับอีเมลของคุณ คุณต้องประสาน SPF กับ DKIM และ DMARC ดูรายละเอียดความสัมพันธ์เหล่านี้ได้ในคู่มือ DKIM, SPF และ DMARC ของ SendHQ

การยอมรับ การส่งถึง และการเข้ากล่องจดหมาย

ในฐานะวิศวกร แยกสามขั้นตอนนี้ออกจากกัน

1. การยอมรับ: เซิร์ฟเวอร์ผู้รับยอมรับการเชื่อมต่อและข้อความ SPF permerror ทำให้เซิร์ฟเวอร์ปฏิเสธข้อความที่ระดับ SMTP ได้ ซึ่งหมายความว่าข้อความไม่เคยถูกยอมรับ
2. การส่งถึง: ข้อความถูกยอมรับและย้ายไปยังกล่องจดหมายของผู้ใช้ (หรือโฟลเดอร์)
3. การเข้ากล่องจดหมาย: ข้อความเข้าอินบ็อกซ์หลักแทนที่จะเข้าโฟลเดอร์สแปม

SPF flattening แก้ปัญหาการยอมรับ แต่ไม่ได้รับประกันการเข้ากล่องจดหมาย การเข้ากล่องจดหมายขึ้นอยู่กับชื่อเสียงผู้ส่ง เนื้อหา และตัวชี้วัดการมีส่วนร่วม

ข้อควรพิจารณาพิเศษสำหรับเอเจนต์ AI

เมื่อเอเจนต์ AI ส่งอีเมลผ่าน API มากขึ้น ความเสี่ยงของปัญหา SPF ก็เพิ่มขึ้น เพราะเอเจนต์อาจกระตุ้นอีเมลปริมาณสูงข้ามหลายโดเมน เมื่อสร้างเวิร์กโฟลว์แบบเอเจนต์ ให้มองการส่งอีเมลเป็นผลข้างเคียงภายนอก

Idempotency และการอนุมัติ

เอเจนต์ไม่ควรส่งอีเมลเป็นลูปโดยไม่มีกลไกป้องกัน ใช้ idempotency key เพื่อให้ตรรกะการลองใหม่ของเอเจนต์ไม่ส่งอีเมล transactional ฉบับเดียวกันถึงลูกค้าสิบครั้ง นอกจากนี้ สำหรับอีเมลที่มีความเสี่ยงสูง ให้ใส่ขั้นตอนอนุมัติแบบ human-in-the-loop ก่อนเรียก API

วิเคราะห์ต้นทุนของผู้ให้บริการส่ง

เมื่อเลือกผู้ให้บริการที่จะ include ในเรคคอร์ด SPF ให้พิจารณาต้นทุนตามปริมาณที่คุณส่ง จากราคาเดือนกันยายน 2026

• Amazon SES: คิด 0.10 USD ต่อ 1,000 อีเมลแบบ a la carte (ราคา Amazon SES) สำหรับ 50,000 อีเมลอยู่ที่ประมาณ 5 USD แพ็กเกจแบบแบ่งระดับใหม่ที่เริ่มเมื่อวันที่ 21 กรกฎาคม 2026 ได้แก่ Essentials (0.16 USD ต่อ 1,000), Pro (0.22 USD ต่อ 1,000 บวก 105 USD/เดือน/ภูมิภาค) และ Enterprise (0.23 USD ต่อ 1,000 บวก 500 USD/เดือน)
• Postmark: 15 USD ต่อเดือนสำหรับ 10,000 อีเมล ส่วนที่เกินคิดระหว่าง 1.80 ถึง 1.20 USD ต่อ 1,000 (ราคา Postmark) 50,000 อีเมลบนแพ็กเกจของ Postmark อยู่ที่ราว 66 USD
• Resend: แพ็กเกจฟรี 3,000 อีเมลต่อเดือน (จำกัด 100/วัน) แพ็กเกจ Pro 20 USD ต่อเดือนสำหรับ 50,000 อีเมล ส่วนที่เกินคิด 0.90 USD ต่อ 1,000 (ราคา Resend)
• Mailgun: 15 USD ต่อเดือนสำหรับ 10,000 อีเมล ส่วนที่เกินคิด 1.80 ถึง 1.10 USD ต่อ 1,000 (ราคา Mailgun)
• SendGrid: แพ็กเกจฟรีตอนนี้เป็นช่วงทดลอง 60 วัน และ Essentials เริ่มที่ 19.95 USD ต่อเดือน (ราคา SendGrid)

รายการตรวจสอบการแก้ปัญหา SPF

หากสงสัยว่ามีปัญหาขีดจำกัด lookup ให้ไล่ตามรายการตรวจสอบนี้

• ตรวจสอบ DNS บนโดเมนรากและโดเมนย่อยสำหรับการส่งทั้งหมด
• นับจำนวน mechanism include, a, mx และ exists ทั้งหมด
• ติดตาม chain ของ include ของผู้ให้บริการแต่ละรายเพื่อดูว่ามี lookup ซ้อนกันหรือไม่
• ระบุและลบผู้ให้บริการที่ไม่ได้ใช้งาน
• ประเมินว่าสามารถย้ายทราฟฟิกไปยังโดเมนย่อยเฉพาะได้หรือไม่ (เช่น notifications.example.com)
• หากยังเกินขีดจำกัด ให้ใช้ SPF flattening แบบไดนามิก
• ตรวจสอบว่าเรคคอร์ดสุดท้ายไม่เกินขีดจำกัด 255 อักขระต่อสตริง

ตารางสรุป: Mechanism ของ SPF

Mechanism | DNS Lookup หรือไม่ | ความเสี่ยง | คำแนะนำ

ip4 / ip6 | ไม่ | ต่ำ | ใช้กับ IP คงที่

include | ใช่ | สูง | ใช้เท่าที่จำเป็น เฝ้าดู chain

a | ใช่ | ปานกลาง | หลีกเลี่ยงถ้าทำได้ ใช้ ip4

mx | ใช่ | ปานกลาง | หลีกเลี่ยงถ้าทำได้

ptr | ใช่ | สูง | อย่าใช้ (เลิกใช้แล้ว)

เมื่อจัดการเรคคอร์ด SPF อย่างเชิงรุก คุณจะหลีกเลี่ยง permerror ที่ฆ่าความสามารถในการส่งถึงก่อนอีเมลจะไปถึงตัวกรองสแปมด้วยซ้ำ ไม่ว่าจะใช้ API ธรรมดาหรือระบบแบบเอเจนต์ที่ซับซ้อน การรักษา DNS ให้เรียบง่ายคือวิธีที่ดีที่สุดที่จะทำให้อีเมล transactional ของคุณถูกยอมรับ

สำหรับชุดเครื่องมือจัดการการยืนยันตัวตนโดเมนแบบครบถ้วน เข้าไปที่ https://sendhq.cc