設定 DMARC 來驗證雲端寄件者的寄件地址網域

提示

你知道你可以免費試用 適用於 Office 365 的 Microsoft Defender Plan 2 的功能嗎？ 請於 Microsoft Defender 入口試用中心使用 適用於 Office 365 的 Defender 的 90 天試用版。 了解 試用 適用於 Office 365 的 Microsoft Defender 的可註冊對象及試用條款。

基於網域的訊息驗證、報告與符合性 (DMARC) 是一種電子郵件 認證 方法，用以驗證來自您Microsoft 365 組織所發送的郵件。 此驗證有助於防止被用於商務電子郵件詐騙（BEC）、勒索軟體及其他網路釣魚攻擊的偽造寄件者。

你可以透過在 DNS 中建立 TXT 紀錄來啟用網域的 DMARC。 DMARC 電子郵件驗證包含以下要素：

  • 確認郵件寄件人與寄件人地址中的網域對齊： SPF 和 DKIM 不要求以下電子郵件地址的網域必須「對齊」 (匹配) ：

    • MAIL FROM 地址：用於 SMTP 電子郵件伺服器間訊息傳輸的電子郵件地址。 此位址也稱為 5321.MailFrom 地址、P1 發送者或信封發送者。
    • 寄件人地址：在電子郵件用戶端中， From 標頭欄位中顯示的電子郵件地址。 此位址亦稱為 5322.From 地址或 P2 發送者。

    關於這些電子郵件地址如何分布在不同網域並被用於偽造，請參見《 為什麼網路電子郵件需要驗證》。

    • DMARC 利用 SPF 的結果來驗證以下兩種條件：

      • 該訊息來自 MAIL FROM 地址所用網域的授權來源 (符合 SPF) 的基本要求。
      • 郵件中的 MAIL FROM 與 From 地址中的網域是對齊的。 此結果實際上要求訊息的有效來源必須位於 From 地址域。

    • DMARC 利用 DKIM 的結果驗證簽署訊息的網域， (DKIM-Signature 標頭欄位中的 d= 值，並由 s= 選擇器值驗證，) 與 From 地址中的網域對齊。

    若上述SPF或DKIM檢查一項或兩項通過，則訊息通過DMARC。 若上述SPF與DKIM檢查皆未通過，則訊息即未通過DMARC。

  • DMARC 政策：規定未通過 DMARC (拒絕、隔離或無指令) 的訊息該如何處理。

  • DMARC 報告：指定報告寄送地點：

    • 彙總報告（定期彙整 DMARC 正面與負面結果的摘要）
    • 鑑識報告（也稱為 失敗報告；幾乎即時的 DMARC 失敗結果，類似未送達報告或退信訊息）。

在開始之前，以下是你需要了解的關於 Microsoft 365 中基於電子郵件網域的 DMARC 資訊：

  • 如果您僅使用 Microsoft Online Email Routing Address (MOERA) 網域來收發電子郵件 (例如 contoso.onmicrosoft.com)：雖然 SPF 和 DKIM 已針對您的 *.onmicrosoft.com 網域完成設定，但您仍需要在 Microsoft 365 系統管理中心中，為 *.onmicrosoft.com 網域建立 DMARC TXT 記錄。 關於說明，請參見「使用Microsoft 365 系統管理中心為 Microsoft 365 中 *.onmicrosoft.com 網域新增 DMARC TXT 紀錄。 欲了解更多關於 *.onmicrosoft.com 網域的資訊，請參閱 「我為何擁有一個「onmicrosoft.com」網域？。

  • 如果您使用一或多個自訂網域作為電子郵件網域（例如 contoso.com）：如果您尚未這麼做，則需要為所有用於電子郵件的自訂網域和子網域設定 SPF。 你還需要設定 DKIM 簽名，使用自訂網域或子網域，讓用於簽署訊息的網域與寄件人地址的網域對齊。 相關說明請參閱以下條目：

    之後，你還需要依本文所述設定自訂網域的 DMARC TXT 紀錄。 你還有以下幾點需要考慮：

    • 子領域：

      • 對於不是由您直接控制的電子郵件服務（例如大量電子郵件服務），請使用子網域（例如 marketing.contoso.com），而非主要電子郵件網域（例如 contoso.com）。 你不希望這些郵件服務寄出的問題影響你主要電子郵件網域用戶寄出的信件聲譽。 關於新增子網域的更多資訊，請參見「 我可以為 Microsoft 365 新增自訂子網域或多個網域嗎？」。
      • 與 SPF 和 DKIM 不同，網域的 DMARC TXT 紀錄會自動涵蓋所有子網域 (包括不存在且沒有自己 DMARC TXT 紀錄的子網域) 。 換句話說，你可以透過在子網域建立 DMARC TXT 紀錄來干擾 DMARC 在該子網域的繼承。 但每個子網域都需要 SPF 和 DKIM 紀錄來進行 DMARC。

    • 如果你擁有已註冊但未使用的網域：如果你擁有不用於電子郵件或其他用途的註冊網域 (也就是所謂 的停放網域) ，請設定這些網域的 DMARC TXT 紀錄，指定這些網域絕對不會有郵件寄出。 如果你不使用該網域來收發電子郵件，此指令包含 *.onmicrosoft.com 網域。

  • DMARC 對 內送 郵件的檢查可能需要協助：如果你使用的電子郵件服務會在郵件傳送途中、傳遞至 Microsoft 365 之前修改郵件，你或許可以將該服務識別為受信任的 ARC 封裝者。 受信任的 ARC 封口器可防止修改後的訊息自動在 DMARC 檢查中失敗。 欲了解更多資訊，請參閱 下一步。

