Defaults.Exposed › 報告

DMARC 成熟度的六個階段

發布於 2026-07-03 · 更新 2026-07-03

數據截至 2026-06-29 · 方法論 v7。 這是一個由週期性普查支撐的參考模型；每一版都會重新測量同一群體，以便隨時間追蹤這些數字。所有數據均為彙總數據——我們從不發佈任何單個企業的評級。

發佈 DMARC 並不等於受到保護

在 261 百萬個受測域名中，24.89% 發佈了 DMARC 記錄——但只有 10.59% 真正強制執行。 換個說法：在大約 65 百萬個已經開啟 DMARC 之旅的域名裡，57.5% 從未走到能真正攔截任何東西的那一步。 它們發佈了一條記錄，把報告指向了某個地方，然後就停滯了。規模更小的獨立研究也發現了同樣的形態——2026 年的一份行業報告稱，在其考察的約 938,000 個域名中，只有約 9% 在強制執行。

採用率已不再是問題所在。保護才是。而域名之所以停滯，有一個結構性的原因：每個人都在用的那些地圖都止步於半途。 它們結束得太早，而且沒有任何一張把最難的那一步單獨命名。

現有的地圖止步於何處

行業賴以導航的這些模型在它們所處的時代是正確的，值得公允地看待：

• 五階段部署模型由 dmarcian 推廣開來（其創始人正是 DMARC 本身的共同作者），它沿著 部署 → 監控 → 策略收緊 的路徑走——並把達到 p=reject 當作終點。
• RFC 演進路徑——p=none → quarantine → reject——是三個強制執行級別，而不是一個成熟度模型。它對前置條件隻字未提，對之後要做什麼也隻字未提。
• **「爬、走、跑」**是一種民間說法：方向上正確，但結構上空洞。

這三者都有兩個共同的侷限。第一，它們都止步於 p=reject——彷彿強制執行就是終點線。其實不是：標準本身早已向前邁進（DMARCbis——RFC 9989、9990 和 9991——已於 2026 年 5 月發佈，取代了原有的 RFC 7489），而且強制執行對傳輸安全或品牌信任毫無幫助。第二——也是真正讓域名擱淺的那一點——它們沒有一個把「每一個發件方都已核實」列為一個有名字的階段。 平心而論，那些部署指南確實提到了這項工作：dmarcian 的模型把來源識別作為其監控階段內部的一項任務。但一項被埋進某個階段內部的任務，恰恰就會被這樣對待——被當作「監控」的一部分，而不是它本應是的那個獨立成就。看著報告不斷到來感覺像是在進步。但此刻還不是。域名之所以在 p=none 上停留數年，最大的單一原因就是它們能看見自己的郵件，卻還沒有核實清楚這些郵件——所以它們不敢強制執行，唯恐弄壞什麼真實的東西。

一個有用的模型需要給那一步一個自己的名字和自己的退出標準。本模型正是如此。我們稱之為 DMARC 採用成熟度模型——DAMM：六個階段，每個階段一步關鍵動作，還有一個你可以引用的名字。

該模型

階段 1——未受保護。 沒有 DMARC 記錄——或者其底層的 SPF 與 DKIM 不完整。任何人都能以你的域名發送郵件，而且任何地方都沒有在做校驗。關鍵動作： 為你的主郵件配置 SPF 和 DKIM，並確認它們能通過認證且對齊。DMARC 建立在兩者之上；你無法跳過這塊地基。

階段 2——已認證。 SPF 與 DKIM 對你的主郵件流已正確配置並對齊。你的合法郵件能夠證明自己的來源——但沒有任何東西告訴全世界的收件箱：對於那些無法證明來源的郵件該怎麼處理。關鍵動作： 發佈一條 p=none 的 DMARC 記錄，並帶上一個 rua= 報告地址。

階段 3——觀察中。 DMARC 已發佈，彙總報告正在流入，你第一次能看到誰在以你的域名發件。什麼都還沒有被攔截。大多數工具把這個階段稱作「可見性」——我們刻意不這麼叫，因為看到報告和理解報告是兩種不同的成就。關鍵動作： 識別出每一個以你的域名發件的合法來源，並讓每一個都實現對齊。

