ตรวจสอบเรคคอร์ด SPF สำหรับอีเมลของแอปพลิเคชันอย่างไร

เริ่มจากตัวตนที่ SPF ตรวจสอบจริง

การตรวจสอบ SPF ต้องมีอินพุตสามอย่าง ได้แก่ IP ของไคลเอนต์ SMTP โดเมนที่นโยบายการอนุญาตกำลังถูกประเมิน และตัวตนผู้ส่ง สำหรับอีเมลของแอปพลิเคชันทั่วไป โดเมนนั้นมาจากที่อยู่ SMTP MAIL FROM ซึ่งเรียกอีกอย่างว่า envelope sender หรือ return path และอาจต่างจากที่อยู่ในเฮดเดอร์ From ของข้อความที่ผู้คนเห็น หาก MAIL FROM ว่างเปล่า ซึ่งเป็นเรื่องปกติสำหรับการแจ้งสถานะการส่ง SPF จะใช้ตัวตน HELO สำหรับการตรวจสอบ MAIL FROM ให้บันทึก IP การเชื่อมต่อจริงและตัวตน envelope จากข้อความทดสอบที่ได้รับ หรือจากการตั้งค่าของผู้ให้บริการส่งก่อนค้นหา DNS การตรวจสอบ example.test เพียงเพราะปรากฏใน From ไม่ให้ข้อสรุปที่แน่ชัด หากแอปพลิเคชันส่งจริงด้วย MAIL FROM ที่ bounce.provider.test หรือ bounces.example.test

ค้นหา TXT ที่โดเมน MAIL FROM ที่ตรงกันทุกตัวอักษร

ค้นหา DNS TXT ที่โดเมนที่เลือกไว้ในขั้นตอนแรกอย่างตรงตัว RFC 7208 กำหนดให้นโยบาย SPF เวอร์ชัน 1 เผยแพร่เป็นเรคคอร์ด TXT ที่ owner name ที่นโยบายนั้นควบคุม ให้ละเว้นค่า TXT ที่ไม่เกี่ยวข้อง และเลือกเรคคอร์ดที่ส่วนเวอร์ชันเป็น v=spf1 พอดี หากไม่มีเรคคอร์ดที่เลือก ผลลัพธ์ SPF คือ none หากมีเรคคอร์ด SPF ที่เลือกมากกว่าหนึ่งรายการ ผลลัพธ์คือ permerror การเผยแพร่เรคคอร์ดแยกกันสำหรับแต่ละผู้ให้บริการไม่ใช่วิธีที่ถูกต้องในการรวมเข้าด้วยกัน เรคคอร์ด TXT รายการเดียวอาจถูกเครื่องมือ DNS แบ่งเป็นสตริงอักขระที่อยู่ในเครื่องหมายอัญประกาศ แต่สตริงเหล่านั้นจะถูกต่อกันโดยไม่มีการเติมช่องว่างก่อน SPF จะแยกวิเคราะห์ ให้บันทึกคำตอบทั้งหมด resolver เวลาที่ค้นหา และ TTL เพื่อให้ตรวจซ้ำได้หลังการเปลี่ยนแปลง

ตรวจสอบไวยากรณ์และประเมิน term จากซ้ายไปขวา

เรคคอร์ด SPF คือนโยบายที่มีลำดับ ไม่ใช่รายชื่อผู้ให้บริการที่ไม่เรียงลำดับ หลัง v=spf1 mechanism จะถูกประเมินจากซ้ายไปขวาจนกว่าจะมีตัวที่ตรงกัน qualifier ที่นำหน้าเป็นตัวกำหนดผลลัพธ์ โดย + หมายถึง pass และเป็นค่าเริ่มต้น - หมายถึง fail ~ หมายถึง softfail และ ? หมายถึง neutral mechanism ip4 และ ip6 เปรียบเทียบที่อยู่ของไคลเอนต์กับที่อยู่หรือเครือข่าย mechanism a และ mx จะ resolve DNS ส่วน include ประเมินนโยบาย SPF ของโดเมนอื่น และตรงกันเฉพาะตามกฎของ include exists ทดสอบผ่าน DNS ส่วน all ตรงกันเสมอและมักปิดท้ายเรคคอร์ด ข้อผิดพลาดด้านไวยากรณ์ตรงไหนก็ตามจะทำให้เกิด permerror ก่อนการประเมินปกติ เครื่องมือตรวจสอบที่ดีควรรายงานว่า mechanism ใดตรงกัน qualifier ของมัน และโดเมนที่ขยายแต่ละตัว ไม่ใช่แค่คืนป้ายสีเพียงอย่างเดียว

