ทีมผลิตภัณฑ์ควรใช้ DMARC ใน Cloudflare อย่างปลอดภัยได้อย่างไร

แยก DNS ของ Cloudflare ออกจากการตั้งค่าผู้ส่ง

Cloudflare สามารถทำหน้าที่ DNS แบบ authoritative ได้ ในขณะที่ผู้ให้บริการรายอื่นส่งและลงลายเซ็นอีเมลของแอปพลิเคชัน ให้บันทึกขอบเขตเหล่านี้ก่อนแก้ไขอะไร โซนเผยแพร่นโยบาย TXT ของ DMARC ผู้ให้บริการอีเมลแต่ละรายควบคุม return path โดเมนและ selector ที่ใช้ลงลายเซ็น DKIM การยืนยัน และบางครั้งการรายงาน ส่วนแอปพลิเคชันควบคุม tenant ประเภทข้อความ ผู้รับ เทมเพลต ที่อยู่ From ที่มองเห็น และเส้นทางผู้ให้บริการ เรคคอร์ด DNS ที่ถูกต้องไม่สามารถแก้ไขผู้ส่งที่ไม่ได้รับอนุญาต ลายเซ็น DKIM ที่หายไป return path ที่ไม่ align หรือค่า From ข้าม tenant ได้ ให้ตรวจสอบรายการระบบ production, staging, ซัพพอร์ต, การเรียกเก็บเงิน, ตัวตน, การติดตาม, CRM, การตลาด และอีเมลที่คนส่งเอง ตามโดเมน From ที่มองเห็น มอบหมายเจ้าของและผู้ติดต่อสำหรับย้อนกลับให้แต่ละรายการ และจำแนกแหล่งรายงานที่ไม่รู้จักก่อนเพิ่มความเข้มงวด

ค้นหาชื่อนโยบายที่ผู้รับประเมิน

สำหรับอีเมลจาก alerts@notify.example.test ให้เริ่มที่ TXT ของ _dmarc.notify.example.test อย่าเผยแพร่นโยบายที่โฮสต์ของเว็บไซต์ mail exchanger DKIM selector หรือชื่อ return-path โดยผิดพลาด การค้นหา DMARC ปัจจุบันสามารถเลือกนโยบายของโดเมนองค์กรหรือ public suffix ที่เกี่ยวข้อง เมื่อโดเมนผู้เขียนไม่มีเรคคอร์ดที่ถูกต้อง ดังนั้นให้บันทึกทั้งชื่อที่ค้นหาและโดเมนนโยบายที่ถูกเลือก ค้นหาคำตอบ authoritative และ recursive ที่มีอยู่ก่อนเปิด Cloudflare เรคคอร์ดนโยบายหลายรายการที่ชื่อเดียวกัน ไวยากรณ์แท็กที่ผิดรูป หรือ CNAME ที่ขัดแย้งกัน อาจทำให้ผลลัพธ์ใช้ไม่ได้ ให้บันทึกเนื้อหาเดิม TTL ผลลัพธ์จาก resolver เจ้าของ และค่าที่คาดหวังหลังเปลี่ยน เพื่อให้ย้อนกลับได้แม่นยำ ไม่ต้องสร้างใหม่ระหว่างเกิดเหตุ

สร้างเรคคอร์ด TXT ที่ผ่านการตรวจสอบหนึ่งรายการใน Cloudflare