本文其餘部分將介紹 DMARC TXT 紀錄建立、自訂網域的逐步部署，以及 Microsoft 365 中的入站 DMARC 處理。

提示

要為Microsoft 365 系統管理中心中的 *.onmicrosoft.com 網域建立 DMARC TXT 紀錄，請參見 Microsoft 365 中使用 Microsoft 365 系統管理中心 新增 *.onmicrosoft.com 網域的 DMARC TXT 紀錄。

Microsoft 365 裡沒有管理入口網站或 PowerShell 指令匣，讓你管理 自訂 網域中的 DMARC TXT 紀錄。 相反地，你應該在網域註冊商或 DNS 主機服務建立 DMARC TXT 紀錄， (通常是同一家公司的) 。

許多網域註冊商提供建立 Microsoft 365 網域所有權 TXT 紀錄的說明。 你可以用這些說明作為起點，建立 DMARC TXT 紀錄。 欲了解更多資訊，請參閱 新增 DNS 紀錄以連接您的網域。

如果你不熟悉 DNS 設定，請聯絡你的網域註冊商尋求協助。

DMARC TXT 紀錄的語法

DMARC TXT 紀錄詳盡描述於 RFC 7489 中。

Microsoft 365 中 DMARC TXT 記錄對應網域的基本語法為：

主機名稱： _dmarc
TXT 值：v=DMARC1; <DMARC policy>; <Percentage of DMARC failed mail subject to DMARC policy>; <DMARC reports>

或

主機名稱： _dmarc
TXT 值：v=DMARC1; p=<reject | quarantine | none>; pct=<0-100>; rua=mailto:<DMARCAggregateReportURI>; ruf=mailto:<DMARCForensicReportURI>

例如：

主機名稱： _dmarc
TXT 值：v=DMARC1; p=reject; pct=100; rua=mailto:rua@contoso.com; ruf=mailto:ruf@contoso.com

  • 主機名稱 _dmarc 值是必須的。

  • v=DMARC1; 識別 TXT 紀錄為 DMARC TXT 紀錄。

  • DMARC 政策：告訴目標郵件系統對於未通過 DMARC 的郵件該如何處理（拒絕、隔離或不採取行動）：

    • p=reject：這些訊息應該被拒絕。 訊息的實際處理方式取決於目的電子郵件系統，但郵件通常會被丟棄。
    • p=quarantine：這些訊息應予接受，但應加以標記。 訊息實際會發生什麼事，取決於目的地的電子郵件系統。 例如，該郵件可能被隔離為垃圾郵件，或送達至垃圾郵件（Junk Email）資料夾，或在主旨或訊息內容中加入識別碼後送達收件匣。
    • p=none：對於未通過 DMARC 驗證的訊息，沒有建議的處理動作。 郵件的處理方式取決於目標郵件系統的電子郵件保護功能。 你用這個值來 測試和調整 DMARC 政策。

    提示

    若來自 Microsoft 365 中網域的外寄郵件未通過目的地電子郵件服務的 DMARC 檢查，且該網域的 DMARC 原則為 或 p=reject，則會透過 p=quarantine 路由傳送。 此行為沒有覆寫選項。

  • 套用 DMARC 原則的未通過 DMARC 郵件百分比：告訴目的地電子郵件系統，未通過 DMARC 的郵件中有多少百分比要對其套用 DMARC 原則。 例如，表示 pct=100 所有未通過 DMARC 的訊息都會套用 DMARC 政策。 你會用小於 100 的數值來 測試和調整 DMARC 政策。 如果你不使用 pct=，預設值為 pct=100。

  • DMARC 報告：

    • DMARC 彙總報告 URI：此 rua=mailto: 值標示應將 DMARC 匯總報告傳送至何處。 綜合報告具備以下特性：

      • 包含彙總報告的電子郵件通常每天會傳送一次（該報告包含前一天的 DMARC 結果）。 主旨欄包含傳送報告之目標網域（提交者）以及 DMARC 結果的來源網域（報告網域）。
      • DMARC 資料放在一個 XML 電子郵件附件裡，可能是 GZIP 壓縮的。 XML 架構定義於 RFC 7489 附錄 C。 報告包含以下資訊：
        • 就是用你網域發送郵件的伺服器或服務的 IP 位址。
        • 無論伺服器或服務是否通過或失敗 DMARC 認證。
        • DMARC 對未通過 DMARC 認證的郵件所採取的行動 (基於 DMARC 政策) 。

      提示

      彙整報告中的資訊可能龐大且難以解析。 為了幫助理解資料，您可以使用以下 DMARC 報告選項：

      • 使用 PowerShell 或 Microsoft Power BI 建立自動化。
      • 使用外部服務。 欲查詢服務清單，請在Microsoft智慧安全協會 (MISA) 目錄 https://www.microsoft.com/misapartnercatalog中搜尋DMARC。 DMARC 報告服務描述了 DMARC TXT 紀錄中所需的任何自訂值。

    • DMARC 鑑識報告 URI：此 ruf=mailto: 值標示 DMARC 鑑識報告的傳送地點 (亦稱為 DMARC 失效報告) 。 報告會在 DMARC 失敗後立即產生並傳送，類似未送達報告 (也稱為 NDR 或退信) 。

    提示

    你應該定期檢視 DMARC 彙總報告，以監控來自你網域的電子郵件來源，並檢查是否有無意的 DMARC 失敗 (誤報) 。

    個別的目的地電子郵件系統負責將 DMARC 報告回傳給你。 DMARC 報告的數量與種類，就像貴組織寄出的郵件數量與種類一樣。 例如，假日期間郵件量會較低，組織活動期間郵件量則較高。 最好指定特定人員監控 DMARC 報告，並使用特定的信箱或 365 群組Microsoft接收 DMARC 報告， (不會將報告送達使用者的信箱) 。

