DMARC p=none, quarantine หรือ reject: คู่มือสำหรับผู้ดูแลระบบ

ข้อแลกเปลี่ยนหลัก

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

ทำไมนโยบายจึงส่งผลต่อคิวเหตุการณ์

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

DMARC (Domain-based Message Authentication, Reporting, and Conformance) อาศัย alignment ของ SPF และ DKIM หากข้อความไม่ผ่านทั้งสองอย่าง แท็ก p= จะบอกเซิร์ฟเวอร์ผู้รับอย่างชัดเจนว่าต้องจัดการกับข้อความนั้นอย่างไร

นโยบายสามระดับ

1. p=none (โหมดเฝ้าติดตาม)

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

ควรใช้เมื่อ:

• ตั้งค่า DMARC ครั้งแรก
• เมื่อคุณไม่แน่ใจว่ามีบริการใดบ้างที่ส่งอีเมลในนามของคุณ
• ระหว่างการย้ายไปใช้ email API ตัวใหม่

Payload:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com;

ข้อแลกเปลี่ยน: คุณไม่มีการป้องกันการปลอมแปลงเลย ผู้โจมตียังส่งอีเมลในนามโดเมนของคุณได้ แต่คุณจะเห็นในรายงาน RUA (Aggregate)

2. p=quarantine (การบังคับใช้แบบอ่อน)

ข้อความที่ไม่ผ่าน DMARC จะถูกมองว่าน่าสงสัย ผู้รับส่วนใหญ่จะย้ายข้อความเหล่านี้ไปยังโฟลเดอร์สแปมหรือโฟลเดอร์ขยะ

ควรใช้เมื่อ:

• หลังจากคุณวิเคราะห์รายงานของ p=none และยืนยันแล้วว่าทุกช่องทางส่งที่ถูกต้องผ่าน alignment
• เป็นตัวกันชนเพื่อความปลอดภัยก่อนขยับไปปฏิเสธเต็มรูปแบบ

Payload:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com;

ข้อแลกเปลี่ยน: ช่วยลดการมองเห็นของอีเมลปลอมแต่ไม่ได้กำจัดให้หมด อีเมลที่ถูกต้องบางฉบับอาจยังตกไปอยู่ในสแปมหากมีการหมุนเวียนคีย์ DKIM ผิดพลาดหรือเรคคอร์ด SPF เกินขีดจำกัด 10 DNS lookup

3. p=reject (การบังคับใช้เต็มรูปแบบ)

นี่คือมาตรฐานสูงสุดของความปลอดภัยโดเมน เซิร์ฟเวอร์ผู้รับจะปฏิเสธที่จะรับข้อความทันทีหากไม่ผ่าน DMARC

ควรใช้เมื่อ:

• เมื่อการเฝ้าติดตามแสดงว่าทราฟฟิกที่ถูกต้องทั้งหมดผ่าน alignment 99.9%
• เมื่อความเสี่ยงจากการปลอมแปลงโดเมนมากกว่าความเสี่ยงที่การส่งจะล้มเหลวเป็นครั้งคราว

Payload:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com;

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

เช็กลิสต์การเปิดใช้สำหรับผู้ดูแลระบบ

อย่าเปลี่ยนนโยบายตามความรู้สึก ให้เปลี่ยนตามข้อมูลในรายงาน aggregate ของคุณ ใช้เครื่องมืออย่าง SendHQ Email DNS Checker เพื่อตรวจสอบว่าเรคคอร์ดของคุณเผยแพร่ถูกต้องก่อนเปลี่ยนแต่ละครั้ง

ระยะที่ 1: การค้นหา (p=none)

1. เผยแพร่ p=none พร้อมที่อยู่ rua
2. รอ 7 ถึง 14 วันเพื่อเก็บอีเมลให้ครบรอบธุรกิจหนึ่งรอบ (รวมรายงานรายสัปดาห์)
3. วิเคราะห์รายงานเพื่อหาทราฟฟิกที่ "ไม่ผ่าน alignment"
4. ระบุผู้ส่งบุคคลที่สามที่ถูกต้อง (เช่น Zendesk, Salesforce, Shopify)
5. ตั้งค่า DKIM สำหรับผู้ส่งทุกรายที่ระบุได้ นี่เป็นวิธีที่เชื่อถือได้ที่สุดในการทำให้ผ่าน alignment

ระยะที่ 2: การทดสอบ (p=quarantine)

1. เปลี่ยนนโยบายเป็น p=quarantine
2. เฝ้าดูตั๋วซัพพอร์ตว่ามีข้อความอย่าง "ฉันไม่ได้รับอีเมล" หรือ "อีเมลอยู่ในสแปม" หรือไม่
3. ตรวจสอบรายงาน RUA ว่ามีความล้มเหลวพุ่งขึ้นใหม่หรือไม่
4. หากเกิดความล้มเหลว ให้แก้การยืนยันตัวตนและคงไว้ที่ quarantine อีกหนึ่งสัปดาห์

ระยะที่ 3: การเสริมความแข็งแกร่ง (p=reject)