ไล่ตาม include และ redirect โดยไม่มองว่าเป็นเพียงชื่อแทน

ไล่ตามทุก include และ redirect ภายในบริบทการประเมินเดียวกัน include เป็น mechanism ที่ถามว่านโยบายที่ include ให้ผล pass สำหรับไคลเอนต์และผู้ส่งปัจจุบันหรือไม่ และหากไม่ตรงก็ดำเนินต่อในเรคคอร์ดเดิม ส่วน redirect เป็น modifier ที่พิจารณาหลังจาก mechanism ของเรคคอร์ดปัจจุบันไม่ตรงกันทั้งหมด โดยโอนการประเมินไปยังนโยบายอื่นพร้อมคง IP ของไคลเอนต์และผู้ส่งไว้ redirect จะถูกละเว้นหากมี all อยู่ที่ใดก็ตามในเรคคอร์ด ความแตกต่างเหล่านี้สำคัญระหว่างการย้ายระบบ การแทน include:vendor.test ด้วย redirect=vendor.test อาจแทนที่นโยบาย fallback ทั้งหมดของเจ้าของโดเมน แทนที่จะเพียงเพิ่มผู้ให้บริการ ให้ตรวจจับวงจรวนซ้ำ เป้าหมายที่ไม่มี เป้าหมายที่ไม่ถูกต้อง และข้อผิดพลาดถาวรหรือชั่วคราวแบบ nested และเก็บห่วงโซ่การพึ่งพาไว้ในผลลัพธ์ เพื่อให้เห็นการเปลี่ยนแปลงนโยบายฝั่งผู้ให้บริการ

นับงบการค้นหา DNS ทั้งหมด

นับ term ที่ก่อให้เกิดการค้นหา DNS ตลอดการประเมินแบบเรียกซ้ำทั้งหมด ไม่ใช่เฉพาะเรคคอร์ดระดับบนสุด RFC 7208 จำกัด term ประเภท include, a, mx, ptr, exists และ redirect ไว้ที่สิบรายการต่อการประเมิน SPF หนึ่งครั้ง หากเกินต้องให้ผล permerror mechanism all, ip4 และ ip6 ไม่ใช้งบ term นี้ การประมวลผล MX และ PTR มีขีดจำกัดการค้นหาที่อยู่เพิ่มเติม RFC ยังแนะนำให้จำกัด void lookup ซึ่งหมายถึงคำตอบว่างที่สำเร็จหรือข้อผิดพลาดด้านชื่อ ไว้ที่สอง และให้ผล permerror เมื่อเกินขีดจำกัดนั้น ไม่แนะนำให้ใช้ mechanism ptr เพราะช้าและไม่น่าเชื่อถือ เรคคอร์ดอาจดูสั้น แต่ include ของผู้ให้บริการอาจขยายเป็น term แบบ nested จนเกินขีดจำกัด จึงควรรายงานยอดรวม term ที่มีส่วนร่วมแต่ละตัว void lookup และสาขาที่ถูกใช้จริงสำหรับ IP ที่ทดสอบ

ตีความผล SPF โดยไม่เกินจริง

ใช้ชุดคำศัพท์ผลลัพธ์มาตรฐาน Pass หมายความว่าไคลเอนต์ที่ทดสอบได้รับอนุญาตให้ใช้ตัวตน SMTP ที่ตรวจสอบ Fail หมายความว่าพบการอนุญาตเชิงลบที่ตรงกัน Softfail เป็นข้อความเชิงลบแบบอ่อน ส่วน neutral หมายความว่าโดเมนไม่ยืนยันอะไรเกี่ยวกับไคลเอนต์นั้น None หมายความว่าไม่มีเรคคอร์ด SPF ที่เลือก Temperror สะท้อนปัญหาการประเมินชั่วคราว ซึ่งมักเกิดจาก DNS ส่วน permerror สะท้อนนโยบายที่ประเมินอย่างถูกต้องไม่ได้ หากไม่มี mechanism ใดตรงกันและไม่มี redirect ที่ใช้ได้ ผลลัพธ์คือ neutral ซึ่งเทียบเท่ากับ ?all โดยปริยาย ให้รายงานผลลัพธ์พร้อมตัวตน IP ของไคลเอนต์ term ที่ตรงกัน ร่องรอย DNS และเวลา อย่าแปลผล pass ว่าเป็นข้อความที่ปลอดภัย อีเมลที่ต้องการ การที่ผู้ให้บริการยอมรับ การส่งถึงกล่องจดหมาย หรือการเข้ากล่องจดหมาย เพราะ SPF ไม่ได้ตัดสินผลเหล่านั้น