欲了解更多關於 DMARC 的資訊，請使用以下資源：

  • M3AAWG (訊息、惡意軟體、行動反濫用工作小組) 的 DMARC 訓練系列。
  • 詳情請見 DMARC.org。

利用Microsoft 365 系統管理中心在 Microsoft 365 中新增 *.onmicrosoft.com 網域的 DMARC TXT 紀錄

請執行以下步驟，為Microsoft 365 系統管理中心中的 *.onmicrosoft.com 網域新增 DMARC TXT 紀錄。

  1. 在 Microsoft 365 系統管理中心https://admin.microsoft.com，選擇「顯示所有>設定>網域」。 或者，若要直接進入 網域頁面 ，請使用 https://admin.microsoft.com/Adminportal/Home#/Domains。

  2. 在 網域頁面 ，點擊清單中除網域名稱旁勾選框以外的任何欄位，選擇 *.onmicrosoft.com 網域。

  3. 在開啟的網域詳細頁面，選擇 DNS 紀錄 標籤。

  4. 在 DNS 紀錄 標籤中，選擇 新增紀錄。

  5. 在開啟的 「新增自訂 DNS 紀錄 」跳板中，請設定以下設定：

    • 類型：確認已選擇 TXT (文字) 。

    • TXT 名稱：輸入 _dmarc。

    • TXT 值：輸入 v=DMARC1; p=reject。

      提示

      要指定 DMARC 聚合與 DMARC 鑑識報告的目的地，請使用語法 v=DMARC1; p=reject; rua=mailto:<emailaddress>; ruf=mailto:<emailaddress>。 例如，v=DMARC1; p=reject; rua=mailto:rua@contoso.onmicrosoft.com; ruf=mailto:ruf@contoso.onmicrosoft.com。

      MISA 目錄 https://www.microsoft.com/misapartnercatalog 中的 DMARC 報告供應商讓查看與解讀 DMARC 結果變得更方便。

    • TTL：確認已選取 1 小時。

    當你完成 「新增自訂 DNS 記錄 」的跳板功能後，選擇 「儲存」。

在 Microsoft 365 中為使用中的自訂網域設定 DMARC

提示

在設定自訂網域或子網域的 DMARC 之前，你需要先建立 SPF TXT 紀錄，並為所有用來在 Microsoft 365 發送電子郵件的自訂網域和子網域設定 DKIM 簽章。

建議採取漸進式的方式來設定 Microsoft 365 網域的 DMARC。 目標是為所有自訂網域和子網域建立 p=reject DMARC 政策，但過程中需要測試和驗證，以防止目的郵件系統因 DMARC 意外失敗而拒絕優質郵件。

您的 DMARC 推廣計畫應採用以下步驟。 先從郵件量低且潛在郵件來源較少的網域或子網域開始 (這樣來自未知來源的合法郵件被封鎖的機率較低) ：

  1. 先從 DMARC 政策 p=none 開始，並監控該網域的結果。 例如：

    marketing.contoso.com 的 DMARC TXT 紀錄：

    主機名稱： _dmarc
    TXT 值：v=DMARC1; p=none; pct=100; rua=mailto:rua@marketing.contoso.com; ruf=mailto:ruf@marketing.contoso.com

    DMARC 彙總與 DMARC 鑑識報告提供了通過與未通過 DMARC 檢查的訊息數量與來源。 你可以查看你的合法郵件流量中有多少受到 DMARC 涵蓋、多少未受到 DMARC 涵蓋，並針對任何問題進行疑難排解。 你也能看到有多少假訊息被發送，以及它們是從哪裡發送的。

  2. 將 DMARC 原則提升至 p=quarantine，並監控該網域的結果。

    在監控 p=none 的影響一段足夠長的時間後，你可以將該網域的 DMARC 原則提高至 p=quarantine。 例如：

    marketing.contoso.com 的 DMARC TXT 紀錄：

    主機名稱： _dmarc
    TXT 值：v=DMARC1; p=quarantine; pct=100; rua=mailto:rua@marketing.contoso.com; ruf=mailto:ruf@marketing.contoso.com

    你也可以利用這個 pct= 數值逐步影響更多訊息並驗證結果。 例如，你可以以以下遞增方式移動：

    • pct=10
    • pct=25
    • pct=50
    • pct=75
    • pct=100

  3. 將 DMARC 原則提升至 p=reject，並監控該網域的結果。

    在監控 p=quarantine 的影響一段足夠長的時間後，你可以將該網域的 DMARC 原則提高至 p=reject。 例如：

    marketing.contoso.com 的 DMARC TXT 紀錄：

    主機名稱： _dmarc
    TXT 值：v=DMARC1; p=reject; pct=100; rua=mailto:rua@marketing.contoso.com; ruf=mailto:ruf@marketing.contoso.com

    你也可以利用這個 pct= 數值逐步影響更多訊息並驗證結果。

  4. 對剩餘體積和/或複雜度增加的子網域重複前三步，將父網域留到最後。

    提示

    封鎖任何大量合法郵件對使用者來說都是不可接受的，但你幾乎不可避免會收到一些誤報。 慢慢來，有條不紊地處理 DMARC 報告中揭露的問題。 MISA 目錄 https://www.microsoft.com/misapartnercatalog 中的 DMARC 報告供應商讓查看與解讀 DMARC 結果變得更方便。

  5. 子網域繼承父網域的 DMARC TXT 紀錄設定，你可以在子網域內用獨立的 DMARC TXT 紀錄覆蓋這些設定。 當你在網域和所有子網域中設定好 DMARC，且父網域和所有子網域的 DMARC 設定幾乎相同後，你可以移除子網域中的 DMARC TXT 紀錄，改用父網域中的單一 DMARC TXT 紀錄。

