วิธีอ่าน DMARC Policy ของบริษัท ในสิบวินาที (และสิ่งที่มันไม่บอกคุณ)

การค้นหา DNS เพียงครั้งเดียวจะบอกคุณว่าบริษัทได้ขอให้เซิร์ฟเวอร์จดหมายทั่วโลกทำอะไรกับจดหมายปลอมที่ส่งมาในนามของมัน บันทึกนี้เป็นสาธารณะ และคำสั่งเป็นบรรทัดเดียว: dig +short TXT _dmarc.example.com สิ่งที่กลับมาคือสตริงการตั้งค่าสั้น ๆ และภายในนั้นมีคำแนะนำเดียว — p=none, p=quarantine หรือ p=reject — ที่ระบุความชอบของเจ้าของโดเมนเมื่อข้อความที่ใช้โดเมนนั้นล้มเหลวในการพิสูจน์ตัวตน

ข้อกำหนด RFC 9989 ปัจจุบัน ซึ่งเผยแพร่ในเดือนพฤษภาคม 2026 ในฐานะเอกสาร IETF Standards Track ได้แทนที่ RFC 7489 ที่เก่ากว่า มันกำหนดค่าทั้งสามนี้เกือบจะกระชับ:

• p=none — "เจ้าของโดเมนไม่แสดงความชอบใด ๆ"
• p=quarantine — "เจ้าของโดเมนพิจารณาว่าจดหมายดังกล่าวน่าสงสัย อาจเป็นไปได้ว่าจดหมายนั้นถูกต้อง แม้ว่าความล้มเหลวในการพิสูจน์ตัวตนนั้นสร้างความกังวลอย่างมาก"
• p=reject — "เจ้าของโดเมนพิจารณาว่าความล้มเหลวทั้งหมดดังกล่าวเป็นข้อบ่งชี้ที่ชัดเจนว่าการใช้ชื่อโดเมนนั้นไม่ถูกต้อง"

อ่านคำพูดเหล่านั้นอีกครั้ง เพราะว่ามันอ่อนแอกว่าคำอธิบายส่วนใหญ่เกี่ยวกับ DMARC ที่ยอมรับ policy คือ ความชอบ ที่เผยแพร่โดยผู้ส่งเพื่อให้ผู้รับพิจารณา มันไม่ใช่คำแนะนำที่ผู้รับมีหน้าที่ต้องปฏิบัติตาม RFC 9989 ระบุเช่นนี้ในประโยคเดียว: "การจัดการข้อความขั้นสุดท้ายเป็นเรื่องของนโยบายท้องถิ่นเสมอและปล่อยให้การพิจารณาของผู้รับข้อความ" ส่วนเดียวกันยังเพิ่มทั้งสองด้านของผลที่ตามมา — ผู้รับ "อาจเลือกที่จะปฏิเสธหรือเก็บข้อความไว้ใน隔离 แม้ว่าจะผ่านการตรวจสอบ DMARC" และพวกเขา "ไม่ควรปฏิเสธข้อความเพียงเพราะนโยบายที่เผยแพร่เป็น 'reject'" โดยเฉพาะอย่างยิ่งเพื่อที่จดหมายที่ถูกต้องซึ่งส่งมาด้วยวิธีที่ DMARC ไม่สามารถอธิบายได้ และรายชื่อผู้รับจดหมายจะไม่ถูกทำลาย

