# DMARC 設定教學：從 p=none 到 reject 的紀錄範例 > 設定 DMARC 時，先確認每個以你的網域寄信的服務都通過 SPF 和 DKIM，再於 _dmarc.yourdomain 發布一筆 TXT 紀錄，例如 v=DMARC1; p=none; rua=mailto:dmarc@yourdomain，閱讀幾週的每日報告後，再把政策收緊為 quarantine，最後改為 reject。 Canonical: https://tellnod.com/zh-Hant/guides/how-to-set-up-dmarc Last updated: 2026-10-22 Author: Tellnod team ## 設定步驟 1. **先確認 SPF 與 DKIM.** 列出所有以你的網域當寄件地址的服務，確認每一個都以你自己的網域通過 [SPF](https://tellnod.com/glossary#spf) 或 [DKIM](https://tellnod.com/glossary#dkim)。Google 建議在設定 DMARC 之前，至少提早 48 小時把這兩項設定好 [S3]。 2. **準備接收報告的信箱.** 建立一個像 dmarc@ninefold.example 的地址，或使用報告分析服務。報告會以壓縮的 XML 檔寄來 [S2]。 3. **發布監控用的紀錄.** 新增一筆 TXT 紀錄，主機名稱填 `_dmarc`，值填 `v=DMARC1; p=none; rua=mailto:dmarc@ninefold.example`。政策為 none 時，不會改變信件的處理方式 [S1]。 4. **確認紀錄已生效.** 執行 `dig +short TXT _dmarc.ninefold.example` 或使用 DNS 查詢工具，確認只回傳一筆紀錄，而且以 v=DMARC1 開頭。 5. **閱讀報告.** 持續檢查彙總報告，直到所有合法的寄件來源都顯示 SPF 或 DKIM 已對齊。Google 建議至少一週；RFC 9989 建議正式執行前先觀察約一個月 [S1][S3]。 6. **改為 quarantine.** 把政策改成 `p=quarantine`，驗證失敗的信會被送進垃圾郵件匣。持續閱讀報告。 7. **改為 reject.** 報告維持乾淨一段相近的時間後，把政策改成 `p=reject`，收件端就會直接拒收驗證失敗的信 [S1]。 ## 開始設定前要準備什麼 [DMARC](https://tellnod.com/glossary#dmarc) 本身不做任何驗證。它讀取 SPF 和 DKIM 的結果，確認其中至少一項是以「和寄件人地址對齊的網域」通過 [S1]。如果你的電子報工具用它自己的網域簽章，即使 DKIM 通過，DMARC 仍會失敗。請先處理這一點，否則報告裡會塞滿你自己的信。 以 Ninefold 這樣的小型服飾品牌為例，寄件來源通常包括員工信箱、電商平台寄出的訂單與出貨通知、客服系統，以及寄 EDM 的電子報工具。每一個都需要在 ninefold.example 上設定 SPF 或 DKIM。各筆紀錄的運作方式，請見[SPF、DKIM、DMARC 是什麼](https://tellnod.com/zh-Hant/guides/spf-dkim-dmarc-explained)。 > 每天寄超過 5,000 封到個人 Gmail 帳戶的寄件者，Gmail 要求必須有 DMARC 紀錄，政策設為 none 也可以 [S4]。Yahoo 同樣要求大量寄件者至少設定 p=none [S5]。發布紀錄只要幾分鐘，不論寄送量多少都值得加上。 ## DMARC 紀錄的語法 DMARC 紀錄是一筆發布在你網域 `_dmarc` 主機上的 TXT 紀錄，由多個以分號隔開的標籤組成。`v=DMARC1` 必須放在第一個，否則收件端會忽略整筆紀錄 [S1]。網店會用到的標籤如下： | 標籤 | 範例 | 作用 | | --- | --- | --- | | v | v=DMARC1 | 版本，必須是第一個標籤 | | p | p=none | 網域的政策：none、quarantine 或 reject | | rua | rua=mailto:dmarc@ninefold.example | 每日彙總報告的寄送地址 | | sp | sp=reject | 既有子網域的政策（與 p 不同時才需要） | | np | np=reject | 不存在的子網域的政策 | | adkim / aspf | adkim=r | DKIM 與 SPF 的對齊方式：寬鬆（預設）或嚴格 | | t | t=y | 測試模式：請收件端套用比所列政策低一級的處理 | 沒有特別理由的話，不必寫 `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]。寄件來源少、報告又乾淨的網店，可以比使用十幾套工具的網店推進得快。 | 政策 | 驗證失敗的信 | 適用時機 | | --- | --- | --- | | p=none | 照常投遞，只產生報告 | 還在找出所有寄件來源時 | | p=quarantine | 視為可疑，通常進垃圾郵件匣 | 報告顯示所有寄件來源都已對齊時 | | p=reject | 收件端直接拒收 | quarantine 階段乾淨地維持一段時間後 | 每次調整前，先檢查最近一週的報告，看看有沒有你認得卻驗證失敗的來源。如果員工會用店家網域寄信到郵件論壇（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 連接器](https://tellnod.com/glossary#mcp-connector)，讓你在 Claude 或 ChatGPT 裡撰寫、預覽並寄出行銷信。你可以立刻從 Tellnod 共用網域上的地址寄信（例如 hello@yourshop.tellnodmail.com），限制為每檔最多 500 位收件人、每月最多 1,000 封。驗證自有網域後即解除這些限制。 在對話中說：「把 ninefold.example 設為我的寄件網域。」Tellnod 會給你 SPF、DKIM 和 DMARC 紀錄，並替你檢查。如果 DNS 由別人管理，可以請 Tellnod 建立設定連結傳給對方：對方不必註冊帳號，使用支援的服務商時可一鍵新增紀錄，也可以複製紀錄自行設定。網域驗證通過後，你會在對話中及透過 Email 收到通知。如果你已經有 DMARC 紀錄，請只保留一筆，並在收緊政策前確認從 Tellnod 寄出的信已經對齊。 每一檔活動仍會先經過桌機與手機預覽，再出現一張只有你能按下確認的卡片。每一次發送都由你核准。[連接 Tellnod](https://tellnod.com/zh-Hant/connect) 就能從免費方案開始，或到[價格頁面](https://tellnod.com/zh-Hant/pricing)比較方案。Gmail 與 Yahoo 的其他要求，請見[寄信到達率入門](https://tellnod.com/guides/email-deliverability-basics)。 ## FAQ ### 第一次設定 DMARC，紀錄該怎麼寫？ 從 v=DMARC1; p=none; rua=mailto: 加上一個你會去看的信箱地址開始。它完全不影響投遞，並會開始寄送每日報告 [S1]。 ### p=none 就符合 Gmail 和 Yahoo 的要求嗎？ 就大量寄件者的規定來說，是的。只要寄件網域和 SPF 或 DKIM 對齊，兩家都接受 none 政策 [S4][S5]。之後再執行更嚴格的政策，可以進一步防止網域被冒用。 ### p=none 要維持多久？ 直到報告顯示所有合法的寄件來源都已對齊。Google 建議至少一週，RFC 9989 則建議正式執行前觀察約一個月 [S1][S3]。 ### 可以有兩筆 DMARC 紀錄嗎？ 不行。_dmarc 上只能發布一筆 TXT 紀錄。查詢時若回傳超過一筆 DMARC 紀錄，收件端會全部捨棄，所以請合併成一筆 [S1]。 ### DMARC 紀錄要設在主網域還是子網域？ 設在寄件地址所用網域的 _dmarc 主機上。主網域上的紀錄也會透過 p、sp 或 np 標籤，涵蓋沒有自己紀錄的子網域 [S1]。 ## Sources - [S1] RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC): (checked 2026-10-22) - [S2] RFC 9990: DMARC aggregate reporting: (checked 2026-10-22) - [S3] Google Workspace Admin Help: Recommended DMARC rollout: (checked 2026-10-22) - [S4] Google Workspace Admin Help: Email sender guidelines: (checked 2026-10-22) - [S5] Yahoo Sender Hub: Sender best practices: (checked 2026-10-22)