Microsoft 365 中停放網域的 DMARC TXT 紀錄

提示

對於不發送郵件的停放網域，建議的 SPF TXT 紀錄在 自訂雲端網域的 SPF TXT 紀錄中說明。 如同「 設定 DKIM 以簽署雲端網域郵件」中所述，DKIM CNAME 紀錄不建議用於停放網域。

  1. 如果您註冊了網路上任何人都不應該預期會收到郵件的網域，請在該網域註冊商建立以下 DMARC TXT 紀錄：

    主機名稱： _dmarc
    TXT 值：v=DMARC1; p=reject;

    • pct=這個值沒有被包含，因為預設值是 pct=100。
    • rua=mailto: 和 ruf=mailto: 值在此情境下可說是不需要的，因為該網域中的寄件者本來就不應該傳送任何有效郵件。

  2. 如果你不使用 *.onmicrosoft.com 網域來發送郵件，你還需要 為你的 *.onmicrosoft.com 網域新增 DMARC TXT 紀錄。

適用於傳入 Microsoft 365 之郵件的 DMARC

以下特性與行為會影響 Microsoft 365 如何評估 DMARC 的入站訊息，以及是否會發送 DMARC 報告。

  • 以下所有 雲端郵箱內建的安全功能 會影響收到郵件的 DMARC 檢查：

    • 檢查此訊息之反網路釣魚原則中的詐騙情報為啟用或停用。 停用詐騙情報僅會停用複合式驗證檢查中的隱含詐騙防護。
    • 檢查此訊息之反網路釣魚原則中的訊息偵測為詐騙時遵循 DMARC 記錄原則設定為啟用或停用，以及根據來源網域的 DMARC 原則 (DMARC TXT 記錄中的 p=quarantine，或 p=reject) 所指定的動作。

    欲知完整資訊，請參閱 偽裝防護及寄件人 DMARC 政策。

    要查看這些設定的預設值，請在所有 雲端郵箱的反釣魚政策設定中查看表格中的設定值。

  • 即使來源網域的 DMARC TXT 記錄中存在有效的 ruf=mailto: 位址，Microsoft 365 也不會傳送 DMARC 鑑識報告（也稱為 DMARC 失敗報告）。

  • Microsoft 365 會將 DMARC Aggregate 報告傳送到所有 DMARC TXT 記錄中有效 rua=mailto: 位址的網域，只要 Microsoft 365 網域的 MX 紀錄直接指向 Microsoft 365。

    如果您在郵件送達 Microsoft 365 之前，先透過非 Microsoft 的服務或裝置轉送網際網路郵件（亦即 MX 記錄指向的不是 Microsoft 365），系統將不會傳送 DMARC 彙總報告。 此限制包含混合情境，郵件先送達本地環境，再透過連接器路由至 Microsoft 365。

    提示

    當非 Microsoft 的服務或裝置位於流入 Microsoft 365 的郵件前端時，連接器增強篩選（也稱為 略過列示）可為 SPF、DKIM（如果該服務會修改郵件）和 DMARC 驗證，正確識別網際網路郵件的來源。

DMARC 故障排除

如需快速查閱 DMARC 錯誤、原因及修復方法，請參見 「Microsoft 365 中的電子郵件認證故障排除」。

本節協助您診斷與解決常見的 DMARC 故障，了解 Microsoft 365 如何對不同 DMARC 政策運作，並解讀 DMARC 彙總與鑑識報告。

DMARC 故障排除流程示意圖

對齊失敗診斷

如 Set DMARC 以驗證雲端發送者的 From 地址域所述，若至少 一次 對齊檢查成功（SPF 或 DKIM），則訊息通過 DMARC。 訊息只有在 兩項 對齊檢查都失敗時，才會未通過 DMARC。

對齊模式

aspf (SPF) 與 adkim (DKIM) 標籤在 DMARC TXT 記錄中控制 From 網域與認證網域必須多嚴格地匹配。 兩者皆為選用項目，預設為 r（寬鬆），但也提供 s（嚴格）。 以下範例展示了使用嚴格SPF比對（aspf=s）與放鬆DKIM比對（adkim=r）的DMARC TXT紀錄：

Hostname: _dmarc
TXT value: v=DMARC1; p=reject; aspf=s; adkim=r; pct=100; rua=mailto:dmarc@contoso.com
  • 寬鬆（r，預設）：組織網域（根網域）必須相符。 允許子網域。
  • 嚴格 (s) ：FQDN 必須完全匹配。 沒有子網域匹配。

