設定 DMARC 以驗證 Microsoft 365 中發件者的寄件者發件者網域

以網域為基礎的郵件驗證、報告和一致性 (DMARC) 是 一種電子郵件驗證 方法，可協助驗證從 Microsoft 365 組織傳送的郵件，以防止商務電子郵件中使用的詐騙發件者入侵 (BEC) 、勒索軟體和其他網路釣魚攻擊。

您可以在 DNS 中建立 TXT 記錄，以啟用網域的 DMARC。 電子郵件訊息的 DMARC 驗證包含下列元素：

• 確認 MAIL FROM 和 FROM 位址中的網域對齊： SPF 和 DKIM 不需要下列電子郵件位址中的網域，即可「對齊」 (符合) ：

  • MAIL FROM 位址：在 SMTP 電子郵件伺服器之間傳輸郵件時所使用的電子郵件位址。 此位址也稱為 5321.MailFrom 位址、P1 發件者或信封寄件者。
  • 寄件者位址：[ 寄 件者] 標頭字段中顯示為電子郵件用戶端中訊息寄件者的電子郵件位址。 此位址也稱為 5322.From 位址或 P2 發件者。

  如需這些電子郵件位址如何位於不同網域並用於詐騙的詳細資訊，請參閱 因特網電子郵件為何需要驗證。

  • DMARC 會使用 SPF 的結果來驗證下列兩個條件：

    • 此訊息來自網域的授權來源，該網域用於MAIL FROM位址 (SPF) 的基本需求。
    • 郵件中MAIL FROM和寄件者位址中的網域會對齊。 此結果實際上需要訊息的有效來源必須位於寄件者位址網域中。

  • DMARC 會使用 DKIM 的結果來驗證在 DKIM-Signature 標頭欄位中簽署訊息 (d= 值的網域，如 s= 選取器值所驗證，) 與發件人位址中的網域一致。

  如果其中一或兩個描述的SPF或 DKIM 檢查都通過，則訊息會傳遞 DMARC。 如果所述的SPF或 DKIM檢查都失敗，則訊息會失敗 DMARC。

• DMARC 原則：指定如何處理 DMARC 失敗 (拒絕、隔離或沒有指示) 的訊息。

• DMARC 報告：指定匯總報表的傳送位置 () 和鑑識報告的定期摘要，) 和鑑識報告 (也稱為 失敗報告;幾乎立即的 DMARC 失敗結果類似於未傳遞報告或退回的訊息) 。

開始之前，以下是您需要瞭解的 Microsoft 365 中以電子郵件網域為基礎的 DMARC：

• 例如，如果您只使用電子郵件 (的 Microsoft Online Email 路由位址 (MOERA) 網域，contoso.onmicrosoft.com) ：雖然已為您的 *.onmicrosoft.com 網域設定 SPF 和 DKIM，但您必須在 Microsoft 365 系統管理中心 中建立 *.onmicrosoft.com 網域的 DMARC TXT 記錄。 如需指示，請參閱本文稍後的 本節 。 如需 *.onmicrosoft.com 網域的詳細資訊，請參閱 為什麼我有「onmicrosoft.com」網域？。

