ศัพท์ · dmarc check

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

การตรวจสอบ DMARC ควรยืนยันสี่อย่างที่แยกจากกัน คือ ค้นพบนโยบายที่ถูกต้องใน DNS ได้ แท็กที่จำเป็นของนโยบายแยกวิเคราะห์ได้ถูกต้อง ตัวระบุ SPF หรือ DKIM ที่ยืนยันตัวตนแล้วอย่างน้อยหนึ่งตัว align กับโดเมน From ที่มองเห็นบนข้อความจริง และผู้ส่งของแอปพลิเคชันที่ถูกต้องทุกตัวถูกนับรวมก่อนบังคับใช้ ให้ค้นหาชื่อ _dmarc ตรวจสอบเรคคอร์ด แล้วตรวจผลการยืนยันตัวตนของข้อความจากการส่งแบบควบคุม DMARC pass ยืนยันว่าการใช้โดเมนได้รับอนุญาต ไม่ได้พิสูจน์การส่งถึงหรือการเข้ากล่องจดหมาย

มอง DMARC check เป็นสี่การทดสอบ ไม่ใช่การค้นหาครั้งเดียว

การตรวจสอบที่มีประโยชน์มีสี่ชั้น ชั้นแรก ค้นหานโยบายที่ใช้กับโดเมนผู้เขียนของข้อความ ชั้นที่สอง ตรวจสอบเรคคอร์ด TXT ว่าเป็นนโยบาย DMARC แทนที่จะยอมรับข้อความใดก็ตามที่ DNS ส่งกลับมา ชั้นที่สาม ทดสอบ alignment ของตัวระบุบนข้อความจริง โดเมน MAIL FROM ที่ SPF ยืนยันตัวตน หรือโดเมนที่ลงลายเซ็น DKIM ที่ยืนยันแล้ว ต้อง align กับโดเมนในเฮดเดอร์ From ที่มองเห็น ชั้นที่สี่ ยืนยันความครอบคลุมเชิงปฏิบัติการโดยส่งผ่านทุกแอปพลิเคชัน ผู้ให้บริการ ภูมิภาค และประเภทข้อความที่ใช้โดเมนนี้อย่างถูกต้อง การค้นหา DNS ที่เป็นสีเขียวครอบคลุมเพียงบางส่วนของสองชั้นแรก ไม่สามารถแสดงว่าผู้ให้บริการลงลายเซ็นด้วยโดเมนที่ตั้งใจ custom return path ทำงานอยู่ การส่งต่อเปลี่ยนพฤติกรรม SPF หรือระบบที่มองข้ามไปจะรอดจากนโยบายบังคับใช้

ค้นหาชื่อ DNS ที่ถูกต้องและตามกระบวนการค้นหานโยบาย

เริ่มจากโดเมนที่แน่นอนในเฮดเดอร์ RFC5322 From ซึ่งมักเรียกว่าโดเมนผู้เขียน ค้นหา TXT ที่ _dmarc ตามด้วยโดเมนนั้น สำหรับข้อความจาก alerts@notify.example.test ให้เริ่มที่ _dmarc.notify.example.test ไม่ใช่โฮสต์ของเว็บไซต์ โฮสต์ MX หรือโดเมน return-path RFC 9989 กำหนดการค้นหานโยบายมากกว่าการค้นหาครั้งเดียว หากโดเมนผู้เขียนไม่มีเรคคอร์ดที่ถูกต้อง ผู้รับสามารถไล่ตาม DNS tree เพื่อหานโยบายของโดเมนองค์กรหรือ public suffix ที่เกี่ยวข้อง การจัดการซับโดเมนอาจมาจากแท็ก sp, np หรือ p ขึ้นอยู่กับสิ่งที่มีอยู่และตำแหน่งที่พบนโยบาย ดังนั้นตัวตรวจสอบควรรายงานทั้งชื่อที่ค้นหาและโดเมนนโยบายที่เลือกจริง ผลลัพธ์ที่บอกเพียงว่าพบเรคคอร์ดอาจซ่อนข้อผิดพลาดจากการสืบทอด หรือนโยบายซับโดเมนที่ระบุชัดซึ่งเปลี่ยนการจัดการที่คาดไว้

ตรวจสอบโครงสร้างเรคคอร์ดก่อนตีความนโยบาย