附註

aspf和adkim標籤是獨立的。 你可以為每個模式使用不同模式，如範例所示。 只要 任一 對齊檢查成功，訊息就會通過 DMARC，因此若其中一項檢查嚴格對齊失敗，只要另一項檢查以寬鬆對齊通過，就不受影響。

範例：

寄件者地址 MAIL FROM / DKIM-Signature d= 地址 放鬆 (r) 嚴格 (s)
user@contoso.com contoso.com ✅ 通過 ✅ 通過
user@contoso.com bounces.contoso.com ✅ 通過 ❌ 失敗
user@marketing.contoso.com contoso.com ✅ 通過 ❌ 失敗
user@contoso.com contoso.onmicrosoft.com ❌ 失敗 ❌ 失敗
user@contoso.com adatum.net ❌ 失敗 ❌ 失敗

常見的對齊失效情境

下表列出常見的 DMARC 對齊失效情境、症狀、根本原因及建議的修復方法。

情境 徵兆 根本原因 解決方案
非 Microsoft 服務代你發送 adatum.com 的 SPF 驗證通過，但 DMARC 驗證失敗 MAIL FROM 會使用服務的網域 (， bounce.adatum.com 例如) 且不會用你的網域進行 DKIM 簽章 在該服務上設定使用你的網域進行 DKIM 簽署，或將 MAIL FROM 變更為你的網域/子網域
Microsoft 365 自動轉發 DMARC 在目的地端驗證失敗 轉寄會變更信封寄件者；DKIM 簽章可能會失效 在目的地使用受信任的 ARC 密封者，或使用 DKIM (如果內文未經修改，轉寄後仍可保持有效)
子域傳送時會嚴格對齊 aspf=s 導致子網域寄件者發生失敗 MAIL FROM 是 sub.contoso.com，但 From 是 contoso.com 變更為 aspf=r（寬鬆），或確保 From 位址與子網域相符
DKIM 簽署網域不匹配 DKIM通過了，但DMARC仍然失敗 例如DKIM d= 值 (， adatum.com) 與From domain不符 (contoso.com) 在服務中使用你的網域設定自訂的 DKIM 簽名
共用信箱或分發群組 DMARC 間歇性失效 回覆自或重新導向會變更信封地址 確認 DKIM 是否完整;請考慮 ARC 作為中介服務

從訊息標頭診斷對齊失敗

步驟 1：打開訊息標頭，找到 Microsoft 365 的 Authentication-Results 標頭。 以下範例顯示 Authentication-Results 標頭，其中 SPF 與 DKIM 均各自通過，但 DMARC 失敗，因為兩者的網域都未與 From 位址的網域對齊：

Authentication-Results: spf=pass (sender IP is 198.51.100.10)
  smtp.mailfrom=bounces.adatum.com; dkim=pass (signature was verified)
  header.d=adatum.com; dmarc=fail action=oreject
  header.from=contoso.com;compauth=fail reason=000

步驟二：找出對齊失效：

檢查 標頭欄位 範例中的價值 和From (contoso.com) 一致嗎？
SPF 對齊 smtp.mailfrom= bounces.adatum.com ❌ 沒有 (不同的組織網域)
DKIM 對齊 header.d= adatum.com ❌ 沒有 (不同的組織網域)
DMARC 結果 dmarc= fail 兩次檢查都失敗了

步驟三：透過回答以下問題來確定解決方案：

  1. 您可以將 MAIL FROM 地址變更為您的網域嗎 (例如使用 bounces.contoso.com，而非 bounces.adatum.com)？
    • 是的：在服務端設定 MAIL FROM 變更以修正 SPF 對齊。
    • 否：請改用 DKIM 對齊（前往步驟 2）。
  2. 服務可以用你的網域 (d=contoso.com) 簽名嗎？
    • 是的：在服務中設定自訂 DKIM 簽約。
    • 不：考慮子領域策略：
      • 從子網域傳送 (例如，sub.contoso.com)。
      • 為該子網域發佈一個獨立的 DMARC 紀錄。
      • 讓服務使用 d=sub.contoso.com 進行 DKIM 簽署。

檢查 PowerShell 中近期訊息的對齊

連接 Exchange Online PowerShell 並執行以下指令：

# Get recent messages and check authentication results
$messages = Get-MessageTrace -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) -PageSize 100

foreach ($msg in $messages) {
    $details = Get-MessageTraceDetail -MessageTraceId $msg.MessageTraceId -RecipientAddress $msg.RecipientAddress
    $authEvent = $details | Where-Object { $_.Event -eq "Receive" }
    if ($authEvent.Detail -match "dmarc=fail") {
        Write-Output "DMARC FAIL: From=$($msg.SenderAddress), Subject=$($msg.Subject)"
    }
}

DMARC 政策對 Microsoft 365 行為的影響

如 內送郵件的 DMARC 所述，Microsoft 365 的行為取決於 Honor DMARC record policy 設定。 如需完整詳細資訊，請參閱 防止詐騙與寄件者 DMARC 原則。

下列摘要顯示當遵循 DMARC 記錄原則為開啟 (建議) 時，未通過 DMARC 之內送訊息的一般行為：