ตรวจสอบข้อความจริง ไม่ใช่แค่เรคคอร์ดที่เผยแพร่

การตรวจสอบเรคคอร์ดแบบคงที่ตอบได้เพียงว่านโยบายถูกค้นพบและแยกวิเคราะห์ได้หรือไม่ ไม่ได้พิสูจน์ว่าแอปพลิเคชันใช้โดเมน MAIL FROM หรือ IP ขาออกตามที่คาดไว้ ให้ส่งข้อความทดสอบแบบควบคุมผ่านทุกเส้นทางใช้งานจริงไปยังบัญชีผู้รับที่คุณดูแล แล้วตรวจสอบเฮดเดอร์ที่ได้รับ เปรียบเทียบ IP ที่เชื่อมต่อ envelope sender และรายการ Authentication-Results ของผู้รับกับผลการประเมิน DNS ทำซ้ำสำหรับแต่ละผู้ให้บริการ region พูลเฉพาะหรือพูลร่วม เส้นทางสำรอง และประเภทข้อความที่อาจเปลี่ยน return path เก็บเฮดเดอร์ไว้ในที่จัดเก็บที่จำกัดสิทธิ์ เพราะที่อยู่และรายละเอียดการกำหนดเส้นทางอาจมีความอ่อนไหว หากแดชบอร์ดของผู้ให้บริการกับข้อความที่ได้รับไม่ตรงกัน ข้อความคือหลักฐานที่หนักแน่นกว่าเกี่ยวกับเส้นทางที่ทำงานจริง แต่ผลของผู้รับเพียงรายเดียวก็ยังไม่ควรถูกขยายเป็นพฤติกรรมการส่งถึงสำหรับทุกกรณี

ประเมิน DMARC alignment เป็นขั้นตอนแยกต่างหาก

SPF อาจ pass สำหรับโดเมน return-path ที่ผู้ให้บริการเป็นเจ้าของ แต่ DMARC ก็ยังใช้ผลนั้นไม่ได้ กฎ DMARC ปัจจุบันเปรียบเทียบโดเมน RFC5321.MailFrom ที่ผ่านการยืนยันตัวตนด้วย SPF สำเร็จ กับโดเมนผู้เขียนในฟิลด์ RFC5322.From ที่ผู้รับมองเห็น alignment แบบ strict ต้องเป็นโดเมน DNS เดียวกัน ส่วน alignment แบบ relaxed อนุญาตโดเมนที่ resolve ไปยัง organizational domain เดียวกันตามกฎการค้นหาของ DMARC ตัวอย่างเช่น bounces.example.test กับ example.test align กันได้ในโหมด relaxed แต่ bounce.provider.test กับ example.test ไม่ align ผล DMARC อาจอาศัยลายเซ็น DKIM ที่ผ่านการยืนยันและ align แทนได้ ดังนั้นผล SPF ที่ไม่ align ไม่ได้หมายความว่า DMARC จะล้มเหลวเสมอไป ให้รายงานการยืนยันตัวตนและ alignment แยกจากกัน และใช้ขั้นตอนการค้นหาโดเมนล่าสุด แทนการเปรียบเทียบสองป้ายท้ายที่ฮาร์ดโค้ดไว้

ทดสอบการตั้งค่า MAIL FROM เฉพาะของผู้ให้บริการ

