ไวยากรณ์เรคคอร์ด SPF คืออะไร และส่งผลต่ออีเมลของแอปพลิเคชันอย่างไร

เรคคอร์ด SPF คือนิพจน์นโยบายที่มีลำดับ

RFC 7208 กำหนดให้เรคคอร์ด SPF เป็นสตริง TXT ใน DNS ที่ term แรกคือ v=spf1 term ที่เหลือที่คั่นด้วยช่องว่างคือ mechanism ซึ่งอาจตรงกัน และ modifier ซึ่งเปลี่ยนการประมวลผล การประเมินทำจากซ้ายไปขวาและหยุดที่ mechanism แรกที่ตรงกัน ลำดับจึงสื่อถึงนโยบาย เรคคอร์ดทั่วไปอาจอนุญาตช่วงที่อยู่คงที่สองช่วง include นโยบายของผู้ให้บริการหนึ่งราย แล้วลงท้ายด้วย -all อย่าวางรูปแบบนั้นโดยไม่ปรับ เรคคอร์ดที่ถูกต้องขึ้นกับตัวตน SMTP MAIL FROM หรือ HELO ที่แน่นอนและแหล่งส่งจริง ให้ตรวจสอบรายการผู้ให้บริการแอปพลิเคชัน เมลเซิร์ฟเวอร์ เครื่องมือซัพพอร์ต แพลตฟอร์มตัวตน ระบบการตลาด เส้นทางการส่งต่อ และผู้ส่งสำหรับ disaster recovery ก่อน เผยแพร่นโยบายที่โดเมนที่ถูกประเมิน ไม่ใช่โดเมน From ที่มองเห็นโดยอัตโนมัติ เรคคอร์ดที่ไวยากรณ์ถูกต้องเพียงรายการเดียวก็ยังอาจอนุญาตแหล่งที่ผิด ละเว้นสตรีมของ production หรือเกินขีดจำกัดการประเมิน DNS ได้

Qualifier แมปการตรงกันของ mechanism เป็นผลลัพธ์ SPF

mechanism อาจขึ้นต้นด้วย qualifier ได้แก่ + สำหรับ pass, - สำหรับ fail, ~ สำหรับ softfail หรือ ? สำหรับ neutral หากไม่มี qualifier จะถือว่าเป็น + qualifier มีผลเมื่อ mechanism นั้นตรงกันเท่านั้น และไม่เปลี่ยนว่า term ถัดไปจะถูกประเมินหรือไม่เมื่อ mechanism ไม่ตรงกัน ทีมมักสนใจ term all ตัวสุดท้าย แต่ include, address, a, mx หรือ exists ทุกตัวก่อนหน้าก็มี qualifier และสามารถยุติการประเมินได้ ให้ทบทวนอย่างชัดเจน แทนที่จะสันนิษฐานว่า ~all คือโหมดทดสอบ หรือ -all พิสูจน์ว่ารู้จักทุกแหล่งแล้ว ผล fail คือหลักฐานของผู้รับเกี่ยวกับตัวตน SMTP และ IP ที่ถูกประเมิน ไม่ใช่คำสั่งสากลให้ลบอีเมล ผู้รับใช้นโยบายท้องถิ่นของตน neutral และ softfail ไม่ใช่การอนุญาตแบบ pass บันทึกผลลัพธ์ที่ตั้งใจสำหรับแหล่งที่ได้รับอนุญาต ไม่ได้รับอนุญาต และยังหาข้อสรุปไม่ได้ชั่วคราว และตรวจสอบด้วย fixture ของ IP และตัวตนที่ควบคุมได้

Address mechanism ตรงไปตรงมาแต่ต้องมีเจ้าของ

mechanism ip4 และ ip6 อนุญาตช่วงเครือข่ายที่ตรงกัน ซึ่งเขียนด้วยไวยากรณ์เฉพาะของโปรโตคอลและความยาวคำนำหน้าที่เป็นทางเลือก ไม่ต้อง lookup ที่อยู่เพิ่มระหว่างประเมิน แต่อาจล้าสมัยเมื่อเครือข่าย egress เปลี่ยน ให้ใช้ที่อยู่ส่งสาธารณะ ไม่ใช่ที่อยู่ของรันไทม์ภายใน และให้ช่วงแคบที่สุดเท่าที่ failover เชิงปฏิบัติการอนุญาต ทุกช่วงควรมีเจ้าของ ระบบต้นทาง สภาพแวดล้อม ขั้นตอนการเปลี่ยนแปลง และวันทบทวน mechanism a ค้นหาชื่อ A หรือ AAAA โดยค่าเริ่มต้นเป็นโดเมน SPF ปัจจุบันเว้นแต่ระบุ domain-spec อื่น mechanism mx ค้นหาโฮสต์ MX และที่อยู่ของโฮสต์เหล่านั้น mechanism เหล่านี้เพิ่มงาน DNS และอาจอนุญาตโครงสร้างพื้นฐานที่เปลี่ยนนอกรอบการปล่อยของแอปพลิเคชัน อย่าใช้ a หรือ mx เป็นทางลัด เว้นแต่ที่อยู่ทั้งหมดที่ resolve ได้ตั้งใจให้ส่งด้วยตัวตน SMTP นั้นได้ ติดตามการเปลี่ยนแปลงและทดสอบทั้งเส้นทาง IPv4 และ IPv6