階段 4——可見性。 每一個合法發件方都已被識別並對齊——那個通訊平臺、那套開票系統、那個 CRM、市場部去年春天註冊的那個東西。你瞭解自己的郵件。一旦強制執行，不會有任何合法郵件被弄壞。這正是舊地圖跳過的那個階段，也是大多數域名永遠翻不過去的那堵牆。關鍵動作： 提升策略——p=none → p=quarantine（DMARCbis 的 t=y 測試模式在這裡能幫上忙）→ p=reject。

階段 5——已強制執行。 p=quarantine 或 p=reject 已經生效，且子域名由一條明確的 sp= 策略覆蓋。認證失敗的郵件現在會在參與其中的接收方那裡被真正隔離或拒收——這些接收方包括所有主流郵箱服務商——因此對你確切域名的直接偽造，在有 DMARC 校驗的地方將不再能投遞到位。關鍵動作： 加上加固層——DMARCbis 的 np= 與樹遍歷（tree-walk）覆蓋、用於傳輸安全的 MTA-STS 與 TLS-RPT，以及如果品牌展示對你重要的話，BIMI。

階段 6——已加固並持續維護。 強制執行加上現代化的技術棧：來自 DMARCbis 的不存在子域名（np=）覆蓋、保障郵件傳輸過程安全的 MTA-STS 與 TLS-RPT、在物有所值處部署的 BIMI——以及至關重要的、對漂移與新發件方的持續監控。這不是一枚徽章；這是一種紀律。新的發件方會出現，服務商會更換 IP，配置會腐化。關鍵動作： 保持在這裡。

無郵件通道。 在整個域名清冊上測量——包括已死亡的域名在內——51.5% 的域名根本不運行任何郵件服務，對它們而言這段旅程坍縮為一步。一個從不發件的域名，應當立即發佈 SPF -all 和 DMARC p=reject：沒有合法郵件需要保護，所以既無需觀察，也沒有牆要翻越。停放的和休眠的品牌域名只需一次 DNS 變更就能直達「已強制執行」——而這樣做還堵住了最常見的冒充攻擊途徑之一。

那堵牆：階段 3 → 4

本模型中其他每一次過渡都是一次 DNS 變更。唯獨這一次是調查性的工作——也正是幾個月光陰葬送之處。

從「觀察中」走到「可見性」，意味著要把你報告中的每一個發件來源都歸因到一個真實的系統：是哪個 ESP、哪個 CRM、哪個區域辦公室的郵件中繼、2023 年某人接上又忘了的哪個 SaaS 工具。這意味著要找出那些無人記錄在案的影子 IT 發件方。這意味著要逐個 ESP 地修復對齊，因為每個平臺都有自己代表你進行認證的方式——其中一些默認就是錯的。

跳過這堵牆，正是 DMARC 落下嚇人名聲的原因。從「觀察中」就直接強制執行——跳過「可見性」——你一定會攔掉某些真實的東西：一批發票郵件、一條密碼重置流程、CEO 的通訊稿。接下來就是驚慌失措地回退到 p=none，內部覆盤，以及每個人都學錯了的那個教訓：「我們試過 DMARC，它把郵件搞壞了。」 大多數 DMARC 恐怖故事恰恰就是這樣——早了一個階段就嘗試強制執行。這堵牆不是停留在階段 3 的理由。它正是階段 4 存在的理由。

這也是域名所有者最常尋求外援的階段——一家 IT 服務商或一項 DMARC 監控服務可以完成發件方識別的工作；無論走哪條路，這些階段都保持不變。

人人都忘記的那部分：階段 5 → 6

達到 p=reject，會在會做校驗的接收方那裡，阻止對你域名 From: 行的直接偽造。這是必要的——但並不充分。同樣值得點明的是強制執行從未覆蓋過什麼：仿冒域名（yourc0mpany.com）和顯示名冒充完全在 DMARC 的觸及範圍之外，所以強制執行關上了確切域名這扇門，卻把相鄰的那些門留給了警覺與其他控制手段。

強制執行對傳輸毫無作用：沒有 MTA-STS 與 TLS-RPT，發往你域名的郵件在傳輸途中仍可能被降級或截獲。它對品牌識別也毫無作用：BIMI——你的徽標，顯示在收件箱裡——是一種信任信號，而非安全控制手段，把它當作信任信號來對待才是誠實的（它還需要一份付費證書，這正是它排在最後而非最前的原因）。而單純的 p=reject 早於 DMARCbis：新 RFC 的 np= 標籤和樹遍歷彌補了較舊部署所留下的不存在子域名缺口。

