ตั้งค่า DMARC โดยไม่ทำเมลหาย: เริ่ม p=none ก่อนบังคับจริง

เริ่มตั้งค่า DMARC อย่างปลอดภัยด้วยการระบุทุกระบบที่ส่งอีเมลในนามโดเมนธุรกิจ เปิด SPF และ DKIM ให้ส่งเมลจริงผ่านการตรวจสอบ เตรียมกล่องรับรายงาน แล้วเผยแพร่ระเบียน TXT ที่ _dmarc ของโดเมนด้วยค่า p=none ก่อน การเริ่มในโหมดนี้ช่วยให้เห็นบริการที่ยังยืนยันตัวตนผิดพลาด โดยยังไม่ขอให้ผู้รับกักหรือปฏิเสธเมลเพราะ DMARC

รอให้ SPF และ DKIM ตรวจสอบเมลได้อย่างน้อย 48 ชั่วโมงตามคำแนะนำของ Google ก่อนเปิด DMARC จากนั้นใช้รายงานหาผู้ส่งที่ได้รับอนุญาตแต่ยังไม่ผ่าน และเปลี่ยนเป็น quarantine หรือ reject เมื่อแก้เส้นทางเหล่านั้นแล้ว p=none ลดความเสี่ยงจากการบังคับนโยบายเร็วเกินไป แต่เมลยังอาจถูกจัดเป็นสแปมด้วยกฎอื่นของผู้รับ จึงไม่ใช่คำรับประกันว่าเมลทุกฉบับจะเข้ากล่องหลัก

สำรวจทุกระบบที่ส่งด้วยโดเมนธุรกิจ

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

คู่มือ SPF ของ Google ให้รวบรวมโดเมนหรือ IP ของเซิร์ฟเวอร์ทุกแห่งที่ส่งเมลให้โดเมนก่อนเขียนระเบียน จึงควรถามเจ้าของแต่ละระบบว่าใครเป็นผู้ส่งจริง ใช้โดเมนใดใน Return-Path และตั้งค่า DKIM ด้วยโดเมนใด ชื่อบริษัทผู้ให้บริการอย่างเดียวไม่พอ เพราะบริการเดียวอาจมีหลายผลิตภัณฑ์หรือหลายเส้นทางส่ง

• บันทึกโดเมน From ของเมลแต่ละประเภท และระบุว่าผู้รับคาดว่าจะเห็นชื่อใด
• บันทึกระบบส่งจริง ผู้รับผิดชอบ และกรณีส่งผ่านผู้ให้บริการภายนอก
• เก็บโดเมน Return-Path กับโดเมน d= ของ DKIM จากเมลตัวอย่างที่ส่งสำเร็จ
• รวมเมลที่ส่งตามรอบ เช่น รายเดือน เมลต่ออายุ และข้อความที่เกิดเฉพาะเมื่อมีธุรกรรม

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

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

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

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

เปิด SPF และ DKIM ให้สอดคล้องกับ From

SPF เป็นระเบียน DNS TXT ที่ระบุเซิร์ฟเวอร์ที่ได้รับอนุญาตให้ส่งภายใต้โดเมนที่ใช้ตรวจ SPF ตรวจระเบียนเดิมก่อนเพิ่มบริการใหม่ และรวมผู้ส่งที่ใช้งานจริงไว้ในระเบียนที่ถูกต้องของแต่ละโดเมน ตัวอย่างสมมติสำหรับองค์กรที่ส่งผ่าน Google Workspace เพียงรายเดียวคือ v=spf1 include:_spf.google.com ~all; ถ้าใช้บริการอื่น ต้องใช้ค่าที่ผู้ให้บริการนั้นระบุและปรับให้ตรงกับเส้นทางจริง

ค่า ~all ในตัวอย่าง SPF เป็น soft fail สำหรับเซิร์ฟเวอร์ที่ไม่ได้อยู่ในรายการ ไม่ใช่คำสั่งเดียวกับ p=none ของ DMARC ผู้รับอาจจัดเมลจากเซิร์ฟเวอร์ที่ SPF ไม่รับรองเป็นเมลน่าสงสัยได้ตั้งแต่ก่อนบังคับ DMARC หากเปลี่ยนเป็น -all เร็วเกินไป ผลกระทบต่อผู้ส่งที่ตกหล่นอาจรุนแรงขึ้น จึงควรสำรวจผู้ส่งและทดสอบระเบียน SPF แยกจากการเปลี่ยนนโยบาย DMARC

