คำตอบสั้น ๆ: ไล่ DMARC Policy จาก p=none ไป quarantine และ reject โดยอีเมลจริงไม่หาย: ทำรายการผู้ส่งจากรายงาน แก้ DKIM ตั้ง sp= ของซับโดเมน และถอยกลับได้เมื่อมีปัญหา
คู่มือนี้อธิบาย DMARC Policy ทีละขั้นตอน พร้อมคำสั่งที่ใช้ได้จริงและปัญหาที่พบบ่อย
DMARC Policy คือค่า p= ในระเบียน DMARC ที่บอกผู้รับปลายทางว่าจะทำอย่างไรกับอีเมลที่อ้างว่ามาจากโดเมนของคุณแต่ตรวจไม่ผ่าน มีสามระดับ คือ none (ดูรายงานอย่างเดียว), quarantine (ส่งเข้า Spam) และ reject (ปฏิเสธ) หลายบริษัทตั้ง p=none ไว้ตั้งแต่ Gmail และ Yahoo ออกข้อกำหนดผู้ส่งในปี 2024 แล้วไม่เคยขยับต่อ ทำให้ผู้โจมตียังปลอมโดเมนของบริษัทส่งหาลูกค้าได้
คู่มือนี้เหมาะกับผู้ดูแลระบบที่ตั้ง SPF, DKIM และ DMARC แล้ว และต้องการไล่ DMARC Policy ไปถึง p=reject โดยไม่ทำให้อีเมลจริงของบริษัทหาย เมื่อทำครบ คุณจะรู้ว่ามีระบบใดส่งอีเมลในชื่อโดเมนบ้าง แก้ให้ทุกระบบผ่าน DMARC กำหนดนโยบายของซับโดเมน ขยับเป็น quarantine และ reject ทีละขั้น และถอยกลับได้ทันทีถ้ามีปัญหา ถ้ายังไม่มีระเบียน DMARC ให้เริ่มที่ คู่มือตั้งค่า SPF, DKIM และ DMARC ก่อน
สิ่งที่ต้องเตรียม
- ระเบียน DMARC ที่มี
rua=และได้รับรายงาน Aggregate มาแล้วอย่างน้อย 4 สัปดาห์ ถ้าอ่านรายงานไม่คล่อง ดู คู่มืออ่านรายงาน DMARC - สิทธิ์แก้ DNS ของโดเมนหลักและซับโดเมน
- รายชื่อระบบที่ส่งอีเมลในชื่อโดเมน เท่าที่รู้ในตอนนี้ เช่น Microsoft 365 หรือ Google Workspace ระบบส่งจดหมายข่าว CRM ระบบบัญชีหรือ e-Tax Invoice ระบบเงินเดือน เว็บไซต์ และเครื่องพิมพ์
- เวลาสังเกตการณ์อย่างน้อยหนึ่งรอบเดือน เพราะบางระบบส่งอีเมลเดือนละครั้ง เช่น ใบแจ้งหนี้สิ้นเดือนหรือสลิปเงินเดือน
ขั้นตอนที่ 1: ตรวจ DMARC Policy ปัจจุบัน
dig +short TXT _dmarc.example.comผลควรมีระเบียนเดียวที่ขึ้นต้นด้วย v=DMARC1 และค่า p= คือ DMARC Policy ที่ใช้อยู่ ถ้ามีสองระเบียน ผู้รับจะถือว่าไม่มี DMARC เลย ถ้า rua= ชี้ไปที่อยู่ในโดเมนอื่น เช่น บริการวิเคราะห์รายงาน โดเมนปลายทางต้องมีระเบียนอนุญาต example.com._report._dmarc.<โดเมนปลายทาง> ไม่เช่นนั้นผู้รับจะไม่ส่งรายงานให้ ซึ่งบริการส่วนใหญ่ตั้งไว้ให้แล้ว แต่ควรตรวจด้วยคำสั่ง dig เหมือนกัน
ขั้นตอนที่ 2: ทำรายการผู้ส่งทุกรายจากรายงานก่อนแตะ DMARC Policy
เปิดรายงาน Aggregate ย้อนหลัง 4 สัปดาห์ แล้วจัดกลุ่ม IP ต้นทางทุกรายการเป็นสามกลุ่ม
- ระบบของบริษัทที่ผ่านแล้ว: ผล DMARC เป็น pass เพราะ SPF หรือ DKIM ผ่านและโดเมนตรงกับ From
- ระบบของบริษัทที่ยังไม่ผ่าน: เช่น ระบบจดหมายข่าวที่ลงนาม DKIM ด้วยโดเมนของผู้ให้บริการเอง หรือระบบบัญชีที่ส่งจาก IP ที่ไม่อยู่ใน SPF กลุ่มนี้คือสิ่งที่จะหายเมื่อขยับ DMARC Policy
- ไม่ใช่ของบริษัท: IP ที่ไม่รู้จักและส่งปริมาณน้อยกระจายหลายประเทศ มักเป็นผู้ปลอมแปลง ซึ่งเป็นกลุ่มที่ DMARC Policy แบบบังคับจะหยุดได้
ถามทุกฝ่ายว่าใช้บริการภายนอกใดส่งอีเมลบ้าง ระบบที่ส่งน้อยมักหลุดจากรายงานช่วงสั้น และมักเป็นระบบที่สำคัญ เช่น ระบบออกใบกำกับภาษีอิเล็กทรอนิกส์
ขั้นตอนที่ 3: แก้ทุกระบบให้ผ่าน DMARC ก่อนขยับ DMARC Policy
- เปิด DKIM ด้วยโดเมนของบริษัท (custom domain) ในทุกระบบที่รองรับ เพราะ DKIM ยังผ่านเมื่ออีเมลถูกส่งต่อ ส่วน SPF จะล้มเหลวเมื่อถูกส่งต่อเสมอ บน Microsoft 365 ดู คู่มือ DKIM บน Microsoft 365
- ระบบที่ตั้ง DKIM ไม่ได้ ให้เพิ่มใน SPF ระวังไม่ให้เกิน 10 lookup ตาม คู่มือแก้ SPF PermError
- ระบบที่ไม่รองรับทั้งสองอย่าง เช่น เครื่องพิมพ์รุ่นเก่า ให้ส่งผ่านเมลเซิร์ฟเวอร์ของบริษัทแทน เช่น Postfix ที่ตั้งเป็น SMTP relay ภายในบริษัท
- ระบบส่งอีเมลการตลาดจำนวนมาก ให้ย้ายไปใช้ซับโดเมน เช่น
news.example.comเพื่อแยกชื่อเสียงและแยก DMARC Policy ออกจากอีเมลงานปกติ
หลังแก้แต่ละระบบ ให้รอรายงานรอบถัดไปเพื่อยืนยันว่าเปลี่ยนเป็น pass จริง อย่าเชื่อหน้าตั้งค่าของผู้ให้บริการเพียงอย่างเดียว
ขั้นตอนที่ 4: กำหนด DMARC Policy ของซับโดเมนและโดเมนที่ไม่ใช้ส่งอีเมล
ถ้าไม่ระบุ sp= ซับโดเมนจะใช้ DMARC Policy เดียวกับโดเมนหลัก ผู้โจมตีนิยมปลอมซับโดเมนที่ไม่มีอยู่จริง เช่น billing.example.com เพราะดูน่าเชื่อ เมื่อโดเมนหลักไปถึง reject แล้วให้ตั้ง sp=reject ด้วย ส่วนซับโดเมนที่ส่งอีเมลจริงให้มีระเบียน _dmarc ของตัวเอง
โดเมนที่บริษัทจดไว้แต่ไม่ได้ส่งอีเมล เช่น โดเมนสำรองหรือโดเมนสะกดผิดที่จดกันไว้ ให้ปิดทุกทางด้วยระเบียนชุดนี้
example.net. 3600 IN MX 0 .
example.net. 3600 IN TXT "v=spf1 -all"
_dmarc.example.net. 3600 IN TXT "v=DMARC1; p=reject; sp=reject"MX ที่ชี้ไป . คือ Null MX ตาม RFC 7505 บอกว่าโดเมนนี้ไม่รับอีเมล