寄件人的 DMARC 政策 訊息處理 驗證結果 CompAuth
p=none 沒有DMARC專屬的動作。 其他過濾仍然適用。 dmarc=fail action=none 根據複合式驗證 (SPF、DKIM、詐騙情報)
p=quarantine 垃圾Email資料夾 (可設定成隔離) dmarc=fail action=quarantine compauth=fail reason=100
p=reject 在 SMTP (550 5.7.1) 中被拒絕 dmarc=fail action=oreject compauth=fail reason=100

注意

為合法寄件者覆寫 p=reject 時請務必小心。 如果您的組織確實會收到來自 DMARC 驗證失敗之寄件者的郵件（例如轉寄郵件、郵寄清單），請使用下列其中一種方法：

  • 將寄件人設定為 可信的 ARC 封口員 (首選) 。
  • 建立郵件流程規則，設定特定條件 (寄件人 IP + 寄件人網域) ，以跳過垃圾郵件過濾。
  • 在租用戶允許/封鎖清單中新增一個允許項目（暫時性，30 天後到期）。

Authentication-Results 中的 DMARC 動作值

在 Authentication-Results 標頭中，你可能會看到以下 DMARC 動作值：

行動價值 意義
action=none 發送者已發布 p=none;未採取任何行動
action=quarantine 寄件者發佈了 p=quarantine；訊息已隔離或標示為垃圾郵件
action=oreject 發送者已發佈 p=reject;訊息被拒絕 (「o」= 來源)
action=pct.quarantine 寄件者發佈了 p=quarantine，且 pct= 小於 100；此訊息屬於取樣百分比範圍內
action=pct.reject 寄件者發佈了 p=reject，且 pct= 小於 100；此訊息屬於取樣百分比範圍內

DMARC 報告解讀

本節協助您解讀接收者發送給您 rua 地址 ruf 的 DMARC 彙總與鑑識報告。 關於如何在 DMARC TXT 記錄中設定 rua 和 ruf 值的資訊，請參見 DMARC TXT 記錄的語法。

綜合報告

以下範例展示了彙總報告的 XML 結構：

<?xml version="1.0" encoding="UTF-8"?>
<feedback>
  <report_metadata>
    <org_name>microsoft.com</org_name>           <!-- Reporting organization -->
    <email>dmarceng@microsoft.com</email>
    <report_id>unique-report-id</report_id>
    <date_range>
      <begin>1700000000</begin>                   <!-- Unix timestamp: start -->
      <end>1700086400</end>                       <!-- Unix timestamp: end -->
    </date_range>
  </report_metadata>

  <policy_published>
    <domain>contoso.com</domain>                  <!-- Your domain -->
    <adkim>r</adkim>                              <!-- DKIM alignment mode -->
    <aspf>r</aspf>                                <!-- SPF alignment mode -->
    <p>reject</p>                                 <!-- Domain policy -->
    <sp>quarantine</sp>                           <!-- Subdomain policy -->
    <pct>100</pct>                                <!-- Percentage -->
  </policy_published>

  <record>
    <row>
      <source_ip>198.51.100.10</source_ip>        <!-- Sending IP -->
      <count>1523</count>                         <!-- Number of messages -->
      <policy_evaluated>
        <disposition>none</disposition>           <!-- What receiver did -->
        <dkim>pass</dkim>                         <!-- DKIM alignment result -->
        <spf>fail</spf>                           <!-- SPF alignment result -->
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>contoso.com</header_from>      <!-- From address domain -->
      <envelope_from>bounces.adatum.com</envelope_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>contoso.com</domain>
        <result>pass</result>
        <selector>selector1</selector>
      </dkim>
      <spf>
        <domain>bounces.adatum.com</domain>
        <result>pass</result>                     <!-- SPF passed but... -->
      </spf>
    </auth_results>
  </record>
</feedback>

閱讀綜合報告

請參考下表解讀 DMARC 彙總報告中最重要的欄位，並決定應採取何種故障排除行動。

XML 元素 它告訴你的 故障排除動作
<source_ip> 發送訊息的 IP 位址 確認這是合法寄件人還是未經授權的寄件人
<count> 來自此來源的訊息數量 來自未知 IP 的高計數 = 潛在的偽造
<disposition> 接收方採取的行動 (none， quarantine，) reject 確認收款人是否遵守你的保單
<dkim> 之下的 <policy_evaluated> DKIM 是否對齊 (而不只是通過) fail = DKIM 網域與 From 網域不符合
<spf> 之下的 <policy_evaluated> SPF 是否對齊 (而不只是通過) fail = MAIL FROM 網域與寄件者網域不相符
<domain> 之下的 <auth_results><spf> 進行 SPF 檢查時比對的網域 如果與 From 網域不同，則為對齊問題
<domain> 之下的 <auth_results><dkim> DKIM 簽名網域 必須與 From 網域匹配才能達成 DMARC 對齊
<result> 之下的 <auth_results> 對齊檢查前的 SPF/DKIM 原始通過/失敗結果 pass + 對齊 fail = 經典對齊問題

提示

彙整報告中最重要的洞見，在於找出驗證通過與對齊通過之間的差距：

  • <auth_results><spf><result>pass</result> + <policy_evaluated><spf>fail</spf> = SPF 通過，但領域不對齊。
  • 這種組合表示寄件者已獲授權（SPF 通過），但 DMARC 未正確設定（對齊失敗）。

常見的彙總報告模式與修正

下表展示了你可能在彙總報告中發現的常見模式及其通常需要採取的行動。

