DMARC 設定教學：從 p=none 到 reject 的紀錄範例

設定步驟#

1. 1

   先確認 SPF 與 DKIM

   列出所有以你的網域當寄件地址的服務，確認每一個都以你自己的網域通過 SPF 或 DKIM。Google 建議在設定 DMARC 之前，至少提早 48 小時把這兩項設定好 ^S3。

2. 2

   準備接收報告的信箱

   建立一個像 dmarc@ninefold.example 的地址，或使用報告分析服務。報告會以壓縮的 XML 檔寄來 ^S2。

3. 3

   發布監控用的紀錄

   新增一筆 TXT 紀錄，主機名稱填 _dmarc，值填 v=DMARC1; p=none; rua=mailto:dmarc@ninefold.example。政策為 none 時，不會改變信件的處理方式 ^S1。

4. 4

   確認紀錄已生效

   執行 dig +short TXT _dmarc.ninefold.example 或使用 DNS 查詢工具，確認只回傳一筆紀錄，而且以 v=DMARC1 開頭。

5. 5

   閱讀報告

   持續檢查彙總報告，直到所有合法的寄件來源都顯示 SPF 或 DKIM 已對齊。Google 建議至少一週；RFC 9989 建議正式執行前先觀察約一個月 ^S1S3。

6. 6

   改為 quarantine

   把政策改成 p=quarantine，驗證失敗的信會被送進垃圾郵件匣。持續閱讀報告。

7. 7

   改為 reject

   報告維持乾淨一段相近的時間後，把政策改成 p=reject，收件端就會直接拒收驗證失敗的信 ^S1。

開始設定前要準備什麼#

DMARC 本身不做任何驗證。它讀取 SPF 和 DKIM 的結果，確認其中至少一項是以「和寄件人地址對齊的網域」通過 ^S1。如果你的電子報工具用它自己的網域簽章，即使 DKIM 通過，DMARC 仍會失敗。請先處理這一點，否則報告裡會塞滿你自己的信。

以 Ninefold 這樣的小型服飾品牌為例，寄件來源通常包括員工信箱、電商平台寄出的訂單與出貨通知、客服系統，以及寄 EDM 的電子報工具。每一個都需要在 ninefold.example 上設定 SPF 或 DKIM。各筆紀錄的運作方式，請見SPF、DKIM、DMARC 是什麼。

每天寄超過 5,000 封到個人 Gmail 帳戶的寄件者，Gmail 要求必須有 DMARC 紀錄，政策設為 none 也可以 ^S4。Yahoo 同樣要求大量寄件者至少設定 p=none ^S5。發布紀錄只要幾分鐘，不論寄送量多少都值得加上。

DMARC 紀錄的語法#

DMARC 紀錄是一筆發布在你網域 _dmarc 主機上的 TXT 紀錄，由多個以分號隔開的標籤組成。v=DMARC1 必須放在第一個，否則收件端會忽略整筆紀錄 ^S1。網店會用到的標籤如下：

沒有特別理由的話，不必寫 adkim 和 aspf。預設的寬鬆對齊，能讓 mail.ninefold.example 這類子網域簽署的信，和 ninefold.example 的寄件地址對齊 ^S1；Yahoo 也接受寬鬆對齊 ^S5。

各階段的 DMARC 紀錄範例#

以下範例使用 ninefold.example。請換成你自己的網域和報告地址，並發布在主機名稱 _dmarc 下。

監控階段

v=DMARC1; p=none; rua=mailto:dmarc@ninefold.example

隔離階段

v=DMARC1; p=quarantine; rua=mailto:dmarc@ninefold.example

拒收階段

v=DMARC1; p=reject; np=reject; rua=mailto:dmarc@ninefold.example

