DMARC คือระเบียน TXT ที่ _dmarc.<your domain> ซึ่งบอกเซิร์ฟเวอร์ผู้รับว่าควรจัดการอย่างไรกับอีเมลที่ใช้โดเมนของคุณในเฮดเดอร์ From แต่ไม่ผ่านทั้ง SPF และ DKIM แบบ aligned และให้ส่งรายงานไปที่ใด โดย p=none ขอเพียงรายงาน ขณะที่ p=quarantine ขอให้เซิร์ฟเวอร์ผู้รับมองว่าอีเมลที่ไม่ผ่านนั้นน่าสงสัย และ p=reject ขอให้ปฏิเสธอีเมลนั้นไปเลย

Gmail, Yahoo และ Microsoft ยอมรับ p=none จากผู้ส่งอีเมลปริมาณมาก หลายโดเมนจึงเผยแพร่นโยบายนี้แล้วหยุดอยู่แค่นั้น ได้รายงานเกี่ยวกับผู้ปลอมแปลงอีเมลแต่ไม่ได้บล็อก ผลวิเคราะห์โดเมน 73.3 ล้านโดเมนของ Red Sift ซึ่งถูกอ้างถึงเมื่อเมษายน 2026 พบว่า 14.9% มีนโยบาย DMARC อยู่บ้าง และ 2.5% บังคับใช้ p=reject ส่วน EasyDMARC ผู้ให้บริการ DMARC อีกราย รายงานในปี 2025 ว่า 62.7% ของบริษัทใน Fortune 500 ที่มี DMARC ใช้ p=reject เทียบกับ 15.2% ของบริษัทใน Inc. 5000

นี่คือแผน 30 วันสู่ p=reject แบบทีละระเบียน สำหรับโดเมนที่ส่งอีเมลจากอีเมลองค์กร, ESP 1 หรือ 2 ราย, ระบบเฮลป์เดสก์ และเครื่องมือเรียกเก็บเงิน ระยะเวลา 30 วันเหมาะกับซับโดเมนสำหรับส่งอีเมล ส่วนโดเมนที่พนักงานใช้รับส่งอีเมลในงานประจำวันต้องใช้เวลานานกว่านั้น

ประเด็นสำคัญ

• เผยแพร่ v=DMARC1; p=none; rua=mailto:... ในวันที่ 1 หากไม่มี rua เซิร์ฟเวอร์ผู้รับจะต้องไม่ส่งรายงานแบบรวม (aggregate report)
• ผู้ส่งที่ถูกต้องทุกรายต้องผ่าน SPF หรือ DKIM ที่ align กับโดเมนใน From ของคุณ สำหรับเครื่องมือส่วนใหญ่ นั่นหมายถึงการลงนาม DKIM ด้วยโดเมนของคุณ
• ให้ SPF มีรายการที่ต้องค้นหา DNS ไม่เกิน 10 รายการ โดยนับรวม include ที่ซ้อนอยู่ด้วย ไม่เช่นนั้นอีเมลทั้งหมดของคุณจะได้ผลเป็น permerror
• ขยับไปใช้ p=quarantine ในวันที่ 15 และ p=reject ในวันที่ 22 โดยแต่ละขั้นต้องมีรายงานที่ไม่พบปัญหาครบหนึ่งสัปดาห์ก่อน ส่วนโดเมนที่พนักงานใช้รับส่งอีเมลในงานประจำวันนั้น RFC 9989 ให้ใช้เวลาขั้นละหนึ่งเดือนใน 2 ขั้นแรก
• RFC 9989 (พฤษภาคม 2026) กำหนดให้ pct อยู่ในสถานะ historic จึงไม่ต้องค่อย ๆ ไล่ค่า pct=10, pct=50
• BIMI ต้องใช้ p=quarantine หรือ p=reject บนโดเมนระดับองค์กร ต้องไม่มี sp=none ต้องมีโลโก้แบบ SVG Tiny PS และสำหรับ Gmail ต้องมี VMC หรือ CMC

DMARC เปลี่ยนไปอย่างไรในปี 2026

เมื่อเดือนพฤษภาคม 2026 ทาง IETF ได้แทนที่ RFC 7489 ซึ่งเป็นเอกสารประเภท Informational จากปี 2015 ด้วย DMARCbis ได้แก่ RFC 9989 ซึ่งเป็น Proposed Standard ที่ทำให้ RFC 9091 ล้าสมัยไปด้วย และ RFC 9990 สำหรับการรายงานแบบรวม การเปลี่ยนแปลงที่สำคัญสำหรับเรื่องนี้มี 3 ข้อ:

• pct อยู่ในสถานะ historic ภาคผนวก A.6 ระบุว่า pct “มักไม่ได้ถูกนำไปใช้อย่างถูกต้อง เว้นแต่ค่าที่ระบุจะเป็น 0 หรือ 100”
• t=y มาแทน pct=0 เซิร์ฟเวอร์ผู้รับจะใช้นโยบายที่ต่ำกว่านโยบายของคุณหนึ่งระดับ ดังนั้น p=reject; t=y จึงทำงานแบบ quarantine โดยแท็กนี้เป็นสวิตช์สำหรับทดสอบ
• np เป็นแท็กใหม่ ใช้กับซับโดเมนที่ไม่มีอยู่ใน DNS และเซิร์ฟเวอร์ผู้รับรุ่นเก่าต้องเพิกเฉยต่อแท็กนี้

นอกจากนี้ การไล่ตรวจตามลำดับชั้นของ DNS (DNS tree walk) ยังมาแทน public suffix list ในการหาโดเมนระดับองค์กร (organizational domain) ด้วย

ระเบียน 3 รายการที่ DMARC ต้องอาศัย

DMARC จะผ่านเมื่อ SPF หรือ DKIM ผ่าน และโดเมนที่ผ่านนั้นตรงกับโดเมนใน From (alignment) ขอแค่ผ่านแบบ aligned อย่างใดอย่างหนึ่งก็เพียงพอ

SPF และขีดจำกัดการค้นหา DNS 10 ครั้ง

SPF ให้สิทธิ์เซิร์ฟเวอร์ที่ส่งในนามโดเมนของ envelope (MAIL FROM หรือ return-path) ซึ่งเป็นตัวตนเดียวที่ DMARC ใช้ ไม่ใช่ HELO ทั้งนี้ RFC 7208 หัวข้อ 4.6.4 จำกัดรายการที่ต้องค้นหา DNS ไว้ที่ 10 รายการ ได้แก่ include, a, mx, ptr, exists และ redirect โดยนับรวมทุก include ที่ซ้อนอยู่ ส่วน ip4, ip6 และ all ไม่นับ หากเกินจะได้ผลเป็น permerror หัวข้อนี้ยังอนุญาตให้มี “void lookup” ได้ไม่เกิน 2 ครั้ง ซึ่งมักเป็น include ที่ชี้ไปยังชื่อโฮสต์ที่ไม่มีอยู่แล้ว

example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:_spf.helpdesk.example include:mail.billing.example ~all"

ระเบียนนี้ใช้การค้นหาไปแล้ว 4 ครั้งก่อนจะนับสิ่งที่ผู้ให้บริการแต่ละรายซ้อนไว้ข้างใน ให้ตรวจแต่ละรายการด้วย dig +short TXT <name> ไล่ลงไปตามลำดับ หากต้องการไม่ให้เกิน 10 ให้ตัดเครื่องมือที่เลิกใช้แล้วออก หรือให้ ESP แต่ละรายมีซับโดเมน return-path ของตัวเอง เช่น bounce.example.com ซึ่งจะมีโควตา 10 ครั้งแยกต่างหาก คู่มือการตั้งค่า SPF ของ Microsoft แนะนำให้ปิดท้ายด้วย -all สำหรับโดเมนที่ใช้ DKIM และ DMARC ด้วย

ESP หลายรายใช้โดเมน return-path ของตัวเองเป็นค่าเริ่มต้น ซึ่งไม่ align กับโดเมนของคุณ ให้ตั้งค่า return-path แบบกำหนดเอง หรือใช้ DKIM แทน

DKIM: คีย์ 2048 บิต, selector และการเปลี่ยนคีย์

DKIM ลงนามอีเมลแต่ละฉบับด้วยโดเมน d= และ selector s= แล้วเซิร์ฟเวอร์ผู้รับจะดึงคีย์จาก <selector>._domainkey.<d domain> เครื่องมือที่ลงนามด้วย d=vendor-mail.example จะผ่าน DKIM แต่ไม่ผ่าน DMARC