p=none เปิดเผยอะไรจริง ๆ น้อยกว่าสิ่งที่มักถูกกล่าวหา ตามเงื่อนไขของข้อกำหนดเองมันคือ Monitoring Mode: เจ้าของโดเมนกำลังรวบรวมรายงานโดยรวมและ "ไม่แสดงความชอบในการจัดการสำหรับข้อความที่ล้มเหลวในการตรวจสอบ DMARC" ในขณะที่ผู้รับที่ใช้งาน DMARC "ยังสามารถ" ตรวจสอบการใช้โดเมนของผู้ส่ง สิ่งที่มันไม่ทำคือปิดสิ่งใด ๆ ที่ส่วนปลายรับ ตัวกรองสแปม การให้คะแนน声誉 การตรวจสอบ URL และการวิเคราะห์ไฟล์แนบของผู้ให้บริการของคุณเป็นเครื่องจักรแยกต่างหากที่ทำงานโดยไม่คำนึงถึงสิ่งที่ผู้ส่งเผยแพร่ ข้อความปลอมที่มาถึงโดเมน p=none ไม่ได้ถูกส่งเสริมไปยังกล่องจดหมายของคุณโดยบันทึก มันเพียงแค่ถูกส่งให้ผู้รับโดยไม่มีความชอบที่ระบุ และผู้รับตัดสินใจ

ความเข้าใจผิดอีกครึ่งหนึ่งวิ่งไปในทางอื่น DMARC ไม่อ่านส่วนที่อันตรายของจดหมายฟิชชิง ข้อกำหนดของมันเองระบุรายการสิ่งที่ตั้งใจให้อยู่นอกขอบเขตโดยจงใจ และ "การวิเคราะห์เนื้อหา" อยู่ในรายการนั้น ในคำพูดเหล่านั้น นอกจากนี้ยังระบุว่า DMARC "ไม่แก้ไขการใช้ชื่อโดเมนที่คล้ายกันด้านสายตาหรือการใช้สิทธิในทางที่ผิดของชื่อที่แสดงหนึ่งในมนุษย์ RFC5322.From" — เคล็ดลับทั้งสองที่นำจดหมายเอกลักษณ์ของแบรนด์มาก ส่วนมูลค่าของการผ่าน: "การผ่าน DMARC ด้วยตัวเองไม่รับประกันว่าการส่งมายังกล่องจดหมายของผู้รับจะปลอดภัยหรือพึงประสงค์" ข้อความที่ได้รับการพิสูจน์ตัวตนอย่างถูกต้องจากโดเมนทิ้ง ผ่าน DMARC อย่างสะอาด DMARC ตอบคำถามว่าใครได้รับอนุญาตให้ใช้โดเมนใน From: header ไม่มีอื่น ๆ

นี่คือที่ที่กฎผู้ส่งจำนวนมากในปี 2024 ถูกรายงานซ้ำ ๆ ตรวจสอบรวมถึงในเวอร์ชันแรกของบทความนี้ หลักเกณฑ์ผู้ส่งของ Google กำหนดให้ผู้ส่งข้อความ 5,000 ข้อความขึ้นไปต่อวันไปยังบัญชี Gmail ให้ "ตั้งค่าการพิสูจน์ตัวตน DMARC email สำหรับโดเมนการส่งของคุณ" จากนั้นพูดในลมหายใจเดียวกัน: "นโยบายการบังคับใช้ DMARC ของคุณสามารถตั้งค่าเป็น none ได้" Sender Hub ของ Yahoo เอง ซึ่งต้องอ่านแยกต่างหากมากกว่าถือว่าคัดลอก Google ระบุข้อกำหนดเป็น "เผยแพร่นโยบาย DMARC ที่ถูกต้องโดยมีอย่างน้อย p=none - DMARC ต้องผ่าน" และไม่เผยแพร่เกณฑ์ปริมาณตัวเลขเลย ข้อกำหนดทั้งสองชุดมีผลบังคับใช้ตั้งแต่เดือนกุมภาพันธ์ 2024 ไม่มีใครบังคับให้ใครออกจาก p=none สิ่งที่ทั้งสองบังคับใช้จริง ๆ คือการพิสูจน์ตัวตนที่เรียงตัวกัน: Google กำหนดให้ว่า "โดเมนใน From: header ของผู้ส่งต้องเรียงตัวกันกับโดเมน SPF หรือโดเมน DKIM" และ Yahoo บอกว่าการจัดตำแหน่งที่ยืดหยุ่นได้รับการยอมรับ การจัดตำแหน่ง ไม่ใช่ความรุนแรง คือประตู