เปิดบัญชีและโซน Cloudflare ที่ถูกต้อง ไปที่ DNS Records เลือก Add record และเลือก TXT ใช้ _dmarc เป็นชื่อสัมพัทธ์สำหรับนโยบายของ apex หรือใช้ label _dmarc ที่ถูกต้องสำหรับซับโดเมนที่ต้องการ ใส่ค่าที่ผ่านการตรวจสอบแล้วหนึ่งค่าโดยไม่ใช้อักขระเครื่องหมายคำพูดที่ไม่สม่ำเสมอ Cloudflare ระบุว่าจะเพิ่มเครื่องหมายคำพูดครอบให้เนื้อหา TXT ใหม่ที่บันทึกโดยไม่มีเครื่องหมายนั้น เลือก TTL ที่สอดคล้องกับการทยอยเปิดใช้และการกู้คืน เพิ่มการอ้างอิงการเปลี่ยนแปลงที่ปลอดภัยต่อความเป็นส่วนตัวหากเหมาะสม และบันทึกหลังตรวจสอบโซน ชื่อ ค่าเดิม และค่าใหม่แล้วเท่านั้น นโยบาย TXT เป็นข้อมูล DNS ไม่ใช่เส้นทางเว็บที่ผ่านพร็อกซี หากพาร์ทเนอร์โฮสติ้งหรือผู้ให้บริการ authoritative รายอื่นจัดการโซน ให้ทำการเปลี่ยนแปลงที่นั่น แทนที่จะสันนิษฐานว่าแดชบอร์ด Cloudflare เป็น authoritative

สร้างค่า DMARC จากการตัดสินใจที่ชัดเจน

เรคคอร์ดในขั้นสังเกตการณ์เริ่มต้นได้ด้วย v=DMARC1; p=none และ URI สำหรับรายงานแบบรวมที่ได้รับอนุมัติ แต่นั่นเป็นเพียงตัวอย่าง ไม่ใช่ค่าสากล ให้คงเวอร์ชันไว้เป็นอันดับแรก กำหนดนโยบายที่ขออย่างตั้งใจ และอนุญาตปลายทางรายงานทุกแห่ง ทบทวนนโยบายซับโดเมน โหมด alignment เปอร์เซ็นต์ และแท็กการรายงาน เฉพาะเมื่อมีข้อกำหนดที่บันทึกไว้และการตีความมาตรฐานปัจจุบัน อย่าคัดลอกตัวอย่างของผู้ให้บริการที่มีกล่องจดหมาย rua ของคนอื่น หรือกระโดดไปที่ p=reject เพียงเพราะไวยากรณ์ผ่านการตรวจสอบ เรคคอร์ดที่ถูกต้องแสดงการจัดการของผู้รับที่ร้องขอ ไม่ได้พิสูจน์ว่า SPF หรือ DKIM ยืนยันตัวตนได้ ตัวระบุที่ยืนยันแล้วตัวใดตัวหนึ่ง align กับโดเมน From เส้นทางการส่งที่ถูกต้องทั้งหมดถูกตรวจสอบรายการแล้ว หรือมีข้อความใดถึงกล่องจดหมาย

ยืนยัน alignment ของ SPF และ DKIM บนข้อความจริง

ส่งตัวอย่างแบบควบคุมจากทุกเส้นทางของแอปพลิเคชันไปยังผู้รับที่คุณตรวจสอบเฮดเดอร์ดิบได้ บันทึก From ที่มองเห็น SMTP MAIL FROM, IP ผู้ส่ง, โดเมนและ selector ของ DKIM d=, Authentication-Results, ตัวระบุของผู้ให้บริการ, ประเภทข้อความ, สภาพแวดล้อม และเวลา DMARC ผ่านได้ด้วย SPF ที่ยืนยันตัวตนและ align หรือลายเซ็น DKIM ที่ยืนยันและ align SPF ประเมินตัวตน SMTP และเปลี่ยนแปลงได้เมื่อมีการส่งต่อ DKIM ตรวจสอบลายเซ็นบนเนื้อหาที่เลือก ทั้งสองอย่างไม่ได้ทดแทนการอนุญาตในระดับแอปพลิเคชัน ทดสอบ alignment แบบ relaxed หรือ strict อย่างตั้งใจ รวมถึงซับโดเมนและเส้นทาง failover การที่ API ของผู้ให้บริการยอมรับ การที่เซิร์ฟเวอร์ปลายทางยอมรับ DMARC pass การเข้ากล่องจดหมาย และการมีส่วนร่วม เป็นการสังเกตที่ต่างกัน ให้แยกสถานะเหล่านี้ออกจากกัน เพื่อไม่ให้การเรียก API สำเร็จหรือตัวชี้วัดนโยบายสีเขียวถูกยกระดับเป็นหลักฐานการส่งถึงที่หนักแน่นกว่า