RFC 8301 ระบุว่าผู้ลงนามต้องใช้คีย์ RSA ขนาดอย่างน้อย 1024 บิต และควรใช้ 2048 บิต แนวทางสำหรับผู้ส่งของ Google ก็ระบุแบบเดียวกันสำหรับการส่งไปยังบัญชี Gmail ส่วนตัว คีย์ 2048 บิตยาวเกินขีดจำกัดสตริง TXT ที่ 255 อักขระ จึงต้องใส่เป็นสตริงในเครื่องหมายคำพูดหลายชุดภายในระเบียนเดียว ซึ่งผู้ให้บริการ DNS ส่วนใหญ่แบ่งให้คุณเอง

s202610._domainkey.example.com.  3600  IN  TXT  ( "v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu1x..."
    "...remainder-of-the-2048-bit-key...IDAQAB" )

ให้ระบบส่งแต่ละระบบมี selector ของตัวเอง และอย่านำชื่อเดิมกลับมาใช้ซ้ำ การตั้งชื่อด้วยวันที่ เช่น s202610 ช่วยให้อ่านประวัติย้อนหลังได้ง่าย แนวปฏิบัติในการเปลี่ยนคีย์ของ M3AAWG แนะนำให้เปลี่ยนคีย์ใหม่อย่างน้อยทุก 6 เดือน:

1. เผยแพร่ selector ใหม่ แล้วรอให้ระเบียนมีผล
2. เปลี่ยนไปลงนามด้วยคีย์ใหม่
3. เก็บคีย์สาธารณะเดิมไว้ใน DNS เป็นเวลา 7 ถึง 30 วัน เพื่อให้อีเมลที่อยู่ระหว่างทางยังยืนยันได้
4. ปลดระวาง selector เดิมด้วยค่า p= ที่ว่างไว้ อย่าลบทิ้ง

Alignment: แบบ relaxed หรือ strict

RFC 9989 กำหนดไว้ 2 โหมด:

RFC 9989 ระบุว่า “เจ้าของโดเมนเกือบทั้งหมดพบว่า alignment แบบ relaxed ก็เพียงพอแล้ว” จึงไม่ต้องใส่ aspf และ adkim ส่วน alignment ของ SPF แบบ strict จะทำให้การตั้ง return-path บนซับโดเมนตามปกติใช้งานไม่ได้

แผน 30 วัน

ระเบียนของแต่ละขั้น ขยับไปขั้นถัดไปเมื่อรายงานไม่พบปัญหาครบหนึ่งสัปดาห์แล้วเท่านั้น

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

วันที่ 1 ถึง 7: เผยแพร่ p=none พร้อมเปิดรับรายงาน

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

รายงานเป็นไฟล์ XML ที่บีบอัดด้วย gzip ซึ่งเซิร์ฟเวอร์ผู้รับแต่ละรายส่งมาอย่างน้อยวันละครั้ง ดังนั้นให้ชี้ rua ไปยังระบบประมวลผลรายงาน ไม่ใช่กล่องอีเมลของคน หากที่อยู่นั้นอยู่บนโดเมนระดับองค์กรอื่น RFC 9990 กำหนดให้เซิร์ฟเวอร์ผู้รับเพิกเฉย เว้นแต่ example.com._report._dmarc.<report domain> จะให้สิทธิ์ไว้ ผู้ให้บริการประมวลผลรายงานจะเผยแพร่ระเบียนนี้ให้ ส่วนโดเมนของคุณเอง ให้เพิ่มระเบียนนี้เอง

เผยแพร่ระเบียน DMARC เพียงรายการเดียวเท่านั้น หากวิซาร์ดตั้งค่าทิ้งระเบียน v=DMARC1 ไว้ 2 รายการที่ _dmarc.example.com เซิร์ฟเวอร์ผู้รับจะทิ้งทั้งสองรายการ

ไม่ต้องใช้ ruf เพราะ RFC 9989 ระบุว่าเซิร์ฟเวอร์ผู้รับที่ให้ความสำคัญกับความเป็นส่วนตัวจะปิดบังข้อมูลในรายงานความล้มเหลว (failure report) อย่างมาก หรือไม่ส่งเลย และคำถามที่พบบ่อยในประกาศสำหรับผู้ส่งอีเมลปริมาณมากของ Microsoft ระบุว่า Microsoft ส่งรายงาน rua และไม่มีแผนจะส่ง ruf

วิธีอ่านรายงานแบบรวม