เรคคอร์ดนโยบาย DMARC ใช้ไวยากรณ์ tag-value ภายใต้ RFC 9989 จำเป็นต้องมี v=DMARC1 ซึ่งแยกตัวพิมพ์เล็กใหญ่และต้องปรากฏก่อน และ tag p ที่ใช้ได้ระบุนโยบายการประเมินที่ร้องขอ ค่านโยบายที่พบบ่อยคือ none, quarantine และ reject tag ทางเลือกอธิบายปลายทางการรายงาน พฤติกรรมโดเมนย่อย และ SPF กับ DKIM alignment แบบ strict หรือ relaxed อย่าซ่อม tag ที่สะกดผิด ค่า p ที่หายไป เรคคอร์ดซ้ำหรือขัดแย้ง ตัวคั่นที่ไม่ถูกต้อง หรือค่าที่คัดลอกมาพร้อมสิ่งตกค้างจากการใส่เครื่องหมายคำพูดของผู้ให้บริการ DNS อย่างเงียบ ๆ ให้ถือ permanent evaluation error เป็นผลที่ต้องแก้ไข ไม่ใช่ DMARC pass หรือ fail และแยก DNS lookup error ชั่วคราวออกจากเรคคอร์ดผิดรูปแบบ ลองใหม่เมื่อ resolver ล้มเหลวชั่วคราวผ่านเส้นทางที่ควบคุมได้ แต่อย่าอ้างว่าโดเมนไม่มีนโยบายจนกว่าจะ query authoritative DNS ได้อย่างน่าเชื่อถือ

ตรวจสอบ alignment ของ SPF และ DKIM บนข้อความจริง

DMARC ถูกประเมินจากการยืนยันตัวตนของข้อความ ไม่ใช่การตั้งค่า DNS โดด ๆ สำหรับ SPF ให้เทียบโดเมน MAIL FROM ที่ยืนยันตัวตนกับโดเมน From ที่มองเห็น สำหรับ DKIM ให้เทียบโดเมน d= ของลายเซ็นแต่ละอันที่ยืนยันสำเร็จกับโดเมน From ที่มองเห็น alignment แบบ relaxed ยอมรับโดเมนที่มีโดเมนองค์กรเดียวกัน ส่วนแบบ strict ต้องเป็นโดเมนเดียวกันทุกตัวอักษร ข้อความผ่านเมื่อมีตัวระบุที่ยืนยันตัวตนอย่างน้อยหนึ่งตัวผ่านกลไกพื้นฐานของตนและ align ตัวอย่างเช่น return path ของผู้ให้บริการอาจทำให้ SPF ผ่านสำหรับโดเมนของผู้ให้บริการ แต่ไม่ align กับ billing.example.test หาก DKIM ยืนยันด้วย d=example.test ภายใต้ alignment แบบ relaxed ข้อความก็ยังผ่าน DMARC ได้ ให้เก็บเฮดเดอร์ Authentication-Results ดิบจากบัญชีผู้รับที่ควบคุมได้ แต่ตีความตามบริบท เพราะเป็นผลของผู้รับที่ทำการประเมิน และอาจมีหลาย hop หรือหลายลายเซ็น

อ่านผล pass, fail, none และ error ให้แม่นยำ

DMARC pass หมายความว่ามีเรคคอร์ดนโยบายที่ใช้ได้ และตัวระบุ SPF หรือ DKIM ที่ยืนยันตัวตนแล้วมี alignment กับโดเมนผู้เขียน fail หมายความว่ามีนโยบายที่ใช้ได้ แต่ไม่มีตัวระบุที่ยืนยันตัวตนและมี alignment none หมายความว่าไม่พบนโยบายที่ใช้ได้ Permerror และ temperror ระบุข้อผิดพลาดระหว่างการประเมิน DMARC ข้อความที่มีข้อผิดพลาด DNS ไม่อาจถือว่าผ่านหรือล้มเหลว DMARC ผลลัพธ์เหล่านี้ไม่ได้บอกว่าผู้ให้บริการกล่องจดหมายวางข้อความไว้ที่ใด RFC 9989 จำกัดความหมายของ pass ไว้อย่างชัดเจนว่าเป็นการตรวจสอบว่าการใช้งานของเจ้าของโดเมนได้รับอนุญาต ไม่ได้ยืนยันว่าข้อความปลอดภัย เป็นที่ต้องการ มีชื่อเสียงดี หรือเหมาะกับกล่องจดหมาย ให้เก็บการยอมรับของผู้ให้บริการ การยอมรับของเซิร์ฟเวอร์ผู้รับ ผล DMARC สัญญาณการร้องเรียน และตำแหน่งที่สังเกตได้เป็นฟิลด์แยกกันในระบบวินิจฉัยและแดชบอร์ด

จัดทำแผนผังผู้ส่งที่ถูกต้องทุกตัวก่อนบังคับใช้

