盲目發佈：大多數 DMARC 記錄不索取任何報告

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

數據截至 2026-06-29 · 方法論 v7。 普查覆蓋了每一個發佈可解析 DMARC 記錄的域名，並按域名去重。rua= 的存在情況是在所有記錄中測量的，因此它與任何單一策略的確切重疊無法推導出來——本文在提及此類重疊時，只會給出上下界，絕不給出確切的交叉列表。所有數據均為彙總數據——我們從不發佈任何單個企業的評級。

大多數 DMARC 記錄並沒有在觀察

在發佈了 DMARC 記錄的 65 百萬個域名中，只有 23 百萬個——即 35.7%——包含索取彙總報告的 rua= 標籤。其餘 64.3% 都在盲目發佈： 記錄上有一條策略，但沒有人要求被告知在這條策略下正在發生什麼。這就意味著有 42 百萬個域名的 DMARC 記錄無法向它們展示任何信息。

一條沒有報告的 DMARC 記錄就像一個無人應答的門鈴。郵件接收方盡職地拿每一封郵件與之核對——而它們的發現，也就是所有以你的域名發信者的名單，卻無處可去。機制在運轉；只是所有者沒有在聽。

`rua=` 實際上做了什麼

DMARC 有兩個部分。策略部分（p=none、quarantine 或 reject）告訴接收方如何處理未通過身份驗證的郵件。報告部分——rua= 標籤，即一個郵箱地址——請求接收方每天向你發送彙總報告：哪些服務器以你的域名發信、發了多少郵件，以及郵件是否通過了 SPF 和 DKIM。

第二個部分就是整個反饋閉環。報告讓你發現那個沒人記錄過的郵件列表平臺、市場部接入的那個開票工具、以及另一個地區的影子發信方——在你實施強制策略並把它們弄壞之前。沒有 rua=，這些情報都無法送達你手中。添加它只需一次 DNS 修改：在現有記錄後追加 rua=mailto:[email protected]（或某個監控服務的地址）。

第 2 階段和第 3 階段之間的鴻溝：已發佈卻盲目

在 DMARC 成熟度的六個階段中，第 3 階段——觀察——始於 DMARC 已發佈且彙總報告開始流入之時。一條沒有 rua= 的記錄並不達標。它處於第 2 階段和第 3 階段之間的鴻溝裡——已發佈卻盲目——這是該模型有意留白、不賦予其自身編號的位置。

這一點很重要，因為其後的每個階段都依賴於報告。你無法從從未收到的報告中識別出你的發信方（第 4 階段）；你也無法在不瞭解發信方的情況下安全地實施強制策略（第 5 階段）。一條盲目的記錄不是這段旅程上的早期一步——它是緊挨著旅程旁邊的一處停靠帶。而普查表明，大多數記錄持有者都停在那裡或附近：所有 DMARC 記錄中有 57.5% 從未達到強制策略。

比毫無用處更糟，因為它讓人感覺像是進展

一條缺失的 DMARC 記錄至少看起來就是它本來的樣子：一個空缺。而一條盲目的記錄看起來像是打了一個勾。有人跑了一遍合規清單、或一份可送達性指南、或某個供應商給的一行修復——發佈了 v=DMARC1; p=none——掃描器就變綠了。這個組織現在感覺比那個根本沒有記錄的組織走得更遠，而實際上處在同樣的境地：沒有可見性、沒有強制策略、也沒有通往任何一者的路徑。

後果是無聲而累積的。盲目的記錄不會大聲報錯；它們只是永遠不會產生那些能為下一步提供依據的證據。多年之後，記錄仍然寫著 p=none，沒有人能說清哪些發信方是合法的，而實施強制策略比以往任何時候都更讓人覺得有風險——恰恰是因為從未收集過任何報告。

普查能說什麼、不能說什麼

由於 rua= 的存在情況是在全部 65 百萬條記錄中測量的——而非按策略交叉列表——因此從這些邊際數據中無法推導出既是 p=none 又是盲目的記錄的確切數量。但上下界依然觸目驚心。37 百萬條記錄（佔記錄持有者的 57.4%）停在 p=none；而整個普查中只有 23 百萬條記錄索取報告。因此這些 p=none 記錄中最多隻有 23 百萬條能夠收到報告——而其中至少 14 百萬條肯定沒有收到，即便普查中的每一個報告地址都屬於某個 p=none 域名也是如此。無論重疊實際上落在何處，都有數百萬個域名停在”監控模式”，而監控器卻被拔掉了插頭。

一次修改即可解決

如果你的 DMARC 記錄沒有 rua= 標籤，修復方法只需一次 DNS 更改，而且在任何策略級別都是安全的：

選擇一個報告目的地——一個你真的會去處理的郵箱，或者一個免費/付費的 DMARC 監控服務，它會把 XML 轉換成可讀的內容。
將它追加到記錄中： v=DMARC1; p=none; rua=mailto:[email protected]。如果目的地是另一個域名，該域名必須授權接收你的報告（在它那一側添加一條小小的額外 DNS 記錄）。
等待幾天，然後閱讀。 主要接收方每天都會發來報告。它們所展示的內容——每一個以你的域名發信的來源——就是這段旅程後續的地圖。

然後這條記錄就不再是擺設，而開始成為一件儀器。（修復 DMARC →。）

常見問題

什麼是 DMARC rua 報告？ 這是一份彙總的 XML 報告，由參與的郵件接收方（通常每天）發送到你記錄中 rua= 標籤所指定的地址，概述哪些來源以你的域名發信，以及郵件是否通過了 SPF 和 DKIM 對齊。它不包含任何郵件內容——只有發信方基礎設施和通過/未通過的計數。

沒有 rua 的 DMARC 是否毫無價值？ 並非毫無價值——即使沒有它，一條強制策略仍能阻止仿冒。但在 p=none 下，一條沒有 rua= 的記錄既不阻止任何東西，也不向你展示任何東西——它唯一剩下的作用就是勾上郵箱服務商的最低要求那一欄。而且即便是實施強制策略卻沒有報告的域名，也會失去那種在新發信方出現時保持強制策略安全的漂移檢測能力。無論如何，p=none 不是保護——沒有報告，它甚至稱不上是準備。

rua= 可以指向任何郵箱嗎？ 可以，包括位於另一個域名上的郵箱——大多數監控服務正是以這種方式工作的。接收域名會發布一條小小的驗證記錄來授權你的報告。真正重要的是，確實有某個東西在處理這些 XML；一個沒人閱讀的郵箱只是多繞了幾步的盲目。

彙總報告會暴露私密數據嗎？ 不會。rua 彙總報告攜帶的是發信來源和身份驗證統計信息，而非郵件正文或收件人名單。（單獨的 ruf= 失敗報告可能包含郵件片段，這也是為什麼許多接收方不再發送它們——rua 才是重要的那個。）

檢查你的記錄是否在觀察

一條不索取任何報告的 DMARC 記錄，是整段旅程中最容易修復的發現之一——一次 DNS 修改就能把盲目變為觀察。你可以私密且免費地進行檢查，看看在 34 項檢查中你通過了哪些，以及如何修復那些沒通過的。

檢查你的域名 → · DMARC 成熟度的六個階段 → · DMARC 支柱 → · 僅彙總數據。數據在歐盟境內存儲與處理。