較舊的教學（包括 Google 的導入說明頁）會用 pct= 只對一定比例的信件執行政策 ^S3。RFC 9989 移除了這個標籤，因為收件端只有在 0 或 100 時才能穩定套用，改以 t=y 作為測試期的做法 ^S1。收件端必須忽略不認得的標籤，所以尚未支援 np 或 t 的收件端會直接略過 ^S1。

rua 報告能告訴你什麼#

會寄送彙總報告的信箱服務商，通常每天針對每個網域寄一份，格式是壓縮的 XML 檔 ^S2。報告會列出用你的網域寄信的 IP 位址、各自寄了多少封、SPF 和 DKIM 的結果、是否對齊，以及收件端如何處理這些信 ^S2。

• 認得、但沒有對齊的來源，是你漏設的寄件服務。到該服務開啟以你網域簽署的 DKIM，或把它加進 SPF。
• 不認得的來源，可能是團隊成員自行註冊的服務，也可能是有人冒用你的網域。正式執行政策前，先在團隊裡問清楚。
• 轉寄的信常常 SPF 失敗、DKIM 通過 ^S1。這是正常現象，也是對齊的 DKIM 最重要的原因之一。

原始的 XML 很難直接閱讀，所以許多網店會把 rua 指向能轉成圖表的報告分析服務。如果該服務使用其他網域，對方必須發布授權紀錄，否則收件端會忽略這個地址 ^S2。這部分通常由報告服務自行設定。

從 p=none 到 quarantine 再到 reject#

順序永遠相同：先監控，再隔離，最後拒收。差別只在每個階段要維持多久。Google 建議 none 階段至少一週 ^S3。RFC 9989 建議 none 至少一個月，quarantine 也維持相近的時間後再改為 reject ^S1。寄件來源少、報告又乾淨的網店，可以比使用十幾套工具的網店推進得快。

每次調整前，先檢查最近一週的報告，看看有沒有你認得卻驗證失敗的來源。如果員工會用店家網域寄信到郵件論壇（mailing list），RFC 9989 不建議設為 p=reject：論壇轉發的信被收件端拒收，會對論壇造成困擾，甚至導致訂閱者被移除 ^S1。這種情況下，停在 quarantine 是合理的選擇。

子網域的 DMARC 設定#

沒有自己紀錄的子網域（例如 news.ninefold.example），會沿用 ninefold.example 的政策。用 sp 為既有子網域設定不同政策，用 np 處理不存在的子網域名稱，後者常被用來冒用品牌 ^S1。

有些網店會用子網域寄 EDM，和員工信件分開。這個子網域可以有自己的 _dmarc 紀錄。RFC 9989 提到的做法是先用 p=quarantine; t=y 測試子網域，再改為 p=reject 並移除測試標記 ^S1。

在 Claude 或 ChatGPT 裡用 Tellnod 設定 DMARC#

Tellnod 是一個 MCP 連接器，讓你在 Claude 或 ChatGPT 裡撰寫、預覽並寄出行銷信。你可以立刻從 Tellnod 共用網域上的地址寄信（例如 hello@yourshop.tellnodmail.com），限制為每檔最多 500 位收件人、每月最多 1,000 封。驗證自有網域後即解除這些限制。

在對話中說：「把 ninefold.example 設為我的寄件網域。」Tellnod 會給你 SPF、DKIM 和 DMARC 紀錄，並替你檢查。如果 DNS 由別人管理，可以請 Tellnod 建立設定連結傳給對方：對方不必註冊帳號，使用支援的服務商時可一鍵新增紀錄，也可以複製紀錄自行設定。網域驗證通過後，你會在對話中及透過 Email 收到通知。如果你已經有 DMARC 紀錄，請只保留一筆，並在收緊政策前確認從 Tellnod 寄出的信已經對齊。

每一檔活動仍會先經過桌機與手機預覽，再出現一張只有你能按下確認的卡片。每一次發送都由你核准。連接 Tellnod 就能從免費方案開始，或到價格頁面比較方案。Gmail 與 Yahoo 的其他要求，請見寄信到達率入門。

常見問題#