ตรวจสอบรายการระบบทั้งหมดที่ใส่โดเมนใน From ได้แก่ แอปพลิเคชัน production อีเมลยืนยันตัวตน ประกาศการเรียกเก็บเงิน เครื่องมือซัพพอร์ต แพลตฟอร์มการตลาด การแจ้งเตือนจากการติดตาม เวิร์กโฟลว์ CRM บัญชีระดับภูมิภาค และระบบฉุกเฉิน สำหรับแต่ละสตรีม ให้บันทึกโดเมน From ที่มองเห็น โดเมน MAIL FROM โดเมนและ selector ของ DKIM d= บัญชีผู้ให้บริการ เจ้าของ ประเภทข้อความ และปริมาณที่คาดไว้ ส่งข้อความทดสอบแบบควบคุมผ่านเส้นทาง production ปกติ และตรวจสอบทั้งการยืนยันตัวตนและ alignment รายงาน DMARC แบบรวมช่วยเปิดเผยแหล่งที่ใช้โดเมน แต่ต้องตีความ และอาจรวมทราฟฟิกที่ถูกส่งต่อหรือไม่ได้รับอนุญาต ให้เริ่มด้วยการติดตามผลขณะที่รายการยังไม่ครบ แล้วแก้สตรีมที่ถูกต้องแต่ไม่ align ก่อนขอให้ผู้รับจัดการเข้มงวดขึ้น อย่าเปลี่ยนนโยบายองค์กรที่ใช้ร่วมกันเพียงเพื่อให้แอปพลิเคชันเดียวเป็นสีเขียว และอย่าเข้าสู่การบังคับใช้จากข้อความทดสอบเพียงข้อความเดียว

วินิจฉัยความล้มเหลวที่พบบ่อยของอีเมลแอปพลิเคชัน

หากไม่พบนโยบาย ให้ตรวจสอบโซน DNS และชื่อเรคคอร์ดก่อนแก้ไขค่า หากเรคคอร์ดมีข้อผิดพลาดถาวร ให้ลดเหลือนโยบายที่ถูกต้องหนึ่งรายการ และตรวจสอบลำดับแท็กและไวยากรณ์ หาก DKIM ไม่ผ่าน ให้ตรวจว่ามี selector ที่คาดไว้หรือไม่ ผู้ให้บริการลงลายเซ็นข้อความที่ทดสอบจริงหรือไม่ เนื้อหาหรือเฮดเดอร์ที่ลงลายเซ็นเปลี่ยนระหว่างทางหรือไม่ และโดเมน d= ที่ยืนยันแล้ว align หรือไม่ หาก SPF ผ่านแต่ DMARC ไม่ผ่าน ให้เทียบโดเมน MAIL FROM กับโดเมน From ที่มองเห็น แทนที่จะถือว่า SPF pass อย่างใดก็เพียงพอ หากเฉพาะอีเมลที่ถูกส่งต่อไม่ผ่าน ให้จำไว้ว่าการส่งต่อมักเปลี่ยนเส้นทาง envelope และทำให้ SPF พังได้ ในขณะที่ลายเซ็น DKIM ที่ align และถูกต้องอาจยังอยู่รอด หากการทยอยเปิดใช้ทำให้เกิดการปฏิเสธ ให้เก็บเฮดเดอร์ที่ล้มเหลวและการตอบกลับของผู้รับ หยุดยกระดับนโยบายต่อ และแก้สตรีมที่รับผิดชอบ แทนที่จะลดทอนการควบคุมการยืนยันตัวตนที่ไม่เกี่ยวข้อง

ใช้กฎ alignment เฉพาะของผู้ให้บริการอย่างตั้งใจ

ผู้ส่งบุคคลที่สามต้องมีการตั้งค่าที่ผูกตัวระบุที่ยืนยันตัวตนของตนเข้ากับโดเมนที่องค์กรควบคุม Amazon SES ระบุไว้ในเอกสารสองเส้นทาง คือโดเมน custom MAIL FROM ที่ align สำหรับ SPF และโดเมนลงลายเซ็น DKIM ที่ align return path เริ่มต้นที่ผู้ให้บริการเป็นเจ้าของอาจยืนยันตัวตนผ่าน SPF ได้โดยไม่ align กับโดเมน From ที่มองเห็น ดังนั้น DKIM จึงมักเป็นกลไกที่ align ได้จริง เว้นแต่จะตั้งค่าโดเมน custom MAIL FROM ผู้ให้บริการรายอื่นใช้ชื่อเรียก return path โดเมน bounce การยืนยันตัวตนโดเมน และตัวตนผู้ลงลายเซ็นที่ต่างกัน ให้ตรวจสอบข้อความขาออกจริง แทนที่จะสันนิษฐานว่าป้ายยืนยันในแดชบอร์ดทำให้ DMARC ผ่าน คำแนะนำสำหรับผู้ส่งของ Gmail ในปัจจุบันก็กำหนดให้มีการยืนยันตัวตนและ alignment สำหรับทราฟฟิกที่เกี่ยวข้อง และแนะนำการรายงาน DMARC ข้อกำหนดของผู้รับและฟีเจอร์ของผู้ให้บริการอาจเปลี่ยนแปลง จึงควรตรวจสอบเอกสารทางการซ้ำเมื่อเปิดตัวและเมื่อทบทวนเหตุการณ์