1. เปลี่ยนนโยบายเป็น p=reject
2. ตรวจสอบว่าโฟลว์ transactional ที่สำคัญที่สุด (การรีเซ็ตรหัสผ่าน ใบแจ้งหนี้) ยังส่งถึงตามปกติ
3. เฝ้าติดตามต่อไป DMARC ไม่ใช่การตั้งค่าแล้วปล่อยทิ้ง

การจัดการอีเมลในฐานะผลข้างเคียง

สำหรับวิศวกรผลิตภัณฑ์ที่สร้างเอเจนต์ AI หรือเวิร์กโฟลว์อัตโนมัติ การส่งอีเมลคือผลข้างเคียงภายนอก ซึ่งหมายความว่าอาจล้มเหลวด้วยเหตุผลนอกตรรกะของแอปพลิเคชัน (ปัญหา DNS การปฏิเสธจาก DMARC หรือ rate limit)

Idempotency และการอนุมัติ

เมื่อเอเจนต์ AI สั่งส่งอีเมล คุณต้องป้องกันการส่งซ้ำระหว่างการลองใหม่ ใช้ idempotency key ในคำขอ API เพื่อให้แน่ใจว่าเครือข่ายหมดเวลาจะไม่ทำให้ลูกค้าได้รับอีเมลฉบับเดียวกันห้าครั้ง

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

ต้นทุนของโครงสร้างพื้นฐานการส่ง

การเลือกผู้ให้บริการส่งมีผลต่อวิธีจัดการ DMARC ผู้ให้บริการบางรายทำให้การตั้งค่า DKIM ง่ายมาก ขณะที่บางรายต้องกรอกเรคคอร์ด DNS ด้วยตนเองสำหรับทุกโดเมนย่อย

เมื่อประเมินต้นทุน ให้ดูต้นทุนรวมในการเป็นเจ้าของ ตัวอย่างเช่น การส่งอีเมล 50,000 ฉบับมีค่าใช้จ่ายประมาณ 5 USD บน Amazon SES แบบ a la carte (ที่ 0.10 USD ต่อ 1,000 อีเมล) ขณะที่แพ็กเกจของ Postmark จะมีค่าใช้จ่ายราว 66 USD สำหรับปริมาณเท่ากัน (15 USD สำหรับ 10,000 ฉบับ บวกส่วนที่เกินระหว่าง 1.20 ถึง 1.80 USD ต่อ 1,000 ฉบับ)

ตัวเลือกอื่นได้แก่ Resend ซึ่งมีแพ็กเกจฟรี 3,000 อีเมลต่อเดือน (จำกัด 100 ต่อวัน) หรือ Mailgun ที่เริ่มต้น 15 USD ต่อเดือนสำหรับ 10,000 อีเมล ปัจจุบัน SendGrid ใช้ช่วงทดลอง 60 วันสำหรับแพ็กเกจฟรี โดยแพ็กเกจ Essentials เริ่มต้น 19.95 USD ต่อเดือน

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

รูปแบบความล้มเหลวที่พบบ่อย

กับดักการส่งต่อ

ผู้ใช้ A ส่งอีเมลถึงผู้ใช้ B ผู้ใช้ B ตั้งส่งต่ออัตโนมัติไปยังผู้ใช้ C เซิร์ฟเวอร์ที่ส่งต่อมักเปลี่ยน envelope sender เป็นโดเมนของตนเองเพื่อหลีกเลี่ยงการถูกทำเครื่องหมายเป็นสแปม ซึ่งทำให้ SPF alignment ใช้ไม่ได้ หากคุณตั้ง p=reject และไม่มีลายเซ็น DKIM ผู้ใช้ C จะไม่เห็นอีเมลนั้นเลย

ขีดจำกัด DNS lookup

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

ปัญหา "Shadow IT"

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

ตารางสรุปสำหรับผู้ดูแลระบบ

นโยบาย | การดำเนินการ | ความเสี่ยง | การมองเห็น | การใช้งานที่แนะนำ

p=none | ไม่มี | ต่ำ | สูง | การค้นหาและการตรวจสอบ

p=quarantine | โฟลเดอร์สแปม | ปานกลาง | สูง | การทดสอบและการเปลี่ยนผ่าน

p=reject | ถูกบล็อก | สูง | ปานกลาง | ความปลอดภัยเต็มรูปแบบในระบบจริง

หากต้องการเจาะลึกการนำเรคคอร์ดเหล่านี้ไปใช้ในเชิงเทคนิค ดูคู่มือเรื่อง DKIM, SPF และ DMARCของเรา

การจัดการเรคคอร์ดเหล่านี้ด้วยตนเองเป็นเรื่องน่าเบื่อ SendHQ ช่วยให้ง่ายขึ้นด้วยการส่งอีเมล transactional จากโดเมนที่ยืนยันแล้ว และเครื่องมือที่ช่วยให้โครงสร้างพื้นฐานของคุณพร้อมสำหรับเอเจนต์

ดูข้อมูลเพิ่มเติมได้ที่ https://sendhq.cc