การตั้งค่าผู้ให้บริการเป็นตัวกำหนดว่าตัวตน SPF ใดจะปรากฏบนสายส่งจริง ตัวอย่างเช่น Amazon SES มีเอกสารเกี่ยวกับโดเมน MAIL FROM แบบกำหนดเองที่ต้องมีเรคคอร์ด MX และเรคคอร์ด SPF TXT ของตัวเอง SES อาจ fallback ไปใช้โดเมน MAIL FROM amazonses.com ที่ขึ้นกับ region เมื่อ MX ของโดเมนที่กำหนดเองตั้งค่าผิด หรืออาจปฏิเสธการส่ง ขึ้นอยู่กับพฤติกรรมที่ตั้งค่าไว้ การ fallback นั้นอาจเปลี่ยน DMARC alignment แม้ที่อยู่ From ที่มองเห็นจะไม่เปลี่ยน สำหรับผู้ให้บริการทุกราย ให้บันทึกโดเมน return-path ที่ตั้งค่าไว้ ค่า DNS ที่ต้องใช้ พฤติกรรม fallback region ที่ส่ง และความเป็นเจ้าของ หลังการเปลี่ยนแปลง DNS หรือผู้ให้บริการ ให้รอให้คำตอบที่แคชไว้หมดอายุ จากนั้นทำการประเมิน DNS และส่งทดสอบแบบควบคุมซ้ำ อย่าคัดลอก include ของผู้ให้บริการไปไว้ในโดเมน From ที่มองเห็น เว้นแต่นั่นคือตัวตนจริง และรายการผู้ส่งทั้งหมดของโดเมนรองรับเช่นนั้น

ใช้การตรวจสอบ SPF ที่ทำซ้ำได้ระหว่างการเปลี่ยนแปลง

เก็บหนึ่งแถวต่อหนึ่งเส้นทางการส่ง พร้อมเจ้าของ แอปพลิเคชัน ประเภทข้อความ โดเมน From ที่มองเห็น โดเมน MAIL FROM โดเมน HELO ช่วงต้นทางที่คาดไว้ การพึ่งพาผู้ให้บริการ และเวลาทดสอบแบบควบคุมล่าสุด เก็บการตรวจสอบ SPF แต่ละครั้งพร้อมเรคคอร์ดที่เลือก ร่องรอยแบบเรียกซ้ำ จำนวนการค้นหา DNS mechanism ที่ตรงกัน ผลลัพธ์ การตัดสิน alignment และตัวระบุการทดสอบที่ไม่อ่อนไหว ระหว่างการย้ายระบบ ให้คงการอนุญาตต้นทางที่ถูกต้องทั้งเก่าและใหม่ไว้เฉพาะช่วงเปลี่ยนผ่านที่จำเป็น ตรวจสอบเส้นทางใหม่ แล้วจึงลบการอนุญาตที่ล้าสมัยอย่างตั้งใจ เฝ้าติดตามข้อผิดพลาดการยืนยันตัวตนทั้งถาวรและชั่วคราว แทนที่จะตอบสนองเฉพาะเมื่อมีการปฏิเสธ ทำการตรวจสอบซ้ำหลังการเปลี่ยนผู้ให้บริการ การย้ายพูล IP การเปลี่ยนโดเมน การแก้ไข DNS หรือมีแอปพลิเคชันใหม่ เวิร์กโฟลว์นี้ช่วยจับได้ทั้งนโยบายที่แคบเกินไปจนบล็อกเส้นทางที่ถูกต้อง และนโยบายที่กว้างเกินไปจนคงการอนุญาตที่ไม่ได้ใช้ไว้

ตรวจสอบ SendHQ ด้วยมาตรฐานหลักฐานเดียวกัน

SendHQ ระบุว่าการส่งโดยตรงต้องใช้ที่อยู่บนโดเมนเวิร์กสเปซที่ยืนยันแล้ว ซึ่งยืนยันตัวตนผู้ส่ง แต่ไม่ทดแทนการประเมิน SPF ข้อความ SendHQ ที่ควบคุมได้ยังต้องใช้ DNS trace การตรวจสอบ received header ผล SPF และการตรวจสอบ DMARC alignment แบบเดียวกับที่อธิบายข้างต้น

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

แหล่งอ้างอิง

• ข้อกำหนด RFC 7208: Sender Policy Framework — IETF
• ข้อกำหนด RFC 5321: Simple Mail Transfer Protocol — IETF
• ข้อกำหนด RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance — RFC Editor
• การใช้โดเมน MAIL FROM แบบกำหนดเองใน Amazon SES — Amazon Web Services
• สัญญา OpenAPI ของ SendHQ — SendHQ