RFC 9990 อธิบายถึงรายงาน XML แบบ “รายวัน (หรือถี่กว่านั้น)” แยกฉบับตามโดเมนนโยบาย ต่อไปนี้คือข้อมูล 1 รายการที่ดัดแปลงจากตัวอย่างใน RFC:

<record>
  <row>
    <source_ip>192.0.2.123</source_ip>
    <count>123</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <envelope_from>bounces.vendor.example</envelope_from>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>vendor.example</domain>
      <selector>abc123</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>bounces.vendor.example</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

ใน policy_evaluated ค่า dkim และ spf คือผลการตรวจ alignment ส่วน disposition คือสิ่งที่เซิร์ฟเวอร์ผู้รับทำกับอีเมล และ auth_results เก็บผลดิบพร้อมโดเมนของแต่ละผล ในตัวอย่างนี้ทั้งคู่ผ่านสำหรับ vendor.example จึงไม่ผ่าน alignment ทั้งคู่ กล่าวคือผู้ให้บริการรายหนึ่งส่งอีเมลในนามของคุณโดยไม่ได้ลงนามในนามของคุณ ให้เปิดใช้ DKIM แบบกำหนดเองหรือการยืนยันตัวตนของโดเมนในบริการของผู้ให้บริการรายนั้น

วันที่ 1 ถึง 7: หาผู้ส่งที่คุณไม่รู้จัก

จัดกลุ่มตาม source_ip, envelope_from และ domain กับ selector ของ DKIM เรียงตาม count แล้วแยกเป็นกลุ่มดังนี้:

หากต้องการระบุว่า IP เป็นของใคร ให้รัน dig -x 192.0.2.123 +short แล้วดู selector ซึ่งมักมีชื่อผู้ให้บริการอยู่ จากนั้นถามฝ่ายการเงิน ฝ่ายสนับสนุน และฝ่ายขายว่ามีอะไรส่งอีเมลในนามบริษัทบ้าง เช่น ระบบเรียกเก็บเงิน ระบบเฮลป์เดสก์ คำเชิญในปฏิทิน และเครื่องสแกนในออฟฟิศ

อีเมลที่ถูกส่งต่อและอีเมลจากเมลลิงลิสต์จะไม่ผ่านในแบบที่คุณแก้ไม่ได้ และหน้าคำถามที่พบบ่อยสำหรับผู้ส่งของ Google ก็ไม่ได้กำหนดให้อีเมลเหล่านี้ต้องผ่าน alignment จึงไม่ต้องรอให้อีเมลกลุ่มนี้ผ่าน

วันที่ 8 ถึง 14: แก้ไขแหล่งส่งที่ถูกต้องทุกแหล่ง

เริ่มจากแหล่งที่มี count สูงสุดไล่ลงมา:

1. อีเมลองค์กร (Google Workspace, Microsoft 365): เปิดใช้ DKIM ในคอนโซลผู้ดูแล ใช้คีย์ 2048 บิตหากมีให้เลือก และตรวจว่า include ของผู้ให้บริการอยู่ใน SPF แล้ว
2. ESP และเครื่องมือการตลาด: ตั้งค่าการยืนยันตัวตนของโดเมนเพื่อให้ลงนามด้วย d= ของคุณ และตั้ง return-path แบบกำหนดเองหากมีให้ใช้
3. ระบบเฮลป์เดสก์, ระบบเรียกเก็บเงิน และ CRM: ทำแบบเดียวกับ ESP หากระบบใดลงนามด้วยโดเมนของคุณไม่ได้ ให้ใช้ซับโดเมนที่ระบบนั้นลงนามได้ หรือใช้โดเมนของระบบนั้นเอง
4. เครื่องมือที่เลิกใช้แล้ว: ลบ include และ selector ของเครื่องมือเหล่านั้นออก

จากนั้นนับจำนวนการค้นหา DNS ของ SPF ใหม่อีกครั้ง

วันที่ 15: p=quarantine

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

นโยบาย quarantine มักหมายถึงการส่งเข้าโฟลเดอร์สแปม ให้เฝ้าดูแหล่งส่งที่ถูกต้องซึ่งได้ disposition เป็น quarantine หากต้องการซ้อมก่อน ให้ใช้ p=quarantine; t=y ซึ่งจะขอให้เซิร์ฟเวอร์ผู้รับที่รองรับ RFC 9989 ใช้ none แทน แต่ RFC นี้เพิ่งออกมาได้ไม่กี่เดือน และยังไม่ใช่ทุกเซิร์ฟเวอร์ผู้รับที่รองรับ t

