ทำไม DMARC record อย่างเดียวไม่พอ ต้องเลือก Policy ให้ถูกด้วย

หลายบริษัทตั้ง DMARC record ไว้แล้วแต่ policy ยังเป็น none ทำให้ยังป้องกันการปลอมแปลงโดเมนไม่ได้จริง บทความนี้อธิบายความต่างระหว่าง quarantine กับ reject พร้อมขั้นตอนขยับอย่างปลอดภัย เพื่อให้โดเมนพร้อมสำหรับแคมเปญ cold email B2B แบบเจาะจงโดยไม่กระทบอีเมลสำคัญที่ส่งจริง

DMARC คืออะไร และทำไมมี record แล้วยังไม่ได้ป้องกันจริง

หลายทีมการตลาดตั้งค่า DMARC record ใน DNS เรียบร้อยแล้ว มี SPF และ DKIM ผ่านทุกฉบับ แต่ยังพบว่ามีคนแอบใช้ชื่อโดเมนของบริษัทส่งอีเมลหลอกลวงไปหาลูกค้าหรือคู่ค้าอยู่ดี สาเหตุที่พบบ่อยที่สุดคือ policy ใน record ยังตั้งเป็น p=none ซึ่งเป็นโหมดเฝ้าดูอย่างเดียว ไม่มีการบล็อกหรือกักอีเมลปลอมแปลงแต่อย่างใด พูดง่าย ๆ คือมี DMARC record แต่ policy ยังไม่ enabled ในเชิงบังคับใช้จริง

DMARC (Domain-based Message Authentication, Reporting and Conformance) คือ record ที่วางไว้ใน DNS ในรูป TXT ที่ _dmarc.ชื่อโดเมน ทำหน้าที่บอกผู้ให้บริการอีเมลปลายทาง เช่น Gmail หรือ Outlook ว่าเมื่อพบอีเมลที่อ้างว่ามาจากโดเมนนี้แต่ SPF หรือ DKIM ไม่ผ่านการตรวจสอบแบบ alignment ให้จัดการอย่างไร ตัวเลือก policy มีสามระดับคือ none, quarantine และ reject ซึ่งเป็นหัวใจของบทความนี้

สำหรับธุรกิจที่ทำ cold email แบบ B2B เจาะจงรายบริษัท ความน่าเชื่อถือของโดเมนคือทรัพย์สินที่ต้องรักษา เพราะกล่องขาเข้าของผู้รับอย่าง Gmail และ Microsoft 365 ใช้สัญญาณ DMARC ประกอบการตัดสินใจว่าจะส่งเข้ากล่องหลักหรือโฟลเดอร์สแปม การปล่อยให้ policy ค้างที่ none นานเกินไปจึงเป็นความเสี่ยงทั้งด้าน security และ deliverability พร้อมกัน

p=none, quarantine, reject ต่างกันอย่างไร

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

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

• p=none — เฝ้าดูอย่างเดียว ไม่บล็อก ไม่กัก ส่งรายงาน rua ให้เจ้าของโดเมนเท่านั้น เหมาะสำหรับช่วงเริ่มต้นเก็บข้อมูล
• p=quarantine — อีเมลที่ authentication ไม่ผ่านจะถูกส่งเข้าโฟลเดอร์สแปมหรือ junk ของผู้รับ ยังส่งถึงแต่ผู้รับต้องเปิดไปดูเอง
• p=reject — อีเมลที่ authentication ไม่ผ่านจะถูกปฏิเสธตั้งแต่ชั้น SMTP ผู้รับจะไม่เห็นอีเมลนั้นเลย เป็นการป้องกันสูงสุด
• pct= — ตัวแปรเสริมกำหนดสัดส่วนเปอร์เซ็นต์ของอีเมลที่จะให้ policy มีผล ใช้ทยอยขยับจาก 25 ไป 100 แทนการเปิดเต็มทันที

ขั้นตอนเปลี่ยนจาก none ไป quarantine ไป reject อย่างปลอดภัย

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

สำหรับโดเมนที่ใช้ทำ cold email แบบเจาะจงรายบริษัท แนะนำให้แยก subdomain สำหรับส่ง เช่น outreach.บริษัท.co.th หรือ go.บริษัท.com เพื่อไม่ให้การทดลอง policy ระหว่างทางไปกระทบชื่อเสียงของโดเมนหลักที่ใช้รับอีเมลลูกค้าและออกเอกสารสำคัญ

• ขั้นที่ 1 — ตรวจสอบให้ SPF ครอบคลุมทุกแหล่งที่ส่งอีเมลในนามโดเมน ทั้ง Google Workspace ระบบ cold email CRM และระบบออกใบกำกับภาษี พร้อมตั้ง DKIM selector ให้ครบทุกระบบ
• ขั้นที่ 2 — ตั้ง p=none พร้อม rua ให้ส่งรายงานสรุปรายวันไปยังเครื่องมือ monitor แล้วเฝ้าดูอย่างน้อย 2–4 สัปดาห์ ว่ามีแหล่งส่งใดที่ authentication ไม่ผ่านทั้งที่เป็นอีเมลจริงของบริษัทเองหรือไม่
• ขั้นที่ 3 — เมื่อรายงานสะอาด ให้ขยับเป็น p=quarantine; pct=25 แล้วค่อยเพิ่มเป็น 50, 100 ทีละสัปดาห์ พร้อมเฝ้าดู rua ต่อเนื่อง
• ขั้นที่ 4 — เมื่อ quarantine ที่ pct=100 นิ่งแล้วไม่มีอีเมลจริงหลุด (false positive) ต่อเนื่องหลายสัปดาห์ จึงขยับเป็น p=reject โดยเริ่มจาก pct น้อยก่อนเช่นกัน