Include ประเมินนโยบายอื่น ไม่ใช่ชิ้นส่วนข้อความ

mechanism include ประเมินนโยบาย SPF ของโดเมนที่อ้างถึง และตรงกันเมื่อการประเมินซ้อนนั้นคืนผล pass มันไม่ได้วาง term ลงในสตริงปัจจุบันแบบกลไก และผลลัพธ์ซ้อนอื่น ๆ มีผลที่กำหนดไว้ ใช้ include เฉพาะเมื่อองค์กรที่อ้างถึงระบุโดเมนนั้นไว้ในเอกสารสำหรับความสัมพันธ์การส่งของคุณอย่างชัดเจน โดเมนเว็บไซต์ โดเมน MX หรือโดเมน From ที่มองเห็นของผู้ให้บริการไม่ใช่ SPF include โดยอัตโนมัติ include สร้างส่วนพึ่งพาเชิงปฏิบัติการ การเปลี่ยนเรคคอร์ดของผู้ให้บริการอาจเปลี่ยนการอนุญาต เพิ่ม DNS lookup ซ้อน หรือทำให้เกิดข้อผิดพลาดชั่วคราวและถาวร บันทึกผู้ให้บริการ บริการ โดเมน include ที่แน่นอน แหล่งสัญญา เจ้าของ และแผนการลบ ทดสอบนโยบายที่ได้จาก IP ส่งจริงของผู้ให้บริการและโดเมน envelope ของคุณ อย่า flatten include ของผู้ให้บริการเป็นรายการ IP ที่คัดลอกมา เว้นแต่คุณยอมรับความเป็นเจ้าของในการติดตามทุกการเปลี่ยนที่อยู่ของผู้ให้บริการและรักษาความหมายดั้งเดิม

all, redirect และ explanation มีบทบาทต่างกัน

mechanism all ตรงกันเสมอและโดยปกติวางไว้ท้ายสุด term หลังจากนั้นไม่มีผลต่อการประเมิน qualifier ของมันกำหนดผลสำหรับแหล่งที่ไม่ตรงกับ term ก่อนหน้า modifier redirect บอกให้ SPF ใช้นโยบายของโดเมนอื่น เมื่อไม่มี mechanism ในเรคคอร์ดปัจจุบันตรงกัน redirect ไม่เหมือน include คือ include เป็น mechanism ที่มีลำดับหนึ่งตัว ส่วน redirect แทนที่การตัดสินใจนโยบายสุดท้ายภายใต้เงื่อนไขที่กำหนด เรคคอร์ดไม่ควรมี modifier redirect หลายตัว modifier exp อ้างถึงคำอธิบายสำหรับผล fail ได้ แต่ไม่ได้อนุญาตอีเมล และสร้างข้อพิจารณาด้านการปฏิบัติการและความเป็นส่วนตัวเพิ่มเติม ให้คำอธิบายเป็นแบบทั่วไปและหลีกเลี่ยงข้อมูลผู้ส่งหรือผู้รับ เลือก redirect เมื่อโดเมนตั้งใจใช้นโยบายทั้งชุดร่วมกันและมีเจ้าของที่ประสานงานกัน เลือก include เมื่อเพิ่มแหล่งที่ได้รับอนุญาตของผู้ให้บริการหนึ่งรายภายในนโยบายท้องถิ่นที่กว้างกว่า ทดสอบเส้นทางที่ไม่ตรงกัน ไม่ใช่แค่ผล pass ที่คาดไว้

หลีกเลี่ยง ptr และถือว่า exists กับ macro เป็นเรื่องขั้นสูง