วันที่ 22: p=reject

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=reject; np=reject; rua=mailto:dmarc-reports@example.com"

เซิร์ฟเวอร์ผู้รับที่ปฏิบัติตาม p=reject จะปฏิเสธอีเมลที่ไม่ผ่านตั้งแต่ในเซสชัน SMTP แต่ RFC 9989 ให้เซิร์ฟเวอร์ผู้รับใช้ quarantine แทนเมื่อนโยบายเป็นหลักฐานเพียงอย่างเดียวที่มี อีเมลบางส่วนจึงไปอยู่ในสแปม

RFC ฉบับเดียวกันระบุว่าโดเมนที่ใช้ p=reject “ต้องไม่ (MUST NOT) พึ่งพา SPF เพียงอย่างเดียว” และต้องลงนามด้วย DKIM เพราะการส่งต่อทำให้ SPF ไม่ผ่าน แต่ไม่กระทบ DKIM ให้ยืนยันก่อนว่าทุกแหล่งส่งมี DKIM ที่ผ่าน alignment

เก็บ rua ไว้ตลอดไป เครื่องมือใหม่ที่จะเข้ามาในไตรมาสหน้าจะโผล่ในรายงานของคุณก่อนจะโผล่ในคิวงานของฝ่ายสนับสนุน

เมื่อไรควรยืดแผนออกไป

RFC 9989 หัวข้อ 7.4 ระบุว่าโดเมนที่ผู้ใช้โพสต์ลงเมลลิงลิสต์ “ไม่ควร (SHOULD NOT)” เผยแพร่ p=reject และโดเมนที่จะเผยแพร่ควรอยู่ที่ p=none “อย่างน้อยหนึ่งเดือน” ก่อน แล้วอยู่ที่ p=quarantine “เป็นระยะเวลาที่ยาวเท่ากัน” ซึ่งครอบคลุมโดเมนหลัก (apex) ของบริษัทส่วนใหญ่ ดังนั้นสำหรับโดเมนเหล่านี้ ให้ใช้เวลาขั้นละหนึ่งเดือนใน 2 ขั้นแรก ส่วนซับโดเมนที่ ESP ของคุณใช้เพียงรายเดียวไม่มีทราฟฟิกจากเมลลิงลิสต์ จึงคงจังหวะ 30 วันไว้ได้

นโยบายซับโดเมน: sp= และ np=

p ครอบคลุมโดเมนและซับโดเมนของโดเมนนั้น ขณะที่ sp ใช้แทนนโยบายนั้นสำหรับซับโดเมนที่มีอยู่จริง และ np ใช้แทนสำหรับซับโดเมนที่ไม่มีอยู่ ซับโดเมนที่มีระเบียนของตัวเองจะใช้ระเบียนนั้น และ RFC 9989 จะไม่สนใจ sp ในกรณีนี้

ซับโดเมนสำหรับส่งอีเมลโดยเฉพาะ เช่น mail.example.com ที่ ESP เพียงรายเดียวใช้ และยืนยัน SPF กับ DKIM แล้ว เผยแพร่ p=reject ได้ตั้งแต่วันแรก ส่วน p=none; sp=reject บนโดเมนหลักจะช่วยปกป้องซับโดเมนระหว่างที่คุณจัดการโดเมนหลักให้เสร็จ แต่จะทำให้ใช้ BIMI ไม่ได้

โดเมนที่จอดไว้เฉย ๆ (parked domain) ควรเผยแพร่ v=spf1 -all ตามคู่มือ SPF ของ Microsoft และเผยแพร่ v=DMARC1; p=reject; ที่ _dmarc ด้วย

วันที่ 30 เป็นต้นไป: BIMI

BIMI แสดงโลโก้ของคุณข้างอีเมลที่ผ่านการยืนยันตัวตนในอินบ็อกซ์ที่รองรับ:

ร่างมาตรฐาน BIMI อยู่ที่ฉบับแก้ไขที่ 14 (พฤษภาคม 2026) และยังเป็น Internet-Draft ที่เขียนอิง RFC 7489 จึงยังพูดถึง pct อยู่ ให้ละ pct ไว้ และอย่าตั้ง t=y