• 例如，如果您針對電子郵件 (使用一或多個自定義網域，contoso.com) ：如果您尚未使用，則必須為用於電子郵件的所有自定義網域和子域設定 SPF。 您也需要使用自定義網域或子域來設定 DKIM 簽署，讓用來簽署訊息的網域與寄件者位址中的網域對齊。 如需指示，請參閱下列文章：

  • 設定 SPF 以協助防止詐騙
  • 使用 DKIM 驗證來自自訂網域的輸出郵件

  之後，您也需要為自定義網域設定 DMARC TXT 記錄，如本文所述。 您也有下列考慮：

  • 子域：

    • 針對不在您直接控制 (例如大量電子郵件服務) 的電子郵件服務，我們建議使用子域 (例如，marketing.contoso.com) 而不是您的主要电子邮件网域 (例如，contoso.com) 。 您不希望從這些電子郵件服務傳送的郵件問題影響您主要電子郵件網域中員工所傳送郵件的信譽。 如需新增子域的詳細資訊，請參 閱我可以將自定義子域或多個網域新增至 Microsoft 365 嗎？。
    • 不同於SPF和 DKIM，網域的 DMARC TXT 記錄會自動涵蓋所有子域 (包括沒有自己 DMARC TXT 記錄的不存在子域) 。 換句話說，您可以在該子域中建立 DMARC TXT 記錄，以中斷子域上的 DMARC 繼承。 但是，每個子域都需要 DMARC 的 SPF 和 DKIM 記錄。

  • 如果您擁有已註冊但未使用的網域：如果您擁有未用於電子郵件或任何 (也稱為 已停 駐網域) 的已註冊網域，請在這些網域中設定 DMARC TXT 記錄，以指定這些網域不應有任何電子郵件。 如果您不是將 *.onmicrosoft.com 網域用於電子郵件，則此指示詞會包含該網域。

• DMARC 檢查 輸入 郵件可能需要協助：如果您使用在傳遞至 Microsoft 365 之前修改傳輸中訊息的電子郵件服務，您可以將服務識別為受信任的 ARC 密封器，讓修改過的郵件不會自動失敗 DMARC 檢查。 如需詳細資訊，請參閱本文結尾的後續 步驟 一節。

本文的其餘部分說明您需要為 Microsoft 365 中的網域建立的 DMARC TXT 記錄、在 Microsoft 365 中逐步且安全地設定自定義網域 DMARC 的最佳方式，以及 Microsoft 365 如何在 輸入 郵件上使用 DMARC。

DMARC TXT 記錄的語法

RFC 7489 中詳盡說明 DMARC TXT 記錄。

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：應該接受訊息，但標示。 郵件實際發生的情況取決於目的地電子郵件系統。 例如，郵件可能會被隔離為垃圾郵件、傳遞至垃圾郵件 Email 資料夾，或傳遞至 [收件匣]，並將標識元新增至主旨或郵件本文。
  • p=none：對於 DMARC 失敗的訊息，沒有建議的動作。 訊息會發生什麼情況取決於目的地電子郵件系統中的電子郵件保護功能。 您可以使用此值來 測試和調整 DMARC 原則 ，如本文稍後所述。

  提示

  如果網域的 DMARC 原則為 p=reject 或 p=quarantine，則來自 Microsoft 365 中未通過目的地電子郵件服務 DMARC 檢查之網域的輸出郵件，會透過輸出郵件的高風險傳遞集區路由傳送。 此行為沒有覆寫。

• 受限於 DMARC 原則的失敗 DMARC 郵件百分比：告知目的地電子郵件系統有多少個失敗 DMARC 的郵件 (百分比) 套用 DMARC 原則。 例如， pct=100 表示失敗 DMARC 的所有訊息都會套用 DMARC 原則。 您可以使用小於 100 的值來 測試和微調 DMARC 原則，如本文稍後所述。 如果您未使用 pct=，則預設值為 pct=100。