報告中的模式 解譯 修正
已知 IP，SPF 認證=通過，SPF 對齊=失敗 MAIL FROM 網域錯誤的合法服務 設定服務以在 MAIL FROM 中使用您的網域，或設定使用您的網域進行 DKIM 簽署
已知 IP，DKIM 認證=通過，DKIM 對齊=失敗 服務以自己的網域簽署 DKIM 在服務中使用 d=contoso.com 設定自訂 DKIM
未知 IP，高流量，全部失敗 潛在的詐騙/網路釣魚活動 不需要行動。 你的 DMARC 政策是在保護收件人。
已知的 IP (Microsoft 365)，SPF 對齊=通過 一般 Microsoft 365 郵件流程 健康。 不需要行動。
來自合法服務的流量偏低，SPF+DKIM 驗證失敗 服務未包含在 SPF 內，也未包含 DKIM 簽名 在 SPF 記錄中新增服務和/或設定 DKIM
已轉寄的郵件 (郵件清單 IP)，全部失敗 郵件轉寄會破壞 SPF；郵件本文修改會使 DKIM 失效 這對轉寄的郵件來說是正常現象。 使用 ARC，或接受某些失敗情況。

法醫報告

如 DMARC 入信 條款所述，Microsoft 365 不會發送鑑識報告。 不過，你可能會從其他服務提供者那裡收到。 下表比較了兩種報告類型：

層面 彙整報告 () rua 法醫報告 (ruf)
Frequency 日常 (通常) 近乎即時 (依失敗次數)
內容 按來源 IP 統計摘要 個別訊息詳情
Volume 每位記者每天報告一份 每次故障提交一份報告（報告數量可能很多）
隱私權 僅限 IP 位址與數量 可能會包含訊息標頭/正文 (經過刪節)
支援 廣受接收器支援 支援有限（許多接收器不會傳送 RUF）
使用案例 趨勢分析，識別未知發送者 針對特定故障進行除錯與鑑識調查

附註

如果你需要從 Microsoft 365 取得每封郵件的失敗詳細資料，請使用郵件追蹤和郵件標頭分析，而不要使用鑑識報告。

以下範例展示了當訊息未通過 DMARC 時，接收端向你 ruf 地址發送的 DMARC 鑑識報告（AFRF/RFC 6591 格式）的結構。 請尋找 Feedback-Type、 Source-IP和 Authentication-Results 欄位以識別故障細節：

From: noreply-dmarc-support@fabrikam.com
To: ruf@contoso.com
Subject: Report Domain: contoso.com Submitter: fabrikam.com

Feedback-Type: auth-failure
User-Agent: fabrikam.com/dmarc-reporter
Version: 1
Original-Mail-From: bounces@adatum.com
Arrival-Date: Mon, 15 Jan 2024 10:30:00 -0000
Source-IP: 198.51.100.10
Authentication-Results: fabrikam.com; dmarc=fail (p=reject)
  header.from=contoso.com
Reported-Domain: contoso.com
Original-Envelope-Id: <abc123@mail.adatum.com>

DMARC 報告的最佳實務

請採用以下最佳實務來有效管理 DMARC 報告。

建議 詳細資料
為 rua 使用專用信箱 例如建立共用信箱 (，) dmarc-reports@contoso.com 。 不要使用個別使用者的信箱。
使用 Microsoft 365 群組 群組為資安團隊提供更好的協作與共享存取權限
考慮使用DMARC報告服務 DMARC 報告服務將 XML 解析成儀表板。 可在MISA目錄中搜尋DMARC。
僅以 rua 開始 如果需要，之後再加。ruf 鑑識報告能產生大量資訊量。
定期監測 初期部署期間每週檢視彙整報告；穩定後每月檢視一次
設定現實的期望 並非所有接收者都會寄報。 覆蓋範圍通常佔總郵件量的70-90%

跨域報告

如果您的 DMARC rua 或 ruf 地址位於與被監控 網域不同的網域 ，接收方必須發布一份授權報告傳遞的 DNS TXT 紀錄：

範例：DMARC 用於 contoso.com 傳送報告至 dmarc@fabrikam.com

若要授權 fabrikam.com 代表 contoso.com 接收 DMARC 報告，fabrikam.com 的管理員必須發佈下列 DNS TXT 記錄：

Hostname: contoso.com._report._dmarc
Type: TXT
Value: v=DMARC1;

若無此紀錄，接收方無法將 DMARC 報告送達外部地址。

DMARC 故障排除快速參考

下表提供常見DMARC症狀的快速參考、可能原因、診斷步驟及解決方法。

