Defaults.Exposed › 修復 › Guides

DKIM 通過但 DMARC 失敗：gappssmtp.com / onmicrosoft.com 默認簽名陷阱（2026）

發布於 2026-07-08

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

你的郵件用服務商的默認簽名通過了 DKIM——d= 以 gappssmtp.com（Google Workspace）或 onmicrosoft.com（Microsoft 365）結尾——但該網域與你的 From 網域不匹配，所以 DMARC 拿不到對齊的通過。啟用自定義網域簽名即可修復。根據 Defaults.Exposed 對 261,086,232 個已評分網域的普查，在授權 Google 郵件伺服器的 12,145,313 個網域中，只有 18.5% 強制執行 DMARC。

這是郵件驗證裡最干脆利落的修復之一：打開自定義網域 DKIM 簽名。在 Google Workspace 是管理控制台的 “Authenticate email” 頁面——生成金鑰、發布一條 TXT 記錄、啟用。在 Microsoft 365 是 Defender 門戶的 DKIM 頁面——發布兩條選擇器 CNAME、啟用。二十分鐘的活兒，DMARC 就終於等到了它一直缺的那個對齊通過。

為什麼 DKIM 通過但 DMARC 依然失敗？

因為 DMARC 問的不是”有沒有一個有效的 DKIM 簽名？“——它問的是”有沒有一個為 From 標头中那個網域簽的有效 DKIM 簽名？“第二個條件叫對齊（alignment），也是 DMARC 的全部意義所在：證明收件人看見的網域就是簽名的網域。

在默認狀態下，Google Workspace 用類似 yourdomain-com.20230601.gappssmtp.com 的網域給你的郵件簽名（日期戳因網域而异），Microsoft 365 則用 yourtenant.onmicrosoft.com 簽名。這兩個簽名在密碼學上都是有效的——DKIM 檢查工具都說通過——但 d= 網域屬於 Google 或 Microsoft，不屬於你。即便按 DMARC 的寬松對齊規則——只要求組織網域匹配——gappssmtp.com 也不是 yourdomain.com。不匹配就沒有對齊通過；如果 SPF 也沒對齊（它經常做不到——接收方是拿 Return-Path 網域評估 SPF 的，不是 From 標头，而且轉發會把它彻底弄壞），DMARC 就失敗了。

這就是服務商默認設定最典型的陷阱：**默認設定給你的是投遞能力，不是保護——對齊才是那把沒拧到底的鑰匙。**普查資料顯示有多少發件方止步於默認設定：在通過 _spf.google.com 授權 Google 郵件伺服器的 12,145,313 個網域中（全球共 138,927,207 個 SPF 發布者），只有 18.5% 強制執行 DMARC。Microsoft 這邊的圖景形狀相同：10,205,070 個網域授權 spf.protection.outlook.com，85.0% 保留著 M365 設定時給出的嚴格 SPF 記錄——却只有 21.7% 強制執行 DMARC。完整對比見我們的郵件服務商 SPF 排行榜。

這個陷阱在日常使用中完全隱形：郵件照常投遞，收件箱測試一切正常，什麼都不報錯——直到你發布一條 DMARC 政策，然後你自己的郵件開始過不了它。我們的免費掃描恰好能揭露這個缺口。

如何在 Authentication-Results 裡識別默認簽名陷阱？

打開一封你發出的郵件（發到 Gmail 或 Outlook 郵箱），查看原始源碼，找到 Authentication-Results 標头。破绽是一個 DKIM 通過却帶著錯的 d=——Gmail 接收側的例子長這樣：

Authentication-Results: mx.google.com;
       dkim=pass [email protected];
       spf=pass smtp.mailfrom=yourdomain.com;
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=yourdomain.com

把它當三個問題來讀：

在 Microsoft 接收的郵件上，同樣的故事表現為 dkim=pass (signature was verified) header.d=yourtenant.onmicrosoft.com 伴隨 compauth=fail——這一模式在 Outlook 拒收指南裡有讲解。

如果你的標头反而顯示 dkim=pass 和 spf=pass 双双通過却 DMARC 失敗，那你屬於更寬泛的對齊問題——DMARC 失敗但 SPF 和 DKIM 都通過指南完整讲解了寬松與嚴格對齊。

如何啟用自定義網域 DKIM 簽名？