• DMARC 報告：

  • DMARC 匯總報表 URI：值 rua=mailto: 會識別 DMARC 匯總報表的傳送位置。 匯總報表具有下列屬性：

    • 包含匯總報表的電子郵件訊息通常會每天傳送一次， (報表包含前一天) 的 DMARC 結果。 [主旨] 行包含將報表傳送 (Submitter) 的目的地網域，以及報表網域) (DMARC 結果的來源網域。
    • DMARC 資料位於可能已壓縮 GZIP 的 XML 電子郵件附件中。 XML 架構定義於 RFC 7489 的附錄 C 中。 報表包含下列資訊：
      • 使用網域傳送郵件之伺服器或服務的IP位址。
      • 伺服器或服務是否通過 DMARC 驗證或失敗。
      • 根據 DMARC 原則) ，DMARC 對無法通過 DMARC 驗證的郵件採取的動作 (。

    提示

    匯總報表中的資訊可能很龐大且難以剖析。 為了協助了解數據，您可以針對 DMARC 報告使用下列選項：

    • 使用 PowerShell 或 Microsoft Power BI 建立自動化。
    • 使用外部服務。 如需服務清單，請在 Microsoft Intelligent Security Association (MISA) 目錄 https://www.microsoft.com/misapartnercatalog中搜尋 DMARC。 DMARC Reporting Services 會描述 DMARC TXT 記錄中所需的任何自定義值。

  • DMARC 鑑識報告 URI：此 ruf=mailto: 值會識別將 DMARC 鑑識報告傳送至何處 (也稱為 DMARC 失敗報告) 。 報告會在 DMARC 失敗之後立即產生並傳送，例如非傳遞報表 (也稱為 NDR 或退回的訊息) 。

  提示

  您應該定期檢閱 DMARC 匯總報告，以監視來自網域的電子郵件來自何處，以及檢查非預期的 DMARC 失敗 (誤判) 。

  個別目的地電子郵件系統會負責將 DMARC 報告傳回給您。 DMARC 報告的數量和種類會因組織所傳送的郵件數量和種類而異。 例如，預期假日期間的郵件數量會減少，而組織活動期間的郵件數量會增加。 最好指定特定人員來監視 DMARC 報告，以及使用特定信箱或 Microsoft 365 群組來接收 DMARC 報告， (不要將報表傳遞至使用者的信箱) 。

如需 DMARC 的詳細資訊，請使用下列資源：

• M³AAWG 的 DMARC 訓練系列 (訊息、惡意代碼、行動裝置反濫用工作組) 。
• dmarcian 的檢查清單。
• DMARC.org 的資訊。

使用 Microsoft 365 系統管理中心 在 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

我們建議您逐步設定 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 涵蓋或未涵蓋多少合法郵件流量，並針對任何問題進行疑難解答。 您也可以查看傳送的詐騙郵件數目，以及其傳送來源。

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 記錄

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

• Exchange Online Protection (EOP) 中的下列功能會影響傳入 Microsoft 365 之郵件的 DMARC 檢查：

  • 檢查訊息的反網路釣魚原則中是否啟用或停用 詐騙情報 。 停用詐騙情報只會停用來自複合驗證檢查的隱含詐騙保護。
  • 在檢查郵件的反網路釣魚原則中，是否啟用或停用 偵測到郵件為詐騙設定時的 Honor DMARC 記錄 原則，以及根據來源網域的 DMARC 原則 (p=quarantine的指定動作，或 p=reject 在 DMARC TXT 記錄) 中啟用。

  如需完整資訊，請 參閱詐騙保護和寄件者 DMARC 原則。

  若要在反網路釣魚原則中查看這些設定的預設值，請在 EOP 防網路釣魚原則設定中檢查數據表中的設定值。

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

• Microsoft 365 會將 DMARC 匯總報告傳送至 DMARC TXT 記錄中具有有效 rua=mailto: 位址的所有網域，只要 Microsoft 365 網域的 MX 記錄直接指向 Microsoft 365 即可。

  如果在傳遞至 Microsoft 365 之前，透過第三方服務或裝置路由傳送來自因特網的郵件， (Microsoft 365) 以外的 MX 記錄點，則不會傳送 DMARC 匯總報告。 這項限制包括混合式或獨立 EOP 案例，其中郵件會先傳遞至內部部署環境，再使用連接器路由傳送至 Microsoft 365。

  提示

  當第三方服務或裝置位於流入 Microsoft 365 的郵件前方時，增強的 連接器篩選 (也稱為 略過清單) 正確識別 SPF 的因特網訊息來源、服務修改訊息) 時的 DKIM (，以及 DMARC 驗證。

針對 DMARC 進行疑難解答

您可以使用下圖來協助針對 DMARC 驗證問題進行疑難解答。

後續步驟

對於 進入 Microsoft 365 的郵件，如果您在傳遞至組織之前使用修改傳輸中訊息的服務，您可能也需要設定受信任的 ARC 密封器。 如需詳細資訊， 請參閱設定受信任的ARC密封器。