ใช้หลักฐานจากผู้ให้บริการโดยไม่ถือว่าเป็นคำตัดสิน DMARC

SendHQ รองรับการส่งจากโดเมนที่ยืนยันแล้ว อีเวนต์การส่ง การระงับการส่ง และแดชบอร์ดเว็บ ใช้ข้อมูลโดเมนส่งและข้อมูลการส่งเพื่อตรวจสอบ stream ของข้อความ จากนั้นตรวจสอบ DMARC จาก header Authentication-Results ของผู้รับ และแยกหลักฐาน SPF, DKIM และ alignment การยอมรับจากผู้ให้บริการและอีเวนต์การส่งไม่พิสูจน์การเข้ากล่องจดหมาย

บันทึกผลการตรวจสอบ DMARC ที่ตรวจสอบย้อนหลังได้

ผลลัพธ์ที่คงทนควรมีโดเมนผู้เขียน เวลาที่ค้นหา resolver ชื่อ _dmarc ที่ค้นหา โดเมนนโยบายที่เลือก เรคคอร์ดที่ปรับให้เป็นมาตรฐานแล้วที่แน่นอน โหมดนโยบายและ alignment สถานะ DNS และผลการแยกวิเคราะห์ว่าไวยากรณ์ใช้ได้หรือเกิด permerror หรือ temperror เพิ่มหนึ่งแถวต่อข้อความทดสอบแบบควบคุม พร้อมตัวระบุข้อความที่ไม่อ่อนไหว ระบบที่ส่ง โดเมน From ที่มองเห็น โดเมนและผล SPF ที่ยืนยันตัวตน โดเมนและ selector ของ DKIM ที่ยืนยันแล้ว การตัดสิน alignment ผล DMARC สุดท้าย และผู้รับ เก็บเฮดเดอร์ดิบไว้ในที่เก็บที่จำกัดสิทธิ์ เพราะอาจเปิดเผยที่อยู่ รายละเอียดการกำหนดเส้นทาง และตัวระบุภายใน เชื่อมโยงแต่ละข้อค้นพบกับเจ้าของและวันที่แก้ไข ตรวจสอบซ้ำหลัง TTL ของ DNS หมดอายุ การตั้งค่าผู้ให้บริการเปลี่ยน การหมุนเวียนคีย์ สตรีมข้อความใหม่ หรือการยกระดับนโยบาย หลักฐานนี้ทำให้การตรวจสอบทำซ้ำได้ และป้องกันไม่ให้ภาพหน้าจอหรือป้ายของเครื่องมือกลายเป็นหลักฐานถาวรหลังการตั้งค่าเบื้องหลังเปลี่ยนไป

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

ควรตรวจสอบเรคคอร์ด DMARC ที่ไหน

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

การพบ v=DMARC1 หมายความว่า DMARC ผ่านหรือไม่

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

DMARC ผ่านได้หรือไม่เมื่อ SPF ไม่ align

ได้ ลายเซ็น DKIM ที่ยืนยันสำเร็จสามารถให้ตัวระบุที่ยืนยันตัวตนและ align ซึ่ง DMARC ต้องการ กรณีกลับกันก็เป็นไปได้ คือ SPF ที่ align สามารถสนับสนุนการผ่านเมื่อ DKIM ไม่ผ่าน แม้การพึ่งกลไกเดียวจะลดความทนทาน

DMARC pass พิสูจน์การเข้ากล่องจดหมายหรือไม่

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

แอปพลิเคชันควรข้ามไปที่ p=reject ทันทีหรือไม่

โดยทั่วไปไม่ได้หากไม่มีรายการสินทรัพย์และหลักฐานการติดตาม แมปผู้ส่งที่ถูกต้องทุกคน ตรวจสอบ alignment บนข้อความที่ควบคุมได้ ตรวจทานรายงานรวม แก้ไขความล้มเหลว และประสานการเปลี่ยนนโยบายกับเจ้าของโดเมนก่อนขอการจัดการที่เข้มงวดขึ้น

ควรตรวจสอบซ้ำอะไรหลังเปลี่ยนผู้ให้บริการอีเมล

ตรวจสอบซ้ำนโยบายที่ค้นพบสำหรับแต่ละโดเมน From โดเมน MAIL FROM และ DKIM ของผู้ให้บริการ DNS ของ selector ผลของ SPF และ DKIM alignment แบบ relaxed หรือ strict รายงานแบบรวม และข้อความทดสอบแบบควบคุมของแอปพลิเคชันทุกประเภท ก่อนเพิ่มทราฟฟิกในระบบจริง

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