# DMARC: จาก p=none สู่ p=reject ใน 30 วัน

URL หลัก: https://brew.new/th/blog/dmarc-p-none-to-reject-in-30-days
ผู้เขียน: Thomas Park
เผยแพร่: 2026-10-04
อัปเดต: 2026-10-04

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](https://redsift.com/blog/email-authentication-bespinlabs-redsift) พบว่า 14.9% มีนโยบาย DMARC อยู่บ้าง และ 2.5% บังคับใช้ `p=reject` ส่วน EasyDMARC ผู้ให้บริการ DMARC อีกราย [รายงานในปี 2025](https://easydmarc.com/blog/dmarc-adoption-across-fortune-500-and-inc-5000-the-growing-divide/) ว่า 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](https://www.rfc-editor.org/rfc/rfc9989.html) ซึ่งเป็น Proposed Standard ที่ทำให้ RFC 9091 ล้าสมัยไปด้วย และ [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html) สำหรับการรายงานแบบรวม การเปลี่ยนแปลงที่สำคัญสำหรับเรื่องนี้มี 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](https://www.rfc-editor.org/rfc/rfc7208.html#section-4.6.4) จำกัดรายการที่ต้องค้นหา DNS ไว้ที่ 10 รายการ ได้แก่ `include`, `a`, `mx`, `ptr`, `exists` และ `redirect` โดยนับรวมทุก include ที่ซ้อนอยู่ ส่วน `ip4`, `ip6` และ `all` ไม่นับ หากเกินจะได้ผลเป็น `permerror` หัวข้อนี้ยังอนุญาตให้มี “void lookup” ได้ไม่เกิน 2 ครั้ง ซึ่งมักเป็น include ที่ชี้ไปยังชื่อโฮสต์ที่ไม่มีอยู่แล้ว

```dns
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](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure) ของ 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](https://www.rfc-editor.org/rfc/rfc8301.html) ระบุว่าผู้ลงนามต้องใช้คีย์ RSA ขนาดอย่างน้อย 1024 บิต และควรใช้ 2048 บิต [แนวทางสำหรับผู้ส่งของ Google](https://support.google.com/mail/answer/81126) ก็ระบุแบบเดียวกันสำหรับการส่งไปยังบัญชี Gmail ส่วนตัว คีย์ 2048 บิตยาวเกินขีดจำกัดสตริง TXT ที่ 255 อักขระ จึงต้องใส่เป็นสตริงในเครื่องหมายคำพูดหลายชุดภายในระเบียนเดียว ซึ่งผู้ให้บริการ DNS ส่วนใหญ่แบ่งให้คุณเอง

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

ให้ระบบส่งแต่ละระบบมี selector ของตัวเอง และอย่านำชื่อเดิมกลับมาใช้ซ้ำ การตั้งชื่อด้วยวันที่ เช่น `s202610` ช่วยให้อ่านประวัติย้อนหลังได้ง่าย [แนวปฏิบัติในการเปลี่ยนคีย์](https://www.m3aawg.org/sites/default/files/m3aawg-dkim-key-rotation-bp-2019-03.pdf)ของ M3AAWG แนะนำให้เปลี่ยนคีย์ใหม่อย่างน้อยทุก 6 เดือน:

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

### Alignment: แบบ relaxed หรือ strict

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

| โหมด | แท็ก | โดเมนที่ผ่าน SPF/DKIM | โดเมนใน From | Aligned ไหม? |
|---|---|---|---|---|
| Relaxed (ค่าเริ่มต้น) | `aspf=r`, `adkim=r` | `bounce.example.com` | `mail.example.com` | ใช่ เพราะอยู่ในโดเมนระดับองค์กรเดียวกัน |
| Strict | `aspf=s`, `adkim=s` | `bounce.example.com` | `mail.example.com` | ไม่ใช่ เพราะชื่อต้องตรงกันทุกตัว |
| ทั้งสองโหมด | | `vendor.example.net` | `example.com` | ไม่ใช่ |

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

## แผน 30 วัน

![ไทม์ไลน์ DMARC 30 วันใน 4 ขั้น: วันที่ 1 ถึง 7 ใช้ p=none พร้อมรายงาน rua, วันที่ 8 ถึง 14 แก้ไขผู้ส่ง, วันที่ 15 ใช้ p=quarantine, วันที่ 22 ใช้ p=reject จากนั้นเริ่ม BIMI ตั้งแต่วันที่ 30 พร้อมระเบียน TXT แบบตรงตัวของแต่ละขั้น](/images/blog/dmarc-p-none-to-reject-in-30-days-timeline.png)

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

| วัน | นโยบาย | สิ่งที่ต้องทำ | เงื่อนไขก่อนขยับต่อ |
|---|---|---|---|
| 1 ถึง 7 | `p=none` | เผยแพร่พร้อม `rua` และทำรายการแหล่งส่งทุกแหล่ง | มีรายงานครบ 7 วันจาก Google, Yahoo และ Microsoft |
| 8 ถึง 14 | `p=none` | แก้ไข DKIM และ SPF, ปลดระวางผู้ส่งที่ไม่ได้ใช้ | แหล่งส่งที่ถูกต้องทุกแหล่งผ่าน SPF หรือ DKIM แบบ aligned |
| 15 ถึง 21 | `p=quarantine` | เฝ้าดูอีเมลที่ถูกต้องซึ่งถูก quarantine | 7 วันที่ไม่มีแหล่งส่งที่ถูกต้องรายใดไม่ผ่าน |
| 22 ถึง 30 | `p=reject` | อ่านรายงานต่อไป และเพิ่ม `np=reject` | คงที่ครบหนึ่งสัปดาห์ |
| 30 ขึ้นไป | `p=reject` | เริ่มทำ BIMI | ได้รับใบรับรองแล้ว |

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

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

```dns
_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) อย่างมาก หรือไม่ส่งเลย และคำถามที่พบบ่อยใน[ประกาศสำหรับผู้ส่งอีเมลปริมาณมาก](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%e2%80%99s-new-requirements-for-high%e2%80%90volume-senders/4399730)ของ Microsoft ระบุว่า Microsoft ส่งรายงาน `rua` และไม่มีแผนจะส่ง `ruf`

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

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

