DMARC 執行落差持續存在：2026 年 68.4% 的公司網域缺乏執行機制

DMARC 執行落差持續存在：2026 年 68.4% 的公司網域缺乏執行機制

概述

DMARC 自 2012 年以來一直作為一種免費的 DNS 紀錄存在，用來告知接收郵件的伺服器如何處理未通過驗證的電子郵件。根據 CipherCue 對 67,336 個公司網域進行的 2026 年快照調查，68.4% 的網域要麼沒有 DMARC 紀錄，要麼紀錄設定為 p=none，這意味著它們並未執行隔離（quarantine）或拒絕（rejection）機制。

執行落差詳情

在受檢的 67,336 個網域中，有 30,362 個 (45.1%) 沒有 DMARC 紀錄。在發布了紀錄的 36,974 個網域中，有 15,709 個 (佔有紀錄網域的 42.5%，佔所有網域的 23.3%) 被設定為 p=none。僅有 10,258 個網域 (佔總數 15.2%) 使用 p=quarantine，以及 10,963 個網域 (佔總數 16.3%) 使用 p=reject。因此，46,071 個網域 (佔總數 68.4%) 要麼缺乏紀錄，要麼採用非執行的 p=none 策略。

為何 p=none 持續存在

從 p=none 轉向執行機制的主要障礙在於解讀每日彙總報告 (rua=) 所需的精力。每個啟用了報告功能的網域都會收到一份清單，列出所有聲稱來自該網域的發件來源。為了執行政策，管理員必須逐一判斷每個來源是否為合法發件者。rua= 地址指向大量一次性、通常是雜湊處理過的信箱（例如 ivrejeuw@ag.c1.dmarcian.com、a.8hyzr404@sdmarc.net），這些信箱沒有明確的所有者，使得政策執行變成了一項被邊緣化的研究任務。

誰在進行 DMARC 監控

將 rua= 報告地址與供應商字典進行比對後，在 29 個指定目的地中識別出 8,862 個實體。前幾大目的地為 Brevo (1,297 個實體, 14.6%)、Proofpoint (1,094, 12.3%)、Valimail (1,068, 12.1%) 和 Cloudflare (978, 11.0%)。若僅限於核心產品為 DMARC 監控的供應商，Valimail、DMARC Analyzer、dmarcian、DMARC Advisor、EasyDMARC、Red Sift、PowerDMARC 和 Fortra (Agari) 共同佔據了 3,619 個實體 (佔已識別實體的 40.8%)。

國家層級的差異

該樣本中各國的執行情況有所不同：

  • 波蘭：64.6% 無紀錄，16.3% p=none，11.3% p=quarantine，7.7% p=reject。
  • 荷蘭：51.1% 無紀錄，21.1% p=none，14.2% p=quarantine，13.6% p=reject。
  • 德國：45.7% 無紀錄，26.3% p=none，12.9% p=quarantine，15.0% p=reject。
  • 美國：42.1% 無紀錄，19.0% p=none，16.7% p=quarantine，22.2% p=reject。
  • 義大利：40.9% 無紀錄，36.8% p=none，11.7% p=quarantine，10.5% p=reject。
  • 英國：37.0% 無紀錄，19.2% p=none，18.3% p=quarantine，25.5% p=reject。
  • 西班牙：36.9% 無紀錄，29.5% p=none，18.1% p=quarantine，15.5% p=reject。
  • 法國：43.0% 無紀錄，29.1% p=none，12.8% p=quarantine，15.1% p=reject。 美國和英國的 p=reject 佔比最高 (分別為 22.2% 和 25.5%)，而義大利儘管無紀錄率相對較低，卻擁有最高的 p=none 佔比 (36.8%)。

相關 DNS 控制措施

除了 DMARC，該樣本還顯示：

  • SPF 出現在 48,962 個網域 (72.7%)。
  • DMARC 出現在 36,974 個網域 (54.9%)。
  • BIMI 出現在 1,726 個網域 (2.6%)。
  • MTA-STS 出現在 957 個網域 (1.4%)。
  • DNSSEC 在全鏈驗證下顯示為 0.0%；作者指出這是測量限制，而非聲稱沒有網域配置了 DNSSEC。 在啟用了 SPF 的網域中，52.4% 使用硬失敗 (-all)，43.1% 使用軟失敗 (~all)。

最近的 RFC 變更

2026 年 5 月，IETF 發布了三份取代 RFC 7489 的標準軌跡 RFC：

  • RFC 9989：核心 DMARC 協定 (現為 Standards Track, Proposed Standard)。
  • RFC 9990：彙總報告 (rua=)。
  • RFC 9991：失敗報告 (ruf=)。 對現有紀錄的實際影響微乎其微；v=、p=、sp=、rua=、ruf=、adkim=、aspf= 和 fo= 標籤保留其原意。一項實質性的變更是用 DNS 樹狀遍歷 (DNS tree walk) 取代了用於組織網域發現的 Public Suffix List 查詢，從而消除了對外部列表的依賴。

SOC 2 與 ISO 27001 考量

SOC 2 與 ISO 27001:2022 均未將 DMARC 作為通用的指定控制措施。SOC 2 評估組織選擇的控制措施是否符合信任服務標準 (Trust Services Criteria)；DMARC 可作為電子郵件驗證風險管理的一部分使用，但未被列為範例。ISO 27001:2022 附錄 A 控制措施 5.14 (資訊傳輸) 範圍夠廣，足以涵蓋電子郵件驗證，而無需特別提及 DMARC。

範例網域

Cranswick (cranswick.co.uk) 發布了一個 p=none 的 DMARC 紀錄，包含三個 rua= 地址：dmarc_agg@vali.email、一個在 eu.cp-dmarc.com 自行註冊的信箱，以及一個在 rua.easydmarc.eu 的雜湊地址。這說明了單一網域如何從多個不相關的目的地彙整報告，這要求管理員在轉向執行機制之前必須先整合這些數據流。

方法論說明

數據來自 CipherCue 自身的 DNS 觀察結果（針對 DMARC、SPF、MTA-STS、BIMI、DNSSEC 的直接查詢），執行於 2026-04-14 至 2026-07-28 之間，涵蓋 67,336 個網域。計數單位為網域，而非去重後的組織；如果一家大公司擁有數個網域，可能會出現多次。供應商比對使用的是手動維護的 40 個已知 rua= 報告端點網域字典，這僅是底線而非全面普查。DNSSEC 結果僅反映全鏈驗證。

社群見解 (HN 評論)

評論者強調了幾個實際與認知上的障礙：

  • 一些小型營運商質疑，當 SPF 和 DKIM 對他們已經有效時，DMARC 能帶來什麼額外價值。
  • 其他人指出，DNS 變更通常是由對技術理解有限的員工進行，導致配置僅停留在 p=none 的複製貼上狀態。
  • 少數人認為主要的電子郵件提供商會忽略濫用報告，降低了 DMARC 的感知效益。
  • 有人建議，沒有電子郵件（或沒有 MX 紀錄）的網域可能會被計入「無紀錄」組別，從而扭曲了統計數據的相關性。
  • 少數評論者聲稱 DMARC 增加了複雜性卻沒有提高收件匣的信任度，因為垃圾郵件通常能通過 SPF/DKIM/DMARC。
  • 相反地，少數用戶描述使用 LLM 來自動化 DNS 變更，包括透過 Terraform 添加 DMARC 紀錄。 這些評論強化了本文的觀點：主要的落差不在於對 DMARC 存在的認知，而是在於從監控轉向執行機制所需的營運工作量。

Sources