RFC 7208 ระบุว่าไม่ควรใช้ mechanism ptr เพราะช้า ไม่น่าเชื่อถือ และเป็นภาระ อย่าเพิ่ม ptr เพื่อทำให้ IP ที่ไม่คุ้นเคยผ่าน mechanism exists ทดสอบการมีอยู่ใน DNS โดยใช้ domain-spec และ macro ของ SPF ขยายส่วนประกอบของตัวตนและการเชื่อมต่อภายในฟิลด์ที่รองรับ เครื่องมือเหล่านี้สื่อการอนุญาตแบบมอบหมายหรือรายลูกค้าได้ แต่เพิ่มความซับซ้อน งาน DNS การเปิดเผยข้อมูลส่วนบุคคล และรูปแบบความล้มเหลว ไวยากรณ์ macro ไม่ใช่การทำเทมเพลตสตริงตามอำเภอใจ มีเพียงตัวอักษร transformer ตัวคั่น และบริบทที่กำหนดเท่านั้นที่ถูกต้อง ห้ามใส่ที่อยู่ผู้รับเต็ม ความลับ หรืออินพุต tenant ที่ไม่มีขอบเขตลงใน DNS query หากชุดช่วง IP ที่เป็นเจ้าของอย่างง่ายและ include ของผู้ให้บริการที่มีเอกสารสื่อนโยบายได้ ให้เลือกแบบนั้น สำหรับนโยบายขั้นสูง ให้สร้าง fixture ที่กำหนดผลได้สำหรับหลายโดเมน ผู้ส่ง ตระกูล IP null reverse path การ escape ของ macro NXDOMAIN timeout และคำตอบ DNS ที่ไม่คาดคิด ก่อนขึ้น production

เคารพขีดจำกัด DNS lookup สิบ term

RFC 7208 จำกัดการ implement SPF ไว้ที่สิบ term ที่ทำให้เกิด DNS query ระหว่างการตรวจสอบหนึ่งครั้ง รวมการประมวลผล include, a, mx, ptr, exists และ redirect ที่เกี่ยวข้อง include ซ้อนก็นับรวม ข้อกำหนดยังแนะนำให้จำกัด void lookup ซึ่ง DNS ส่งคำตอบว่างหรือ name error ไว้ที่สองครั้ง การเกินขีดจำกัดการประมวลผลอาจทำให้เกิดข้อผิดพลาดถาวรแทนที่จะเป็น pass ให้นับกราฟการประเมินที่ขยายแล้ว ไม่ใช่แค่ term ที่เห็นในสตริง TXT ระดับบนสุด include ของผู้ให้บริการรายเดียวอาจนำส่วนพึ่งพาซ้อนหลายรายการมา และ mechanism mx อาจทำให้เกิดการ lookup ที่อยู่ของหลายโฮสต์ ใช้ตัวประเมินที่ตระหนักถึงมาตรฐานพร้อม fixture DNS ที่บันทึกไว้ แต่ก็ตรวจต้นไม้ส่วนพึ่งพาด้วยตนเอง ลบผู้ให้บริการที่ไม่ใช้และ mechanism ที่ซ้ำซ้อน หลีกเลี่ยง flattening ที่ไม่ปลอดภัยซึ่งทำให้เสียการอัปเดตของผู้ให้บริการอย่างเงียบ ๆ ติดตามการเปลี่ยนแปลงนโยบาย และเหลือพื้นที่ lookup ไว้สำหรับการเปลี่ยนแปลงของผู้ให้บริการ แทนการ deploy ที่ค่าสูงสุดพอดี

เผยแพร่นโยบาย SPF เพียงหนึ่งรายการต่อโดเมน

RFC 7208 ใช้เรคคอร์ด TXT ใน DNS สำหรับ SPF และกำหนดให้เลือกเรคคอร์ดที่ขึ้นต้นด้วย v=spf1 เรคคอร์ด SPF หลายรายการที่ชื่อเจ้าของเดียวกันทำให้เกิดข้อผิดพลาดถาวร แทนที่จะรวมการอนุญาตเข้าด้วยกัน ให้แก้ไขนโยบายที่มีอยู่ภายใต้เจ้าของที่ประสานงานกัน อย่าเพิ่มเรคคอร์ด TXT ที่สองเพียงเพราะแอปพลิเคชันอื่นต้องการเข้าถึง เรคคอร์ด TXT อื่นที่ไม่เกี่ยวข้องที่ชื่อเดียวกันอยู่ร่วมกันได้ แต่ควรมีนโยบาย SPF ที่ถูกเลือกเพียงรายการเดียว ยืนยันพฤติกรรมการใส่เครื่องหมายคำพูดและการแบ่งสตริงของ control plane DNS ค้นหาจากเซิร์ฟเวอร์ authoritative แล้วค้นหาจาก recursive resolver อิสระ เก็บค่าและ TTL เดิมไว้เพื่อย้อนกลับ การ propagate ของ DNS ไม่ได้เกิดทันที และ negative cache อาจคงอยู่ เครื่องหมายถูกสีเขียวในแดชบอร์ดพิสูจน์เพียงคำค้นและพฤติกรรม parser ที่มันสังเกต ตรวจสอบโดเมน envelope จริงใน production จากเฮดเดอร์ดิบที่ได้รับและล็อกของผู้ให้บริการ รวมถึงซับโดเมนและที่อยู่ bounce ที่อาจเผยแพร่นโยบายแยกกัน