ตรวจสอบ DNS และรายงานนอกแดชบอร์ด

หลังบันทึก ให้ค้นหา TXT ที่ชื่อ _dmarc ที่ถูกต้องจาก name server แบบ authoritative ของ Cloudflare และ recursive resolver อิสระหลายตัว เก็บคำตอบดิบ โดเมนนโยบายที่เลือก TTL resolver เวลา และผลลัพธ์ของ parser ยืนยันว่ามีเรคคอร์ดที่ใช้งานได้เพียงหนึ่งรายการ v=DMARC1 อยู่ก่อน ค่าที่จำเป็นถูกต้อง และ URI การรายงานได้รับอนุมัติ ทำซ้ำหลังช่วงแคชที่คาดไว้ ส่งข้อความทดสอบแบบควบคุมอีกครั้งและตรวจสอบเฮดเดอร์ฝั่งผู้รับ Cloudflare ระบุว่า DMARC Management เป็นวิธีดูแหล่งที่ส่งและผลรวมของ SPF, DKIM และ DMARC แต่รายงานเป็นข้อมูลที่ผู้รับส่งมาอย่างล่าช้า ไม่ใช่การสำรวจสดครบถ้วน ให้เชื่อมโยงกับหลักฐานของผู้ให้บริการ ให้หยุดเมื่อ resolver ให้ผลไม่ตรงกัน ไม่พบทราฟฟิกความถี่ต่ำ พบแหล่งที่ถูกต้องซึ่งไม่รู้จัก ข้อความทดสอบแบบควบคุมไม่ align หรือปริมาณรายงานเปลี่ยนโดยไม่คาดคิด

ถือว่า Cloudflare DMARC Management เป็นการเปลี่ยนแปลง DNS

Cloudflare ระบุว่าการเปิดใช้ DMARC Management อาจเชิญให้สร้างเรคคอร์ดเมื่อยังไม่มี หรือเพิ่มที่อยู่รายงานแบบรวมของ Cloudflare ลงในแท็ก rua ที่มีอยู่ ให้ตรวจสอบการเปลี่ยนแปลงที่เสนอนี้เหมือนโครงสร้างพื้นฐานของระบบจริง คือส่งออกค่าเดิม ยืนยันว่าปลายทางที่มีอยู่ยังตั้งใจไว้ ตรวจสอบขอบเขตโดเมน และเก็บแผนย้อนกลับ เอกสารการเปิดใช้งานยังอธิบายขอบเขตโดเมน apex ปัจจุบันและข้อควรระวังเรื่องเรคคอร์ด SPF ภายนอก อย่าสรุปว่าฟีเจอร์นี้เขียนทับเส้นทาง SPF ที่โฮสต์ที่อื่นได้อย่างปลอดภัย แหล่งหรือ IP ที่แสดงไม่ได้พิสูจน์ว่าแอปพลิเคชัน tenant หรือบุคคลใดเป็นผู้อนุญาต และการไม่มีแถวไม่ได้พิสูจน์ว่าไม่มีทราฟฟิก ใช้มุมมองนี้เพื่อรวบรวมหลักฐาน ควบคู่กับหลักฐานจาก DNS แบบ authoritative ข้อความดิบ ล็อกของผู้ให้บริการ และการตรวจสอบของแอปพลิเคชัน

เพิ่มการบังคับใช้ผ่านหลักฐานเป็นขั้น ๆ