一個處於 p=reject 卻不具備上述任何一項的域名，能夠抵禦最常見的攻擊，卻對其餘的攻擊毫無準備。這是一個真實存在的區別，也值得擁有自己的階段。

你所處的階段是可測量的

這個模型不只是一張圖——一個域名所處的階段是可以計算的，這正是它區別於掛在牆上的一張海報之處。

階段 3 到階段 6 可以從一個域名自身的 DMARC 報告數據加上其已發佈的記錄中推導出來：哪條策略在生效、報告是否在流動、以及每一個被觀察到的發件方是否對齊。階段 1 和階段 2 則通過一次實時 DNS 檢查來評估，因為此時還不存在報告。兩個方向上各有一個誠實的侷限：階段 4 靠的是隨時間積累的證據來確認——「在足夠多的報告日裡，每一個被觀察到的發件方都對齊」是一個有力的代理指標，但任何報告都無法揭示你尚未接入的那個發件方。而階段 6 的加固層——MTA-STS、TLS-RPT、BIMI——在 DMARC 報告中是不可見的；要看到它，得靠一次 DNS 檢查。一個域名從它的報告來看可能像是「已完成」，卻仍暗藏著一個隱蔽的階段 5 → 6 缺口。這正是我們自己的報告分析所對照測量的模型，連同它的種種阻礙在內。

一個實戰例子

一家中型公司在一個郵件過濾網關背後運行 Microsoft 365。SPF 以 -all 結尾，DKIM 已配置，DMARC 以 p=none 發佈，報告流向一個監控工具。在舊地圖上，這看起來幾乎已經完成。而在這張地圖上，它處於 階段 3——觀察中：困難的搭建工作已經完成，而域名恰恰停滯在那堵牆上——可見，卻未受保護。價值最高的動作是 3 → 4 → 5：確認那些（很可能為數不多的）合法發件方全部對齊，然後分階段提升策略。對於處於這種形態的域名，這通常是數週的關注，而非數月——那堵牆對於從不繪製它的人才最高。

找到你所處的階段

該被淘汰的問題是「我們有沒有 DMARC？」——24.89% 的域名可以回答「有」，而其中 57.5% 仍然可被偽造。更好的問題是 「我們處於哪個階段，通往下一個階段的那一步關鍵動作是什麼？」 今天，互聯網上每一個域名恰好處於這六個階段中的某一個。知道是哪一個，就把一份焦慮變成了一張待辦清單。

常見問題

什麼是 DAMM？ DMARC 採用成熟度模型——就是本頁上的六階段模型：未受保護、已認證、觀察中、可見性、已強制執行、已加固。一個域名所處的階段可以從它的 DNS 和它的 DMARC 報告數據中測量出來，這正是它區別於掛在牆上的一張海報之處。

那麼發佈 p=none 就毫無價值了嗎？ 不——它是階段 3，而階段 3 是承重的：報告正是你在強制執行之前找出每一個發件方的方式。只有當它被當作終點時，才會變成一個問題。參見為什麼 p=none 不是保護。

我能不能直接跳到 p=reject？ 如果你的域名不發送任何郵件——可以，今天就可以，而且你應該這麼做。如果它確實發送郵件——不行：在沒有「可見性」（階段 4）的情況下強制執行，正是合法郵件被弄壞、回退發生的原因。這些階段是安全的路徑，而不是繁文縟節。

要「完成」是不是必須有 BIMI？ 不。BIMI 是階段 6 的品牌展示層，也是模型中最可選的元素——MTA-STS、TLS-RPT 以及 DMARCbis 的 np= 覆蓋才是真正對域名起到實質性加固作用的部分。如果證書成本對你來說並不划算，就跳過它，守住階段 6 的其餘部分。

SPF 和 DKIM 處於什麼位置？ 處於一切的底層——它們是階段 1 → 2，而沒有 DMARC 的 SPF所提供的保護，比大多數所有者所以為的要少。自 2024 年起，主流接收方還直接要求批量發件方進行認證。

查看你自己的域名處於何處

這些階段是群體層面的模式——你的域名恰好處於其中之一，而下一步動作是可知的。你可以私密且免費地檢查，看看在這 34 項檢查中你通過了哪些，以及如何修復沒通過的那些。

檢查你的域名 → · 我們如何為互聯網評級 → · DMARC 支柱頁 → · 僅彙總數據。數據在歐盟境內存儲和處理。