กฎเรื่องโดเมนระดับองค์กรทำให้ผู้ที่ส่งจากซับโดเมนติดปัญหา หาก mail.example.com ใช้ p=reject แต่ example.com ใช้ p=none เซิร์ฟเวอร์ผู้รับต้องไม่แสดงโลโก้ ดังนั้นโดเมนหลักก็ต้องทำตามแผนจนจบด้วย

แนวทางเรื่อง SVG ของ BIMI Group แนะนำให้ใช้โลโก้ทรงจัตุรัส จัดกึ่งกลาง บนพื้นหลังสีทึบ และมีขนาดต่ำกว่า 32 KB ส่วน Google เพิ่มการรองรับ CMC เมื่อเดือนกันยายน 2024 และนี่คือระเบียนตามคู่มือการใช้งานของ BIMI Group:

default._bimi.example.com.  3600  IN  TXT  "v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/certificate.pem"

การจดทะเบียนเครื่องหมายการค้าใช้เวลาหลายเดือน หากจะทำ VMC ให้เริ่มตั้งแต่ตอนนี้

ข้อกำหนดของ Gmail, Yahoo และ Microsoft

ไม่มีรายใดใน 3 รายนี้กำหนดให้ต้องบังคับใช้ DMARC กำหนดเพียงให้มีระเบียน DMARC และผ่าน alignment

แหล่งที่มา: แนวทางสำหรับผู้ส่งของ Google และหน้าคำถามที่พบบ่อย, แนวทางปฏิบัติที่ดีสำหรับผู้ส่งของ Yahoo รวมถึงประกาศเมื่อเดือนเมษายน 2025 และหน้าช่วยเหลือเรื่อง 5.7.515 ของ Microsoft โดย Microsoft เริ่มบังคับใช้เมื่อวันที่ 5 พฤษภาคม 2025 หลังการอัปเดตเมื่อวันที่ 29 เมษายนเปลี่ยนการดำเนินการจากการย้ายเข้าโฟลเดอร์อีเมลขยะเป็นการปฏิเสธ

หน้าคำถามที่พบบ่อยของ Google ระบุว่า alignment กับทั้ง SPF และ DKIM “จะกลายเป็นข้อกำหนดสำหรับผู้ส่งในที่สุด” จึงควรทำให้ผ่าน alignment ทั้งคู่ในสัปดาห์ที่ 2 ส่วนเรื่องการยกเลิกการรับข่าวสารและอัตราสแปม อ่านสิ่งที่ยังต้องทำตามเมื่อเอเจนต์ส่งอีเมลแทนคุณ และคู่มืออัตราการส่งถึงของเรา

DMARC บนโดเมนผู้ส่งของ Brew

การตั้งค่าโดเมนของ Brew ต้องใช้ระเบียนต่อไปนี้:

• DKIM: ระเบียน TXT ที่ selector ._domainkey ภายใต้โดเมนผู้ส่งของคุณ จำเป็นต้องมี
• SPF: ระเบียน MX และระเบียน TXT บน send.<your sending domain> ซึ่งเป็น return-path ของ Brew จำเป็นต้องมี
• DMARC: ระเบียน TXT ที่ _dmarc.<your sending domain> ไม่บังคับ แต่แนะนำให้มี
• ระเบียน CNAME สำหรับการติดตามคลิก ใช้เฉพาะเมื่อมีซับโดเมนติดตามแบบกำหนดเอง

โดเมนจะเริ่มส่งได้เมื่อยืนยัน SPF และ DKIM ผ่านแล้ว และ Brew จะแนะนำค่า DMARC ที่เหมาะสมให้:

; dedicated sending subdomain, e.g. mail.example.com
_dmarc.mail.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@mail.example.com"
 
; apex domain, or a domain Brew can't prove is dedicated
_dmarc.example.com.       TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

ซับโดเมนเฉพาะได้ p=reject เพราะไม่มีอะไรส่งจากซับโดเมนนั้นก่อนที่ SPF และ DKIM ของ Brew จะยืนยันผ่าน ส่วนโดเมนหลัก (apex) ได้ p=none เพราะเครื่องมืออื่นของคุณน่าจะส่งในนามโดเมนนี้ด้วย จึงควรทำตามแผนข้างต้น ทั้งนี้ alignment ยังคงเป็นแบบ relaxed เพราะ return-path send.<domain> จะ align ได้เฉพาะในโหมด relaxed เท่านั้น