```xml
<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` แล้วแยกเป็นกลุ่มดังนี้:

| รูปแบบในรายงาน | สาเหตุที่เป็นไปได้ | สิ่งที่ต้องทำ |
|---|---|---|
| ผ่าน DKIM หรือ SPF แบบ aligned | ตั้งค่าถูกต้องแล้ว | ไม่ต้องทำอะไร |
| DKIM และ SPF ผ่านสำหรับโดเมนของผู้ให้บริการ | เครื่องมือ SaaS ที่ใช้ตัวตนของตัวเอง | เปิดใช้ DKIM แบบกำหนดเอง |
| DKIM ผ่านแบบ aligned, SPF ไม่ผ่าน, IP ของผู้ให้บริการอีเมลหรือเมลลิงลิสต์ | การส่งต่อหรือเมลลิงลิสต์ | มักไม่ต้องทำอะไร เพราะ DKIM ที่ผ่าน alignment ยังผ่านแม้ถูกส่งต่อ |
| ไม่มี DKIM, SPF ไม่ผ่าน, IP ที่ระบุที่มาไม่ได้ | การปลอมแปลงอีเมล | ไม่ต้องทำอะไร นี่คือสิ่งที่ `p=reject` หยุดได้ |

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

อีเมลที่ถูกส่งต่อและอีเมลจากเมลลิงลิสต์จะไม่ผ่านในแบบที่คุณแก้ไม่ได้ และ[หน้าคำถามที่พบบ่อยสำหรับผู้ส่ง](https://support.google.com/mail/answer/14229414)ของ 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

```dns
_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

```dns
_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 แสดงโลโก้ของคุณข้างอีเมลที่ผ่านการยืนยันตัวตนในอินบ็อกซ์ที่รองรับ:

| ข้อกำหนด | รายละเอียด | แหล่งที่มา |
|---|---|---|
| นโยบาย DMARC | `p=quarantine` หรือ `p=reject` บนโดเมนระดับองค์กรและโดเมนใน From | ร่างมาตรฐาน BIMI |
| นโยบายซับโดเมน | หากเผยแพร่ `sp` ไว้ ต้องไม่เป็น `none` | ร่างมาตรฐาน BIMI |
| เปอร์เซ็นต์ | quarantine ต้องไม่มี `pct` ต่ำกว่า 100 | ร่างมาตรฐาน BIMI |
| โลโก้ | SVG Tiny PS: `baseProfile="tiny-ps"`, `version="1.2"`, มี `<title>`, ไม่มีสคริปต์หรือการอ้างอิงภายนอก และไม่มี `x=` หรือ `y=` ที่องค์ประกอบราก | BIMI Group |
| ใบรับรอง | Gmail ต้องใช้ VMC (มีเครื่องหมายการค้าจดทะเบียน และแสดงเครื่องหมายถูก) หรือ CMC (ไม่มีเครื่องหมายการค้า และไม่แสดงเครื่องหมายถูก) | Google |

[ร่างมาตรฐาน BIMI](https://datatracker.ietf.org/doc/draft-brand-indicators-for-message-identification/) อยู่ที่ฉบับแก้ไขที่ 14 (พฤษภาคม 2026) และยังเป็น Internet-Draft ที่เขียนอิง RFC 7489 จึงยังพูดถึง `pct` อยู่ ให้ละ `pct` ไว้ และอย่าตั้ง `t=y`

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

[แนวทางเรื่อง SVG ของ BIMI Group](https://bimigroup.org/creating-bimi-svg-logo-files/) แนะนำให้ใช้โลโก้ทรงจัตุรัส จัดกึ่งกลาง บนพื้นหลังสีทึบ และมีขนาดต่ำกว่า 32 KB ส่วน Google [เพิ่มการรองรับ CMC เมื่อเดือนกันยายน 2024](https://workspaceupdates.googleblog.com/2024/09/gmail-additional-bimi-protections.html) และนี่คือระเบียนตาม[คู่มือการใช้งานของ BIMI Group](https://bimigroup.org/implementation-guide/):

```dns
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

| | Gmail | Yahoo | Outlook.com |
|---|---|---|---|
| เกณฑ์ | ราว 5,000 ฉบับต่อวันไปยังบัญชี Gmail ส่วนตัว นับต่อโดเมนหลัก และเป็นสถานะถาวรเมื่อถึงเกณฑ์แล้ว | ผู้ส่งอีเมลปริมาณมาก ไม่ระบุตัวเลข | มากกว่า 5,000 ฉบับต่อวันไปยัง outlook.com, hotmail.com และ live.com นับต่อโดเมนใน From |
| SPF และ DKIM | ต้องมีทั้งคู่ | ต้องมีทั้งคู่ | ต้องผ่านทั้งคู่ |
| DMARC | ต้องมีระเบียน และยอมรับ `p=none` | อย่างน้อย `p=none` และแนะนำอย่างยิ่งให้มี `rua` | อย่างน้อย `p=none` |
| Alignment | SPF หรือ DKIM | SPF หรือ DKIM โดยใช้แบบ relaxed ได้ | SPF หรือ DKIM |
| เมื่อไม่ผ่าน | การปฏิเสธชั่วคราวและการปฏิเสธถาวร ตั้งแต่พฤศจิกายน 2025 | ไม่ได้ระบุ | `550 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level.` |

แหล่งที่มา: [แนวทางสำหรับผู้ส่งของ Google](https://support.google.com/mail/answer/81126) และ[หน้าคำถามที่พบบ่อย](https://support.google.com/mail/answer/14229414), [แนวทางปฏิบัติที่ดีสำหรับผู้ส่งของ Yahoo](https://senders.yahooinc.com/best-practices/) รวมถึง[ประกาศเมื่อเดือนเมษายน 2025](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%e2%80%99s-new-requirements-for-high%e2%80%90volume-senders/4399730) และ[หน้าช่วยเหลือเรื่อง 5.7.515](https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com) ของ Microsoft โดย Microsoft เริ่มบังคับใช้เมื่อวันที่ 5 พฤษภาคม 2025 หลังการอัปเดตเมื่อวันที่ 29 เมษายนเปลี่ยนการดำเนินการจากการย้ายเข้าโฟลเดอร์อีเมลขยะเป็นการปฏิเสธ

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

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

[การตั้งค่าโดเมน](https://docs.brew.new/get-started/verify-your-sending-domain)ของ 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 ที่เหมาะสมให้:

```dns
; 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 เฉพาะเมื่อยังไม่มีระเบียนอยู่ จึงไม่สร้างระเบียนซ้ำ การตรวจจะทำที่โดเมนผู้ส่ง ไม่ใช่โดเมนแม่ ดังนั้นให้ซับโดเมนสำหรับส่งอีเมลแต่ละรายการมีระเบียนของตัวเอง รวมถึงซับโดเมนสำหรับ[อีเมลธุรกรรม](/th/blog/transactional-emails)หากคุณแยกทั้งสองประเภทออกจากกันตามที่เอกสารแนะนำ ส่วนระบบประมวลผล `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](https://bimigroup.org/understanding-bimi-certificate-types/) ระบุว่าผู้ให้บริการบางราย รวมถึง Yahoo และ Fastmail ยังแสดงโลโก้ที่ประกาศเองโดยไม่มีใบรับรองด้วย