benchmark ระยะเวลาและตัวเลขที่ควรเห็นก่อนขยับ policy

ไม่มีตัวเลขตายตัวว่าต้องรอกี่วันก่อนขยับ policy เพราะขึ้นกับจำนวนแหล่งส่งอีเมลของแต่ละบริษัท แต่จากการดูแลโดเมนที่ทำ cold email B2B พบช่วงเวลาที่ใช้ได้จริงดังนี้

แนวโน้มที่ควรเห็นคืออัตรา fail ของอีเมลจริง ไม่ใช่อีเมลปลอม ลดลงเรื่อย ๆ จนเข้าใกล้ศูนย์ก่อนจะขยับไปขั้นถัดไป หากตัวเลขไม่ลดลงตามที่คาด แปลว่ายังมีแหล่งส่งที่ไม่ได้ตั้งค่า SPF หรือ DKIM ให้ครบ ต้องแก้ตรงนั้นก่อน ไม่ใช่ฝืนขยับ policy ต่อ

ข้อผิดพลาดที่พบบ่อยเมื่อรีบตั้ง reject เร็วเกินไป

ข้อผิดพลาดที่พบบ่อยเมื่อบริษัทรีบตั้ง p=reject โดยยังไม่ผ่านขั้น monitor และ quarantine อย่างเพียงพอ มักมาจากความเข้าใจผิดว่ามี DMARC record แล้วคือจบ

• ลืมใส่ SPF include ของเครื่องมือส่งอีเมลบางตัว เช่น ระบบ ticket support หรือ marketing automation ทำให้อีเมลจากระบบเหล่านั้นถูก reject หายไปโดยไม่มีใครแจ้ง
• ไม่แยก subdomain สำหรับ cold email ทำให้การทดลอง policy กระทบโดเมนหลักที่ใช้รับใบเสนอราคาและอีเมลตอบกลับจากลูกค้า
• ตั้ง pct=100 ทันทีตั้งแต่ขั้น quarantine โดยไม่ทยอยเพิ่ม ทำให้แก้ปัญหาย้อนหลังยาก เพราะกระทบอีเมลจำนวนมากพร้อมกัน
• ไม่มีใครอ่านรายงาน rua เป็นประจำ ปล่อยให้ policy อยู่ที่ reject เฉย ๆ โดยไม่รู้ว่ามีอีเมลจริงหลุดหายไปกี่ฉบับต่อเดือน
• เข้าใจผิดว่าตั้ง DMARC record แล้วจบ ทั้งที่ policy ยังเป็น none ตลอดกาล ซึ่งเท่ากับยังไม่ได้ป้องกันอะไรเลย

LDM ตั้งค่า DMARC อย่างไรก่อนเปิดแคมเปญ B2B เจาะจง

แนวทางที่ LDM ใช้ก่อนเปิดแคมเปญ cold email แบบเจาะจงให้ลูกค้า คือดูแลทั้งฝั่งเทคนิคของโดเมนและฝั่งข้อมูลผู้ติดต่อไปพร้อมกัน เพราะทั้งสองส่วนส่งผลต่อความน่าเชื่อถือของแคมเปญ

การดูแล DMARC ให้ policy เข้มขึ้นตามลำดับ ควบคู่กับการเคารพสิทธิ์ของผู้ติดต่อในฐานข้อมูลอย่างถูกต้องตาม PDPA ทำให้แคมเปญ B2B ที่เจาะจงรายบริษัทมีอัตราการเข้ากล่องหลักสูงขึ้นและความเสี่ยงถูกร้องเรียนหรือถูกปลอมแปลงโดเมนลดลงไปพร้อมกัน

• ตั้ง subdomain แยกสำหรับ cold email และวอร์มอัพก่อนส่งจริงอย่างน้อยหลายสัปดาห์
• เริ่ม DMARC ที่ p=none พร้อมเก็บ rua report อย่างน้อย 2–4 สัปดาห์ก่อนขยับ
• ทยอยขึ้น quarantine แล้วค่อย reject ตามอัตรา fail ของอีเมลจริงที่ลดลงจนนิ่ง
• ใช้ข้อมูลผู้ติดต่อทางธุรกิจ เช่น ชื่อ ตำแหน่ง อีเมลที่ระบุบนเว็บไซต์บริษัทหรือ LinkedIn ตามหลัก legitimate interest ภายใต้พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (PDPA) พร้อมช่องทาง opt-out ที่ชัดเจนในทุกฉบับ
• ตรวจ complaint rate และ unsubscribe อย่างสม่ำเสมอ เพราะการร้องเรียนของผู้รับกระทบชื่อเสียงโดเมนไม่ต่างจาก DMARC fail

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