การเพิ่มบริการใหม่โดยคัดลอกระเบียน SPF อีกบรรทัดไว้ที่ชื่อโดเมนเดิมไม่ใช่วิธีรวมสิทธิ์ ผู้ดูแลควรแก้รายการที่มีอยู่และตรวจว่าระเบียนที่เผยแพร่ตรงกับแผนส่งเมล หากระบบใช้โดเมนย่อยเป็น Return-Path ต้องตรวจ SPF ที่โดเมนย่อยนั้นด้วย เพราะตัวรับตรวจโดเมนในเส้นทางส่ง ไม่ได้อนุมานสิทธิ์จากชื่อโดเมนบริษัทในช่อง From เสมอไป

SPF ต้องประเมินโดเมนของผู้ส่งในระดับการส่งผ่าน SMTP จึงอาจต่างจากชื่อในช่อง From ที่ผู้รับเห็น การใส่ IP ของบริการใน SPF ของโดเมนหลักอย่างเดียวจึงอาจไม่ช่วย หากบริการใช้ Return-Path ในโดเมนของตนเอง สำหรับเส้นทางนั้นให้ตรวจว่าผู้ให้บริการตั้ง Return-Path เป็นโดเมนที่องค์กรควบคุมได้หรือไม่ และส่งเมลตัวอย่างมายืนยันผลหลังแก้ค่า

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

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

การตรวจ DKIM ต้องแยกชื่อ selector ออกจากโดเมนลงนาม selector ชี้ไปยังกุญแจที่ผู้รับต้องค้นใน DNS ส่วนค่า d= บอกโดเมนที่ผู้ส่งใช้รับรองลายเซ็น สำหรับ DMARC จุดตัดสินความสอดคล้องอยู่ที่โดเมนลงนาม ไม่ใช่ชื่อ selector เมื่อบริการเปลี่ยนกุญแจหรือเปิดการลงนามหลายชุด ให้ดูผลลัพธ์ของเมลจริงว่าอย่างน้อยหนึ่งลายเซ็นที่สอดคล้องยังผ่าน

ตัวอย่างสมมติ: ใบแจ้งหนี้แสดง From เป็น [email protected] แต่ผู้ให้บริการส่งด้วย Return-Path ในโดเมนของตนและลงนาม DKIM ด้วยโดเมนของตน แม้การตรวจของผู้ให้บริการจะผ่าน เมลฉบับนั้นก็ยังไม่ผ่าน DMARC สำหรับ example.com วิธีแก้คือให้ผู้ให้บริการรองรับ Return-Path หรือ DKIM ที่สอดคล้องกับโดเมนธุรกิจ แล้วทดสอบข้อความที่ส่งออกจริงอีกครั้ง

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

หากผู้ให้บริการภายนอกรองรับการลงนาม DKIM ด้วยโดเมนขององค์กร ให้ตั้งค่าโดเมนลงนามนั้นก่อนใช้การบังคับนโยบาย เส้นทางนี้มีประโยชน์เมื่อบริการต้องใช้ Return-Path ของตัวเอง เพราะ DMARC ต้องการเพียงวิธีใดวิธีหนึ่งที่ผ่านและสอดคล้องกับ From แต่การรองรับของแต่ละบริการต่างกัน ต้องตรวจค่าที่บริการเปิดให้กำหนดและผลของเมลจริง ไม่ใช่สมมติว่าทุกแพลตฟอร์มตั้งโดเมนเองได้

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

เผยแพร่ระเบียน p=none และรับรายงาน

สร้างกล่องหรือกลุ่มสำหรับรับรายงานก่อนเพิ่มระเบียน และกำหนดคนที่ติดตามข้อมูลได้จริง สำหรับตัวอย่างสมมติใช้ [email protected] ซึ่งเป็นที่อยู่ภายใต้โดเมนเดียวกัน หากใช้บริการรับรายงานในอีกโดเมนหนึ่ง ต้องตรวจเงื่อนไขการอนุญาตรับรายงานข้ามโดเมนของปลายทางก่อน มิฉะนั้นอาจตั้งค่า rua แล้วไม่เห็นรายงานตามที่คาด

ใน DNS ของ example.com ให้สร้างระเบียนชนิด TXT ที่ชื่อ _dmarc.example.com โดยใส่ค่า v=DMARC1; p=none; rua=mailto:[email protected] ตัวอย่างนี้ต้องเปลี่ยน example.com และที่อยู่กล่องรับเป็นค่าขององค์กรจริง v ระบุรุ่นของระเบียน p ระบุความต้องการด้านการจัดการเมลที่ไม่ผ่าน ส่วน rua เป็นปลายทางสำหรับรายงานภาพรวม ซึ่งควรเป็นกล่องที่รับข้อความและเอกสารแนบได้

รักษารูปแบบระเบียนให้เรียบง่ายในช่วงเริ่มต้น โดยให้ v=DMARC1 อยู่ต้นค่าและตามด้วย p=none จากนั้นจึงระบุ rua ตามที่อยู่รับรายงาน ไม่ต้องใส่ค่าเข้มงวดอื่นก่อนเห็นผลจากผู้ส่งจริง หากต้องเปลี่ยนปลายทางรายงานภายหลัง ให้แก้ที่อยู่ในระเบียนเดียวกันและตรวจว่ากล่องใหม่ได้รับข้อมูลก่อนปิดกล่องเดิม