สังเกตนานพอที่จะครอบคลุมผู้ส่งที่ถูกต้อง ประเภทข้อความ รูปแบบวันในสัปดาห์ งาน batch เส้นทาง failover และเวิร์กโฟลว์ความถี่ต่ำทั้งหมด จำแนกแหล่งเป็นของเรา ผู้ให้บริการที่อนุมัติ การส่งต่อ ไม่รู้จัก หรือละเมิด แก้ alignment ของทราฟฟิกที่ถูกต้องก่อนขอการจัดการที่เข้มงวดขึ้น เกณฑ์ go/no-go ควรรวม DNS ที่ถูกต้อง ข้อความทดสอบแบบควบคุมที่ผ่าน ความครอบคลุมที่ align ในระดับที่ยอมรับได้ ไม่มีแหล่งที่ถูกต้องซึ่งไม่รู้จัก เจ้าของเมื่อเกิดเหตุ ความพร้อมของซัพพอร์ต และการย้อนกลับที่ทดสอบแล้ว เพิ่มนโยบายผ่านการเปลี่ยนแปลงที่มีขอบเขตและได้รับอนุมัติเท่านั้น และติดตามทั้งความล้มเหลวด้านการยืนยันตัวตนและด้านธุรกิจ ให้ย้อนกลับหรือหยุดเมื่อมีการปฏิเสธข้อความที่ถูกต้อง รายงานหาย แหล่งที่ไม่คาดคิด resolver ไม่สอดคล้อง การย้ายผู้ให้บริการ หรือเหตุไม่คาดฝันจากการสืบทอดนโยบายซับโดเมน ให้เปลี่ยน SPF, DKIM และ DMARC แยกกันเมื่อเป็นไปได้ เพื่อให้ระบุสาเหตุของการถดถอยได้ชัดเจน

หลีกเลี่ยงรูปแบบความล้มเหลวที่พบบ่อยของ DMARC บน Cloudflare

ความล้มเหลวที่พบบ่อย ได้แก่ แก้ไขโซนผิด เผยแพร่ที่ชื่อ _dmarc ผิด ทิ้งเรคคอร์ดนโยบายไว้สองรายการ เพิ่มเครื่องหมายคำพูดที่ใช้ไม่ได้ แทนที่รายการ rua ที่ได้รับอนุมัติ สันนิษฐานว่านโยบายของ apex และซับโดเมนเหมือนกัน และใช้ p=reject ก่อนที่ผู้ส่งความถี่ต่ำจะปรากฏ อีกข้อผิดพลาดคือการถือว่าสถานะที่บันทึกหรือตรวจพบในแดชบอร์ดเป็นหลักฐานระดับข้อความ ให้ใช้ diff ที่แม่นยำ ผู้รับแบบควบคุม การค้นหาอิสระ เฮดเดอร์ดิบ และล็อกเหตุการณ์ระดับผู้รับ อย่าเก็บที่อยู่ลูกค้า เนื้อหาข้อความ API key และข้อมูลรายงานที่ไม่มีขอบเขตไว้ในตั๋วและระบบวิเคราะห์ หากคำตอบ authoritative และแคชยังไม่สอดคล้องเกินแผน ผู้ส่งที่คาดไว้หายไป หรือข้อความจริงไม่ผ่าน alignment ให้หยุดและวินิจฉัย delegation แคช ไวยากรณ์เรคคอร์ด รายการผู้ส่ง SPF และ DKIM แยกกัน

SendHQ เหมาะกับการใช้งานอย่างไร

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

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

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

• การจัดการเรคคอร์ด DNS — Cloudflare
• ประเภทเรคคอร์ด DNS ของ Cloudflare — Cloudflare
• ภาพรวม Cloudflare DMARC Management — Cloudflare
• การเปิดใช้ Cloudflare DMARC Management — Cloudflare
• การดูสถิติ DMARC ของ Cloudflare — Cloudflare
• ข้อกำหนด RFC 9989: DMARC — RFC Editor
• ข้อกำหนด RFC 7208: SPF — RFC Editor
• ข้อกำหนด RFC 6376: DKIM — RFC Editor