1. 動手之前，先在 defaults.exposed 執行免費掃描。 它會顯示你的網域是否有對齊的 DKIM、你的 DMARC 政策實際是什麼，以及這項修復之後是否還有別的東西（SPF、DMARC 記錄語法）會拦住你——這樣一次就把整件事做完。
2. 確認你在用哪個默認簽名。 按上文查看 Authentication-Results 裡的 header.d=：gappssmtp.com 是 Google Workspace 默認，onmicrosoft.com 是 Microsoft 365 默認。
3. Google Workspace：生成並發布你自己的金鑰。 在管理控制台進入 Apps → Google Workspace → Gmail → Authenticate email，選擇你的網域並點擊 Generate New Record（除非你的 DNS 主機存不下，否則選 2048 位）。把它給出的 TXT 記錄發布到 google._domainkey.yourdomain.com，等待 DNS 生效（最長 48 小時），然後——大家最常漏掉的一步——點擊 Start authentication。只生成記錄不開啟簽名，什麼都不會發生。完整教程：在 Google Workspace 設定 DKIM。
4. Microsoft 365：發布兩條選擇器 CNAME 並啟用。 在 Defender 門戶進入 Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM，選擇你的自定義網域並建立金鑰。兩條 CNAME 都要發布——selector1._domainkey 和 selector2._domainkey，指向 Microsoft 顯示給你的目標（從門戶原樣復制確切目標——2025 年 5 月之前啟用的網域以你租戶的 .onmicrosoft.com 結尾；更新的以 .dkim.mail.microsoft 結尾）——然後打開簽名開關。兩個選擇器不是可選項：Microsoft 會在兩者之間轮換金鑰。完整教程：在 Microsoft 365 設定 DKIM。
5. 驗證新簽名。 給外部郵箱發一封新郵件，重新檢查 Authentication-Results：dkim=pass 現在應該顯示 header.d=yourdomain.com。如果你的 DNS 面板自動把你的網域追加到了 CNAME 目標後面，或者把很長的 TXT 值弄乱了，簽名就切換不過來——這裡大多數失敗都是面板的怪癖造成的，不是服務商的問題。
6. 重新掃描，讓這個對齊通過發挥作用。 確認掃描顯示 DKIM 已對齊，然後用起來：停在 p=none 的 DMARC 政策保護不了任何東西。在全部 261,086,232 個已評分網域中，只有 10.59% 強制執行 DMARC（資料截至 2026-06-29）——正是對齊的 DKIM 讓逐級收紧變得安全。從如何修復 DMARC 開始。

啟用自定義 DKIM 會弄壞什麼嗎？

不會——這是郵件驗證裡少見的几乎零波及面的修復：原來帶默認簽名發出的郵件，現在帶著更好的簽名發出，金鑰仍由服務商管理（Microsoft 會在兩個選擇器之間自動轮換）。真正的失敗模式是做一半——發布了 Google 的 TXT 却始終沒點 Start authentication，或者只發布了一條 M365 選擇器而不是兩條。另外別在日後為了”清理”而刪掉這些 DNS 記錄；金鑰一消失，簽名立刻停止。

一個範圍說明：這修復的是經由 Google 或 Microsoft 發出的郵件。郵件通讯工具和 CRM 也用它們自己的默認簽名，每一個都需要單獨開啟自定義網域 DKIM——這一模式，連同現在明確提出此要求的 Gmail 大宗發件方規則，都在 550-5.7.26 指南裡讲到。

常見問題

每個測試工具上 DKIM 都顯示”通過”——為什麼還有東西要修？ 因為這些工具回答的問題比 DMARC 問的窄。簽名確實有效——但它是 gappssmtp.com 或 onmicrosoft.com 的，不是你的，所以在 DMARC 對齊中一文不值。這正是那麼多發件方止步於默認設定的原因：在 12,145,313 個授權 Google 的網域中，只有 18.5% 強制執行 DMARC（資料截至 2026-06-29）。

DMARC 的寬松對齊能讓默認簽名通過嗎？ 不能。寬松對齊只是把匹配放寬到組織網域——mail.yourdomain.com 與 yourdomain.com 對齊。而默認簽名的組織網域是 gappssmtp.com 或 onmicrosoft.com，跟你的網域毫无交集。沒有任何對齊模式能拯救第三方的 d=。

gappssmtp.com / onmicrosoft.com 簽名是壞東西嗎？我該移除它嗎？ 它不壞——它保證你的郵件至少帶著某個有效簽名，這對垃圾郵件過滤有幫助。它只是不屬於你。你不需要移除它；啟用自定義網域簽名就把它替換掉了。

我的網域在 Microsoft 365 上，SPF 是嚴格模式——我是不是已經安全了？ 多半沒有：那條嚴格記錄只是 M365 默認設定在完成它唯一的本職工作。在授權 spf.protection.outlook.com 的 10,205,070 個網域中，85.0% 有嚴格 SPF，却只有 21.7% 強制執行 DMARC（資料截至 2026-06-29）。SPF 在轉發下還會失效，因為它是對 Return-Path 而不是 From 標头評估的——對齊的 DKIM 才是能活下來的那條腿，這正是這項修復重要的原因。

這個修復要花多久？ 控制台裡的操作每個服務商只需几分鐘。等的是 DNS：Google 說開始驗證前要預留最長 48 小時；Microsoft 的 CNAME 通常几小時內生效。整體預算一個工作日，其中大部分是等待。

把報告發給負責人

如果你是在替客戶或雇主修這個問題，用證據來收尾。新簽名生效後重新執行免費掃描，把評分報告轉發給企業負責人：有日期、說人話、顯示 DKIM 已與他們的網域對齊。這正是網路保險續保和下一份供應商安全問卷需要的材料——證明網域以自己的身份做驗證，而不是作為 gappssmtp.com 的一個”租客”。

免費檢查你的 DKIM 對齊

查看你的郵件是否以你自己的網域簽名——以及確切要修什麼——私密進行，僅網域所有者可見。

檢查你的網域 → · DMARC 失敗但 SPF 和 DKIM 都通過 → · 修復 DKIM → · 在 Google Workspace 設定 DKIM → · 僅使用彙總資料。資料在歐盟境內儲存和處理。