Brew อ่านระเบียน _dmarc.<sending domain> ที่ใช้งานอยู่จริงทุกครั้งที่เพิ่มโดเมน ยืนยันโดเมน และตรวจสอบซ้ำ ผลลัพธ์จะแสดงในหน้า โดเมน รวมถึงผ่าน get_domain_health ทาง MCP และ GET /v1/domains/{domainId}/health:

• dmarc_missing: คำเตือนพร้อมระเบียนที่ต้องเพิ่มแบบตรงตัว
• dmarc_invalid: เมื่อมีระเบียน DMARC 2 รายการที่ชื่อเดียวกัน หรือมีเวอร์ชันหรือนโยบายที่ไม่ถูกต้อง หรือมีแท็กซ้ำ โดยจะระบุระเบียนที่ต้องลบ
• ยืนยันแล้ว: เมื่อพบระเบียนที่ถูกต้องเพียงรายการเดียว

การตั้งค่า DNS อัตโนมัติจะเขียนระเบียน DMARC เฉพาะเมื่อยังไม่มีระเบียนอยู่ จึงไม่สร้างระเบียนซ้ำ การตรวจจะทำที่โดเมนผู้ส่ง ไม่ใช่โดเมนแม่ ดังนั้นให้ซับโดเมนสำหรับส่งอีเมลแต่ละรายการมีระเบียนของตัวเอง รวมถึงซับโดเมนสำหรับอีเมลธุรกรรมหากคุณแยกทั้งสองประเภทออกจากกันตามที่เอกสารแนะนำ ส่วนระบบประมวลผล rua คือที่ที่คุณอ่านรายงานและตัดสินใจว่าจะขยับไปใช้ reject เมื่อไร

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

ควรอยู่ที่ p=none นานแค่ไหนก่อนขยับไป quarantine?

จนกว่ารายงานตลอดหนึ่งสัปดาห์เต็มจะแสดงว่าแหล่งส่งที่ถูกต้องทุกแหล่งผ่าน SPF หรือ DKIM แบบ aligned ซึ่งสำหรับซับโดเมนสำหรับส่งอีเมลมักใช้เวลา 1 ถึง 2 สัปดาห์ ส่วนโดเมนที่พนักงานใช้รับส่งอีเมลในงานประจำวันนั้น RFC 9989 กำหนดให้ใช้เวลาอย่างน้อยหนึ่งเดือน การอยู่ที่ p=none นาน 2 ปีโดยไม่มีใครอ่านรายงานเลยไม่มีประโยชน์อะไร

แท็ก pct ของ DMARC เลิกใช้แล้วหรือไม่?

ใช่ RFC 9989 จัด pct ไว้ในสถานะ “historic” และนำ t มาแทนค่าของ pct ที่เคยใช้ได้อย่างน่าเชื่อถือ โดย t=y ทำงานเหมือน pct=0 และ t=n เหมือน pct=100 เซิร์ฟเวอร์ผู้รับรุ่นเก่าอาจยังอ่าน pct อยู่ แต่ไม่เคยใช้ค่าระหว่างกลางอย่างสม่ำเสมอ จึงควรขยับทีละขั้นเต็ม ๆ

p=reject จะบล็อกอีเมลที่ส่งต่อไหม?

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

Gmail และ Yahoo บังคับให้ใช้ p=reject ไหม?

ไม่บังคับ ทั้งสองรายกำหนดให้ผู้ส่งอีเมลปริมาณมากเผยแพร่ DMARC และยอมรับ p=none เช่นเดียวกับ Microsoft สำหรับผู้ที่ส่งมากกว่า 5,000 ฉบับต่อวันไปยัง Outlook.com การบังคับใช้ช่วยหยุดการปลอมแปลงอีเมลและเป็นเงื่อนไขของ BIMI แต่ทั้ง 3 รายไม่ได้บังคับ

ต้องมี VMC สำหรับ BIMI ไหม?

สำหรับ Gmail คุณต้องมี VMC ซึ่งต้องมีเครื่องหมายการค้าจดทะเบียนและจะแสดงเครื่องหมายถูก หรือ CMC ซึ่งแสดงโลโก้โดยไม่มีเครื่องหมายถูก BIMI Group ระบุว่าผู้ให้บริการบางราย รวมถึง Yahoo และ Fastmail ยังแสดงโลโก้ที่ประกาศเองโดยไม่มีใบรับรองด้วย