徵兆 可能的原因 診斷步驟 解決方案
dmarc=fail 但 SPF 和 DKIM 兩者皆個別通過驗證 對齊失敗：領域不匹配 From 在 Authentication-Results 中檢查 smtp.mailfrom= 和 header.d= 與 header.from= 的比較 使用對齊的網域設定 SPF/DKIM
dmarc=bestguesspass From 網域未公開 DMARC 紀錄 查詢 _dmarc.domain.com TXT 記錄 Microsoft 會推斷為通過。 發布明確的 DMARC 紀錄。
dmarc=fail action=oreject 但訊息已傳達 遵循 DMARC 已停用，或已設定允許清單/覆寫 檢查反釣魚政策設定和租戶允許/封鎖名單 如果需要嚴格強制執行，請啟用 遵循 DMARC 記錄原則
dmarc=fail 用於轉發訊息 轉寄會中斷 SPF 對齊；內文變更會中斷 DKIM 檢查訊息是否經過中介（X-MS-Exchange 標頭） 為轉寄服務設定可信的ARC封存器
dmarc=fail 適用於非 Microsoft SaaS 寄件者 服務在 MAIL FROM 和 DKIM 中使用自己的網域 d= 請查看服務的 IP 彙整報告 在服務處設定自訂 DKIM 簽章 + 對齊郵件來源
dmarc=temperror 或 dmarc=permerror DNS 擷取 DMARC 記錄時發生問題（逾時、語法錯誤） 使用 nslookup -type=TXT _dmarc.domain.com 驗證 DMARC 記錄語法 修正 DNS 語法錯誤;確保只存在一條 _dmarc TXT 紀錄
compauth=fail reason=000 複合驗證失敗 (明確失敗) 查看所有認證結果 (SPF、DKIM、DMARC、ARC) 修正底層的 SPF/DKIM/DMARC 問題
compauth=fail reason=100 DMARC 明確失敗，並強制執行原則 發送者的 DMARC 政策導致了失敗 在來源修正對齊問題，或者如果合法則設定 ARC/覆寫
未收到綜合報告 rua 位址無法達，或跨域認證缺失 驗證信箱存在及外部網域的 DNS 授權紀錄 修正信箱路由;新增 domain._report._dmarc TXT 紀錄

DMARC 診斷工作流程

請依照以下步驟診斷含有 dmarc=fail 的訊息：

  1. 識別 From 網域：在 header.from= 標頭中尋找 值。

  2. 檢查 SPF 對齊：smtp.mailfrom= 網域是否與 header.from= 網域相符？

    • 是（與 aspf=r 具有相同的組織網域）：SPF 已對齊。
    • 否：SPF 對齊失敗。
    • SPF 到底有沒有通過（spf=pass 與 spf=fail 相比）？ 如果 spf=fail，先透過將發送者加入 SPF 紀錄來修正 SPF。

  3. 檢查 DKIM 對齊：DKIM-Signature 中的值是否 header.d= 與網域相符 header.from= ？

    • 是（與 adkim=r 具有相同的組織網域）：DKIM 已對齊。
    • 不：DKIM 對齊失敗。
    • DKIM 是否有通過（dkim=pass 與 dkim=fail 相比）？ 如果 dkim=fail，則透過公開金鑰並驗證簽署來修正 DKIM。

  4. 如果兩種排列都失敗，DMARC 也會失敗。 解析度選項：

    • 修正 SPF 對齊：將 MAIL FROM 地址改成你的網域。
    • 修正 DKIM 對齊：使用 d=contoso.com 進行簽署。
    • 使用子網域：從 sub.domain.com 發送，並附有自己的 DMARC 紀錄。
    • 若訊息被轉發：設定一個受信任的 ARC 封函器。

  5. 請查看政策行動：

    • p=none：對分娩無影響 (僅監控) 。
    • p=quarantine：訊息會移至 Junk Email（如果已開啟 Honor DMARC policy）。
    • p=reject：郵件會遭到拒絕（若已開啟 遵循 DMARC 原則）。 如果合法郵件被拒絕，請使用 ARC、允許清單，或修正來源認證。

用於 DMARC 故障排除的實用 PowerShell 指令

連接 Exchange Online PowerShell，並使用以下指令驗證你的反釣魚政策 DMARC 設定、檢查 DMARC 與 DKIM DNS 紀錄、檢視近期 DMARC 失敗案例，以及檢查 ARC 設定：

# Check your organization's anti-phishing policy DMARC settings
Get-AntiPhishPolicy | Format-List Name, HonorDmarcPolicy, DmarcQuarantineAction, DmarcRejectAction

# Verify DMARC record for a domain
Resolve-DnsName -Name "_dmarc.contoso.com" -Type TXT | Select-Object -ExpandProperty Strings

# Check DKIM configuration (alignment prerequisite)
Get-DkimSigningConfig | Format-List Domain, Enabled, Selector1CNAME, Selector2CNAME

# Review messages that failed DMARC in the last 24 hours
Get-MailDetailSpamReport -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) |
  Where-Object { $_.MessageTraceId } |
  Select-Object Date, SenderAddress, RecipientAddress, Subject, SpamScore

# Check ARC configuration (for forwarding scenarios)
Get-ArcConfig | Format-List ArcTrustedSealers

# View anti-phishing policy DMARC override actions
Get-AntiPhishPolicy -Identity "Office365 AntiPhish Default" |
  Select-Object HonorDmarcPolicy, DmarcQuarantineAction, DmarcRejectAction

提示

在排除特定寄件者的 DMARC 故障時：

  1. 從 Authentication-Results 標頭開始辨識故障類型。
  2. 與你的 DMARC 彙總報告 交叉比對，查看音量和來源 IP。
  3. 使用 Get-MessageTrace 尋找特定訊息，使用 Get-MessageTraceDetail 檢視送達事件。
  4. 如果寄件人是可信任的，請先與對方合作修正 SPF/DKIM 的對齊問題，再建立例外設定。

後續步驟

對於傳入 Microsoft 365 的郵件，如果您使用會在郵件送達貴組織之前於傳輸途中修改郵件的服務，您可能也需要設定受信任的 ARC 簽署者。 欲了解更多資訊，請參閱 配置可信的ARC封口器。

要診斷並修復電子郵件認證失敗，請參閱 「在 Microsoft 365 中排除電子郵件認證問題」。

  • Last updated on