หน้า DNS บางแห่งเติมชื่อโดเมนต่อท้ายช่อง Host ให้อัตโนมัติ จึงอาจต้องกรอกเพียง _dmarc แทนชื่อเต็ม หลังบันทึก ให้ตรวจชื่อระเบียนจากภายนอกว่าอ่านได้ที่ _dmarc ของโดเมนที่ต้องการ และค่าที่ตอบกลับตรงกับค่าที่ตั้งใจ หากมี DMARC อยู่แล้ว ให้แก้ระเบียนเดิมแทนการเพิ่มระเบียน DMARC อีกชุดที่ชื่อเดียวกัน

ก่อนอาศัยรายงานตัดสินใจ ส่งเมลทดสอบจากระบบหลักและผู้ส่งภายนอกแต่ละรายไปยังกล่องที่ดูส่วนหัวเมลได้ ตรวจ Authentication-Results ว่า SPF, DKIM และ DMARC ผ่านหรือไม่ พร้อมเทียบชื่อโดเมนที่ใช้ตรวจ ค่า DNS อาจยังไม่ปรากฏเท่ากันทุกเครือข่ายเพราะการเก็บข้อมูลชั่วคราว จึงควรตรวจระเบียนที่เผยแพร่จริงก่อนสรุปว่าการตั้งค่าล้มเหลว

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

p=none หมายถึงเจ้าของโดเมนยังไม่ขอให้ผู้รับเปลี่ยนการจัดการข้อความเพราะผล DMARC แต่ยังขอรับข้อมูลผ่าน rua ได้ เมื่อระบบส่งผิดพลาด เมลอาจยังมาถึงผู้รับ จึงเป็นช่วงเหมาะสำหรับแก้ค่าระบบโดยอาศัยทั้งผลทดสอบและรายงาน อย่างไรก็ตาม การรับรายงานขึ้นอยู่กับผู้รับที่รองรับและเลือกส่งข้อมูล ไม่ควรใช้ความเงียบของกล่องรายงานแทนหลักฐานว่าทุกเส้นทางผ่าน

ถ้าบริษัทส่งจากโดเมนย่อย ให้ตรวจว่านโยบายที่ผู้รับจะพบสำหรับโดเมนย่อยนั้นมาจากระเบียนของตนเองหรือสืบทอดจากโดเมนหลัก การเปลี่ยน p ของโดเมนหลักอาจกระทบเมลที่ใช้ From ในโดเมนย่อยซึ่งไม่มีนโยบายแยก ก่อนขยับความเข้มงวด จึงควรมีตัวอย่างเมลจริงจากโดเมนย่อยที่ใช้ส่งด้วย ไม่ใช่ทดสอบเฉพาะชื่อโดเมนหลัก

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

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

อ่านรายงานแล้วแยกเมลจริงจากการแอบอ้าง

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

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

เริ่มจับคู่แหล่งส่งกับบัญชีระบบที่สำรวจไว้ หากเป็นบริการที่ได้รับอนุญาต ให้แยกปัญหาว่าไม่ผ่านการยืนยันตัวตนหรือผ่านแต่โดเมนไม่สอดคล้องกัน SPF pass พร้อม DMARC fail มักชี้ให้ตรวจ Return-Path กับ From ขณะที่ DKIM pass พร้อม DMARC fail ให้ดูค่า d= ของลายเซ็นเทียบกับ From การแก้สองกรณีนี้ต่างจากการเพิ่ม IP เข้า SPF แบบไม่มีหลักฐานว่าเป็นผู้ส่งของบริษัท

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

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

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

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

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

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

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

ยกระดับเป็น quarantine หรือ reject เมื่อใด

เปลี่ยนเป็น p=quarantine เมื่อระบบส่งที่ได้รับอนุญาตถูกระบุครบและเส้นทางสำคัญผ่าน DMARC อย่างสม่ำเสมอ ค่านี้ขอให้ผู้รับจัดข้อความที่ไม่ผ่านเป็นเมลน่าสงสัย ซึ่งอาจลงโฟลเดอร์สแปม ติดตามรายงานควบคู่กับข้อร้องเรียนจากผู้รับและผลส่งของระบบธุรกิจ หากเมลจริงเริ่มถูกกัก ให้ระบุเส้นทางที่ล้มเหลวแล้วแก้การยืนยันตัวตนก่อนยกระดับต่อ

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