ซึ่งปล่อยให้เหตุผลที่แท้จริงว่าทำไมโดเมนจึงนั่งอยู่ที่การตรวจสอบ และมันเป็นการทำงานมากกว่าความขาดแรงกล้า การย้ายไปที่ quarantine หรือ reject หมายถึงการค้นหาทุกบริการที่ส่งจดหมายในนามของคุณก่อน — เงินเดือน การจัดตั๋ว การตลาด โต๊ะสนับสนุนที่ไม่มีใครบันทึก — และพิสูจน์ตัวตนแต่ละรายการเพื่อให้มันเรียงตัวกัน มาตรฐานเองยอมรับอันตรายที่ทำให้เรื่องนี้ช้า: ผู้ส่งของบุคคลที่สามไม่ได้ถูกแนะนำหรือแยกออกโดย DMARC การส่งต่อและรายชื่อผู้รับจดหมายสามารถทำลายการจัดตำแหน่งโดยไม่มีข้อผิดพลาดของผู้ส่ง และข้อกำหนดชี้ให้ผู้รับ RFC 7960 สำหรับโหมดความล้มเหลวเหล่านั้นอย่างแม่นยำ องค์กรที่เผยแพร่ p=none และอ่านรายงานของมันกำลังทำงานตามลำดับที่ข้อกำหนดอธิบาย องค์กรที่เผยแพร่ p=none และละเลยรายงานนั้นไม่ใช่ จากด้านนอก บันทึกเพียงอย่างเดียวไม่สามารถบอกคุณได้ว่าคุณกำลังดูสองสิ่งใดในบรรดาทั้งสอง

คุณไม่จำเป็นต้องใช้เทอร์มินัล เครื่องมือค้นหาฟรี — ตัวตรวจสอบโดเมนของ dmarcian MXToolbox's DMARC check — ดึงบันทึกและพิมพ์นโยบายให้คุณ ทำเช่นนั้นสำหรับธนาคารของคุณ ผู้ให้บริการเงินเดือนของคุณ สายการบินที่คุณบิน เพียงแค่อ่านคำตอบสำหรับสิ่งที่เป็น: คำแถลงของจุดประสงค์โดยเจ้าของโดเมน ป้อนข้อมูลหนึ่งในหลาย ๆ อย่างในการตัดสินใจที่ผู้ให้บริการจดหมายของคุณตัดสินใจด้วยตัวเอง เกี่ยวกับการปลอมแปลงประเภทเฉพาะนี้ นี่เป็นสิ่งที่มีประโยชน์อย่างแท้จริงที่จะสามารถอ่านได้ในสิบวินาที มันไม่ใช่คำตัดสินว่าข้อความถัดไปที่อ้างว่าเป็นจากแบรนด์นั้นปลอดภัยหรือไม่

การแก้ไข 20 ตุลาคม 2026 เวอร์ชันก่อนหน้าของบทความนี้อธิบาย p=none ว่าเป็นการส่งการปลอมแปลงไปยังกล่องจดหมาย และ p=reject เป็นการตั้งค่าเดียวที่บล็อกข้อความการสปูฟ บอกว่ากฎผู้ส่งจำนวนมากของ Google และ Yahoo ในปี 2024 บังคับให้ผู้ส่งออกจาก p=none และอ้างอิงตัวเลขประมาณหนึ่งในสามของโดเมนที่มีการบังคับใช้ คำอธิบายนโยบายได้รับการแก้ไขตาม RFC 9989; Google และ Yahoo จริง ๆ แล้วยอมรับ p=none ตามที่อ้างจากเอกสารของตนเอง และตัวเลขการบังคับใช้ได้ถูกลบออกเนื่องจากรายงานพื้นฐานไม่เผยแพร่ตัวอย่างหรือตัวส่วนของมัน บทความนี้ยังระบุว่า DMARC ไม่ตรวจสอบอะไร

@@END@@