Defaults.Exposed › 修復 › Guides

從 p=none 到 p=reject 且不誤伤合法郵件：分階段上線方案（2026）

發布於 2026-07-08

資料截至 2026-06-29 · 方法論 v7。 基於 261 百萬個已評分網域的彙總普查資料。參見我們如何評分。

把 DMARC 從 p=none 推進到 p=reject 分四個階段：監控 rua 報告 2–4 周、修復每一個合法發件方、用 pct 逐步提高 p=quarantine，最後拒收——永遠不要一步跳到 reject。根據 Defaults.Exposed 普查，261,086,232 個已評分網域中有 70,368,600 個卡在軟性 SPF、且沒有 DMARC 強制執行的階段。

以下是操作層面的執行手冊：一張帶退出標準的階段表、每個階段該發布的記錄、會改變“50%”實際含義的 RFC 7489 pct 細節，以及面向子網域的 sp= 標簽。如果你還在決定要不要強制執行，先讀 DMARC 成熟度的 6 個階段——那是框架；如果連政策級別本身你都還不熟，p=none、p=quarantine 和 p=reject 到底是什麼意思 是入門讀物。這一頁讲的是怎麼做。

為什麼不能直接跳到 p=reject？

因為 p=reject 會讓每個遵守規則的接收方退回 DMARC 失敗的郵件——而在你看過報告之前，你根本不知道哪些會失敗。几乎每個開啟監控的網域都會發現自己忘記的合法發件方：CRM、開票工具、聯繫表單。第一天就跳到 reject，這些郵件不會進垃圾箱——它們會在 SMTP 階段直接消失。丢一次發票郵件就足以讓整個組織從此害怕 DMARC，記錄隨即被永久回滚到 p=none——在 261,086,232 個已評分網域中，恰好有 37,312,637 個停在這一步，只有 10.59%（27,640,987 個）最終達到強制執行的政策。

另一個原因是對齊。DMARC 只有在 SPF 或 DKIM 通過並且與可見的 From 網域對齊時才算通過——SPF 對齊的是 Return-Path（RFC5321.MailFrom）網域，DKIM 對齊的是簽名裡的 d=。第三方發件方通常在自己的網域上通過 SPF，而不是你的網域，這就是為什麼“修復每個來源”這一階段主要是在為每個服務商啟用自定義網域 DKIM——詳細拆解見 DMARC 失敗但 SPF 和 DKIM 都通過。

上線的四個階段是什麼？

資料截至 2026-06-29；政策行為依據 RFC 7489。

階段 3 是網域最容易卡住或慌乱的地方。進垃圾箱是可以補救的——使用者能把郵件找出來，你調低 pct，修好來源。拒收則无法補救，這就是為什麼“在 pct=100 下干淨執行”是進入階段 4 的入場券。

具體該怎麼一步步上線？

1. 動 DNS 之前，先在 defaults.exposed 執行免費掃描。 它會確認你當前的政策，以及底層是否已具備 SPF 和 DKIM——強制執行正是立在這兩條腿上的。
2. 如果還沒開，先開啟監控。 發布帶 rua= 的 p=none 是 “DMARC 政策未啟用” 裡那個五分鐘步驟。收集 2–4 周的報告——足夠捕捉到像開票這類按月出現的發件方。
3. 盘點報告中的每個來源。 把發件方分為你自己的、你的服務商的和未知的。原始報告是 XML 附件——用報告解析工具（或你服務商的儀表盘）把它們轉成可讀的發件方清單。
4. 讓每個合法來源都對齊通過。 為每個服務商啟用自定義網域 DKIM（通常是在其後台新增兩條 CNAME 記錄），讓簽名帶上你的網域而不是它們的網域。优先用 DKIM 來對齊：它能扛住轉發，而SPF 不能。
5. 等到連續兩周干淨為止。 只有當報告裡的失敗全部是你不認識的流量——也就是你想拦截的偽造流量——才算完成階段 2，可以退出。
6. 切換到 p=quarantine; pct=10——編輯現有的 _dmarc TXT 記錄（實操示例：IONOS DMARC 設定），並留意語法：政策標簽裡的一個拼寫錯誤就可能讓整條記錄作廢。在 2–4 周內把 pct 逐步提高到 25、50、100，同時關注報告和服務台工單。任何進了垃圾箱的合法郵件：把 pct 調回去，修好來源，再繼續。
7. 在 pct=100 干淨執行 1–2 周後，切換到 p=reject。 永久保留 rua=——公司以後採用的每一個新工具都可能是未來的一個失敗發件方。

pct 到底做了什麼？RFC 7489 裡的細節

pct 要求接收方把你的政策應用到該百分比的失敗郵件上。細節在 RFC 7489 §6.6.4：被抽樣排除的郵件不會回落到“照常送達”——而是會被套用低一級的政策。在 p=quarantine; pct=25 下，另外 75% 按 p=none 處理並照常送達。但在 p=reject; pct=50 下，另外 50% 會被隔离，而不是送達。沒有“温和版拒收”這回事：一旦你的記錄寫著 reject，所有失敗郵件在遵守規則的接收方那裡至少會被丢進垃圾箱。