พิจารณา p=reject หลังตรวจทั้งเมลประจำ เมลที่ออกเป็นรอบ และผู้ส่งภายนอกที่ใช้โดเมนเดียวกัน ค่านี้ขอให้ผู้รับปฏิเสธข้อความที่ไม่ผ่าน DMARC จึงเพิ่มต้นทุนของผู้ส่งที่ตกหล่นอย่างชัดเจน เมลที่ผ่านการส่งต่อและรายชื่ออีเมลอาจมีปัญหาเพิ่มเติม เพราะ SPF อาจไม่ผ่านหลังเปลี่ยนเซิร์ฟเวอร์ส่ง และบางเส้นทางอาจทำให้ DKIM ไม่ผ่านด้วย

มาตรฐาน RFC 9989 แนะนำให้ใช้รายงานในช่วง p=none เพื่อค้นหาผู้ส่งที่ตกหล่นและแก้เมลจริงก่อนบังคับนโยบาย โดยระบุความเสี่ยงของ p=reject ต่อการส่งต่อและรายชื่ออีเมล สำหรับโดเมนที่ผู้ใช้ส่งข้อความเข้ารายชื่ออีเมล มาตรฐานเตือนเป็นพิเศษว่าการใช้ reject อาจรบกวนการส่งถึง จึงต้องตรวจรูปแบบการใช้งานนั้นก่อนตัดสินใจ

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

ถ้าพบเพียงบางประเภทเมลที่ยังไม่ผ่าน ให้แก้ที่ระบบนั้นก่อนเปลี่ยนค่า p สำหรับทุกเมลในโดเมน การตั้ง From ให้ใช้โดเมนของบริษัทโดยไม่มี SPF หรือ DKIM ที่สอดคล้องกันจะยังคงสร้าง DMARC fail ต่อให้แหล่งส่งเป็นคู่ค้าที่เชื่อถือได้ การแก้ที่ต้นทางทำให้ความพร้อมของบริการนั้นตรวจได้จากเมลทดสอบและรายงาน ไม่ต้องอาศัยการคาดเดาจากชื่อผู้ให้บริการ

สำหรับการส่งผ่านรายชื่ออีเมลหรือการส่งต่อ ให้ดูทั้งผลที่ปลายทางและลักษณะการใช้งานจริงขององค์กร หากผู้ใช้ต้องส่งถึงรายชื่อภายนอกเป็นงานประจำ การขยับไป reject มีความเสี่ยงอีกแบบหนึ่งที่เมลทดสอบส่งตรงจะไม่เผย ตรวจกรณีนี้กับผู้ดูแลรายชื่อและระบบส่งต่อก่อนตัดสินใจ และใช้ผลการกักเมลระหว่างช่วง quarantine ประกอบ

หลังเปลี่ยนนโยบาย ให้ติดตามผู้ส่งรายใหม่ที่เริ่มใช้โดเมนด้วย เพราะความพร้อมในวันที่ประกาศไม่ได้คงอยู่ตลอดไป ระบบบัญชี แพลตฟอร์มส่งแคมเปญ หรือผู้ให้บริการเว็บไซต์ที่เปลี่ยนภายหลังอาจทำให้ผลยืนยันตัวตนเปลี่ยนไป เมื่อมีการเพิ่มบริการ ควรนำเส้นทางใหม่นั้นกลับเข้ารายการผู้ส่งและทดสอบเมลก่อนเปิดใช้จริง

ถ้าผู้ให้บริการรายใดไม่สามารถตั้ง Return-Path หรือ DKIM ให้สอดคล้องกับโดเมนธุรกิจได้ ให้ตัดสินใจเรื่องผู้ส่งรายนั้นก่อนยกระดับนโยบาย ทางเลือกขึ้นอยู่กับบริการที่ใช้ เช่น เปลี่ยนวิธีส่งหรือเปลี่ยนโดเมน From ของบริการให้ตรงกับสิทธิ์ที่ควบคุมได้ การปล่อยให้บริการเดิมส่งด้วย From ของบริษัทต่อไปจะทำให้ DMARC fail ซ้ำแม้ระเบียน DNS ของระบบอื่นถูกต้องแล้ว

แม้ประกาศ p=reject ผู้รับยังมีดุลพินิจตามนโยบายภายในว่าจะจัดการข้อความอย่างไร และการผ่าน DMARC ก็ไม่รับประกันว่าเมลจะเข้ากล่องหลัก หากพบเมลธุรกิจจริงถูกกักหรือปฏิเสธหลังเปลี่ยนค่า ให้ตรวจส่วนหัวและเหตุผลการตีกลับ จับคู่กับแหล่งส่งในรายงาน แล้วแก้ SPF หรือ DKIM ให้สอดคล้องกับ From ระหว่างแก้ปัญหา สามารถลดระดับนโยบายกลับไปยังค่าที่ติดตามผลได้ เพื่อหยุดผลกระทบต่อเส้นทางที่ยังไม่พร้อม