เชื่อม SPF syntax กับ DMARC โดยไม่ปะปนกัน

โดยปกติ SPF ประเมินโดเมน MAIL FROM หรือตัวตน HELO ตามกฎของโปรโตคอล DMARC ใช้โดเมน RFC 5322 From ที่มองเห็น และยอมรับ SPF เป็นเส้นทางหนึ่งเมื่อโดเมน SPF ที่ยืนยันตัวตนแล้ว align กับโดเมนที่มองเห็นนั้นเท่านั้น ดังนั้น return-path ของผู้ให้บริการอาจผ่าน SPF แต่ยังไม่ align สำหรับ DMARC ในทางกลับกัน DKIM ที่ align และผ่านอาจทำให้ DMARC ผ่านได้เมื่อ SPF ล้มเหลวหรือไม่ align ให้บันทึกผล SPF โดเมนที่ประเมิน IP ที่เชื่อมต่อ From ที่มองเห็น ผล DKIM alignment และผล DMARC แยกกัน การส่งต่อมักเปลี่ยน IP ที่เชื่อมต่อและทำให้ SPF พังได้แม้ผู้ส่งเดิมได้รับอนุญาต อย่าขยาย SPF ให้รวมผู้ส่งต่อตามอำเภอใจ ใช้ DKIM และเมื่อเหมาะสมใช้กลไก authenticated-chain และหลักฐานจากผู้รับ SPF pass ไม่ได้พิสูจน์ความสมบูรณ์ของข้อความ ความปลอดภัยของเนื้อหา ความยินยอมของผู้รับ การยอมรับของเซิร์ฟเวอร์ หรือการเข้ากล่องจดหมาย

ตรวจสอบการเปลี่ยนแปลงด้วยเวิร์กโฟลว์ที่กำหนดผลได้

ก่อนแก้ไข DNS ให้ส่งออกเรคคอร์ดปัจจุบันและระบุ mechanism หรือ modifier แต่ละตัวพร้อมเจ้าของและวัตถุประสงค์ แยกวิเคราะห์ตัวเลือกใหม่ตามไวยากรณ์ของ RFC 7208 ขยายส่วนพึ่งพา DNS จากสแนปช็อตที่ควบคุมได้ นับ term ที่ทำให้เกิด lookup และทดสอบด้วย fixture IPv4 และ IPv6 ที่ได้รับอนุญาตและไม่ได้รับอนุญาต ตรวจสอบพฤติกรรม pass, fail, neutral, softfail, temporary error และ permanent error ของ include ซ้อน ทดสอบการจัดการ null reverse-path ผ่าน HELO ซับโดเมน return path ของผู้ให้บริการ และแหล่งที่ควรตกลงไปที่ all เผยแพร่ผ่านการควบคุมการเปลี่ยนแปลงปกติ ค้นหา DNS แบบ authoritative และ recursive แล้วส่งข้อความทดสอบแบบควบคุมผ่านทุกสตรีมจริง เก็บ Authentication-Results ดิบจากผู้รับที่เชื่อถือได้และเปรียบเทียบกับตัวตนที่คาดไว้ ย้อนกลับเมื่อขาดแหล่งของ production เลือกเรคคอร์ดหลายรายการ เกิดข้อผิดพลาดขีดจำกัด lookup temperror แพร่หลาย หรืออนุญาตโดยไม่ตั้งใจ ห้ามทดสอบด้วยการส่งอีเมลที่ผู้รับไม่ได้ร้องขอ

ตั้งค่า SPF ด้วย SendHQ

SendHQ จัดเตรียมนโยบาย SPF TXT เป็นส่วนหนึ่งของการตั้งค่าตัวตนผู้ส่ง โดยหยุดการตั้งค่าเมื่อนโยบาย SPF ขัดแย้งกัน และรายงานค่า SPF ที่รวมแล้วที่แนะนำ แทนการเขียนทับนโยบายที่ไม่เกี่ยวข้องอย่างเงียบ ๆ ให้คงนโยบาย SPF ที่เลือกได้เพียงหนึ่งรายการ โปรดดูเอกสาร Domains และ DNS สำหรับรายละเอียดการตั้งค่าและการแก้ไข

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

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

• ข้อกำหนด RFC 7208: Sender Policy Framework — RFC Editor
• ข้อกำหนด RFC 7489: Domain-based Message Authentication, Reporting, and Conformance — RFC Editor
• ข้อกำหนด RFC 5321: Simple Mail Transfer Protocol — RFC Editor