刻意使用的話，這反而是個特性——p=reject; pct=1 相當於“几乎全部隔离，只拒收一小撮”，是一種合理的最終過渡方式。有兩點要留意：接收方對抽樣的實作並不完全一致，所以把 pct 當成一個粗略的旋钮就好；等階段 4 稳定之後，記得去掉這個標簽（或設為 pct=100），讓你的記錄名副其實。

子網域怎麼辦——sp= 標簽

默認情况下，子網域繼承組織網域的政策：yourdomain.com 上的 p=reject 也覆蓋 mail.yourdomain.com。sp= 標簽可以讓子網域走不同的路，既有用也有風險。有用的一面：p=quarantine; sp=reject 可以在主網域還在逐步提高階段時，就先鎖死那些你從不用來發信的子網域——偽造者會刻意瞄準被監控網域的子網域下手。危險的一面：一個被遗忘的 sp=none 會悄无聲息地把每個子網域都排除在你花了六周才贏得的拒收政策之外。到階段 4 時檢查一下這個標簽；如果確實有某個子網域需要更寬松的政策，就單獨為那個子網域發布一條 _dmarc 記錄，而不是把所有子網域都放寬。

NIS2 是否意味著歐盟企業必須這麼做？

DMARC 在哪裡都一樣運作——跨過歐盟邊境，這份執行手冊裡的任何內容都不會改變。改變的是合規上的推動力。NIS2 第 21(2)(j) 條要求受監管實體保障其通信安全，而歐盟委員會實施法規 (EU) 2024/2690 為其覆蓋的數字基礎設施實體明確了技术要求——其附件（第 6.7.2(k) 點）要求制定實施計劃，部署國際公認的現代郵件安全標準，第 6.7.2(l) 點要求遵循 DNS 安全最佳實践。一個底層具備 SPF 和 DKIM、且強制執行的 DMARC 政策，是防範偽造的公認可審計控制措施；p=none 明顯只是在監控，谈不上安全防護。如果你的客戶在此監管範圍內，他們的供應商安全問卷會越來越明確地要求這一點。

常見問題

整個上線過程要花多久？ 通常是六到十周：監控 2–4 周，修復來源 1–3 周，提高 quarantine 比例 2–4 周，然後拒收。這是日歷時間，不是工作量——大部分時間都在等報告確認每一步改動是否生效。截至 2026-06-29，261,086,232 個已評分網域中有 89.41% 沒有強制執行的政策，其中大多數並不是還在上線過程中——它們根本沒開始計時。

能不能跳過 quarantine，直接用低 pct 的 p=reject？ 可以——根據 RFC 7489 §6.6.4，p=reject; pct=10 意味著 10% 被拒收、90% 被隔离，大致相當於階段 3 後期。但先用 p=quarantine 更容易推理判斷，而且不同接收方對抽樣的執行程度參差不齊。无論走哪條路，階段 1–2 都沒有商量余地：只要還有合法發件方在失敗，任何一種強制執行方式都不安全。

那些我修不了的郵件呢——轉發和郵件列表？ 轉發天生就會破壞 SPF，一些郵件列表還會改寫內容，連 DKIM 也一起破壞。對齊的 DKIM 能扛住普通轉發，這解決了大部分問題；剩下的少量殘余正是 quarantine 階段存在的意義——進了垃圾箱的郵件在你評估期間是可以補救的。详見轉發郵件 SPF 失敗。

停在 p=quarantine 夠不夠？ 這已經拿到了大部分價值，也遠好過停在 p=none 的那 37,312,637 個網域（在 261,086,232 個已評分網域中，資料截至 2026-06-29）——但被偽造的郵件仍會進垃圾箱，而人們會把它捞出來。拒收才是終點：已評分網域中只有 10.59% 真正強制執行，檢測工具、保險公司和問卷認可的正是走完全程。

把報告發給老板

如果你是在替客戶或雇主推進這次上線，終點是可以展示出來的。p=reject 生效後重新執行免費掃描，把評分報告轉發出去：網域遷移到強制執行政策，帶日期、用大白話寫清楚。這一頁比 DNS 面板的截圖更能回答網路保險續保和 NIS2 驅動的供應商問卷裡那道郵件安全題——也讓六周細致、看不見的工作，在買單的人面前變得看得見。

免費檢查你的 DMARC 政策

私密、僅網域所有者可見地看看你目前的政策是什麼——以及 SPF 和 DKIM 能不能撑起強制執行。

檢查你的網域 → · 修復 DMARC → · “DMARC 政策未啟用”——誠實的第一步 → · 僅使用彙總資料。資料在歐盟境內儲存和處理。