使用 DMARC 來驗證電子郵件

發行項
03/18/2023

提示

您知道您可以免費試用Office 365方案 2 的Microsoft 365 Defender功能嗎？ 使用 Microsoft 365 Defender 入口網站試用中樞的 90 天適用於 Office 365 的 Defender試用版。在這裡瞭解誰可以註冊和試用條款。

適用於

以網域為基礎的郵件驗證、報告和符合性 (DMARC) 搭配寄件者原則架構 (SPF) 和網域金鑰識別郵件 (DKIM) 來驗證郵件寄件者。

DMARC 確保目的地電子郵件系統信任從您網域傳送的訊息。將 DMARC 與 SPF 和 DKIM 結合使用，可以為組織提供更多保護，防止詐騙和網路釣魚電子郵件。 DMARC 可協助接收方郵件系統決定如何處理來自您網域之未通過 SPF 或 DKIM 檢查的郵件。

提示

請造訪 Microsoft 情報安全性聯盟 (MISA) 目錄，以檢視為 Microsoft 365 提供 DMARC 報告的協力廠商。

提示

您是否看過我們的逐步指南？ 設定 1-2-3s 且沒有 frills，適用于急迫的系統管理員。如需在MOERA) 和停駐網域 (啟用 Microsoft Online Email 路由位址 DMARC 報告的步驟。

SPF 和 DMARC 如何共同運作以在 Microsoft 365 中保護電子郵件？

電子郵件訊息可能包含多個建立者或寄件者地址。這些地址可用於不同用途。例如以下地址：

「郵件寄件者」地址：識別寄件者，並説明如果郵件傳遞發生任何問題時要傳送回傳通知的位置 (如未傳遞通知)。 郵件寄件者地址 顯示在電子郵件的信封部分，不會顯示在電子郵件應用程式中，有時稱為 5321.MailFrom 地址或反轉路徑地址。
「寄件者」地址：由您的郵件應用程式顯示為寄件者地址的地址。 寄件者地址 可識別電子郵件的作者。也就是負責撰寫郵件的使用者或系統信箱。 寄件者地址 有時稱為 5322.From 地址。

SPF 使用 DNS TXT 記錄列出指定網域的已授權傳送 IP 位址。一般而言，SPF 檢查只會針對 5321.MailFrom 地址執行。當您單獨使用 SPF 時，不會驗證 5322.From 地址，這會導致以下情况：使用者收到通過了 SPF 檢查的訊息，但其具有僞造的 5322.From 寄件者地址。例如，請看以下 SMTP 文字記錄：

S: Helo woodgrovebank.com
S: Mail from: phish@phishing.contoso.com
S: Rcpt to: astobes@tailspintoys.com
S: data
S: To: "Andrew Stobes" <astobes@tailspintoys.com>
S: From: "Woodgrove Bank Security" <security@woodgrovebank.com>
S: Subject: Woodgrove Bank - Action required
S:
S: Greetings User,
S:
S: We need to verify your banking details.
S: Please click the following link to verify that Microsoft has the right information for your account.
S:
S: https://short.url/woodgrovebank/updateaccount/12-121.aspx
S:
S: Thank you,
S: Woodgrove Bank
S: .

在此文字記錄中，寄件者地址如下：

來自位址 (5321.MailFrom) ： phish@phishing.contoso.com
從位址 (5322.From) ： security@woodgrovebank.com

如果您已設定 SPF，則接收伺服器會對來自位址 phish@phishing.contoso.com 的郵件進行檢查。如果郵件是來自網域 phishing.contoso.com 的有效來源，則 SPF 檢查會通過。由於電子郵件用戶端只會顯示寄件者位址，因此使用者會看到此訊息來自 security@woodgrovebank.com 。如果單獨使用 SPF，則一律不會驗證 woodgrovebank.com 的有效性。

若您使用 DMARC，則接收方伺服器也會針對寄件者地址執行檢查。在上述案例中，如果 woodgrovebank.com 有 DMARC TXT 記錄，則對寄件者地址的檢查不會通過。

什麼是 DMARC TXT 記錄？

如同 SPF 的 DNS 記錄，DMARC 的記錄是 DNS 文字 (TXT) 記錄，其有助於防止詐騙和網路釣魚。您在 DNS 中發佈 DMARC TXT 記錄。 DMARC TXT 記錄會根據宣稱為傳送網域的擁有者來驗證電子郵件作者的 IP 位址，藉以驗證電子郵件訊息的原始位置。 DMARC TXT 記錄可識別已獲授權的輸出電子郵件伺服器。目的地電子郵件系統接著會驗證收到的郵件是否來自於已獲授權的輸出電子郵件伺服器。

Microsoft 的 DMARC TXT 記錄看起來如下：

_dmarc.microsoft.com.   3600    IN      TXT     "v=DMARC1; p=none; pct=100; rua=mailto:d@rua.contoso.com; ruf=mailto:d@ruf.contoso.com; fo=1"

如需為 Microsoft 365 提供 DMARC 報告的協力廠商，請造訪 MISA 目錄。

為輸入郵件設定 DMARC

您不需要針對在 Microsoft 365 中收到的郵件執行任何動作來設定 DMARC。一切都已妥善處理。如果您想了解未通過 DMARC 檢查的郵件將會發生什麼事，請參閱 Microsoft 365 如何處理未通過 DMARC 的輸入電子郵件。

為 Microsoft 365 的輸出郵件設定 DMARC

如果您使用 Microsoft 365 但未使用自訂網域 (也就是您使用的是 onmicrosoft.com)，則系統已為您設定 SPF，且 Microsoft 365 會自動產生外寄郵件的 DKIM 簽章。(如需此簽章的詳細資訊，請參閱 DKIM 與 Microsoft 365 的預設行為)。若要為您的組織設定 DMARC，您必須為 onmicrosoft.com 網域建立DMARC TXT 記錄，並透過[Office 365 系統管理員中心> 設定 > 網域 > ] 將它發佈至 DNS，按一下 [onmicrosoft.com 網域 > 新增記錄]。

如果您有自訂網域或正在使用內部部署 Exchange 伺服器以及 Microsoft 365，則需要手動為輸出郵件設定 DMARC。為您的自訂網域設定 DMARC 包含下列步驟：

步驟 1：找出您網域的郵件有效來源
步驟 2：為網域設定 SPF
步驟 3：為自訂網域設定 DKIM
步驟 4：為網域形成 DMARC TXT 記錄

步驟 1：找出您網域的郵件有效來源

如果您已設定 SPF，則已完成此練習。 DMARC 還有一些其他考量。在識別您網域的郵件來源時，請回答以下兩個問題：

哪些 IP 位址會從我的網域傳送郵件？
針對由第三方代表我所傳送的郵件，5321.MailFrom 和 5322.From 網域相符嗎？

步驟 2：為網域設定 SPF

現在您有所有有效寄件者的清單，您可以按照步驟設定 SPF 以協助防止詐騙。

例如，假設 contoso.com 從 Exchange Online 傳送郵件，其為 IP 位址為 192.168.0.1 的內部部署 Exchange 伺服器和 IP 位址為 192.168.100.100 的 Web 應用程式，則 SPF TXT 記錄呈現如下：

contoso.com  IN  TXT  " v=spf1 ip4:192.168.0.1 ip4:192.168.100.100 include:spf.protection.outlook.com -all"

最佳作法是，請確定 SPF TXT 記錄包括第三方寄件者。

步驟 3：為自訂網域設定 DKIM

設定 SPF 後，您需要設定 DKIM。 DKIM 可讓您在郵件標頭中將數位簽章新增到電子郵件。如果您未設定 DKIM，而是允許 Microsoft 365 為您的網域使用預設 DKIM 設定，則 DMARC 可能會失敗。發生此失敗的原因是預設 DKIM 設定使用您的原始 onmicrosoft.com 網域作為 5321.MailFrom 位址，而非您的自訂網域。這會導致所有從您網域傳送的所有電子郵件中 5321.MailFrom 與 5322.From 地址不相符。

如果有代表您傳送郵件的第三方寄件者，且其傳送的郵件中 5321.MailFrom 和 5322.From 地址不相符，則該電子郵件的 DMARC 將會失敗。若要避免此問題，您必須特別針對第三方寄件者設定網域 DKIM。這可讓 Microsoft 365 驗證來自此協力廠商服務的電子郵件。不過，這也讓 Yahoo、Gmail 和 Comcast 等信箱可以驗證由第三方傳送給他們的電子郵件，如同由您所傳送的電子郵件。這十分有説明，因為它可讓您的客戶不論信箱位於何處，都與您的網域建立信任，同時 Microsoft 365 不會因為詐騙而將郵件標示為垃圾郵件，因為它會通過網域的驗證檢查。

有關為網域設定 DKIM 的相關指示，包括如何為第三方寄件者設定 DKIM 以避免詐騙網域，請參閱使用 DKIM 驗證從您的自訂網域傳送的輸出電子郵件。

步驟 4：為網域形成 DMARC TXT 記錄

雖然還有其他此處未提及的語法選項，以下是 Microsoft 365 最常使用的選項。以下列格式為您的網域形成 DMARC TXT 記錄：

_dmarc.domain  TTL  IN  TXT  "v=DMARC1; p=policy; pct=100"

其中：

網域是您想要保護的網域。根據預設，記錄會保護該網域及所有子網域的郵件。例如，如果您指定 _dmarc.contoso.com，DMARC 會保護此網域及所有子網域的郵件，例如 housewares.contoso.com 或 plumbing.contoso.com。
TTL 一律相當於一小時。 TTL 所使用的單位，無論是小時 (1 小時)、分鐘 (60 分鐘) 或秒 (3600 秒)，會取決於您的網域註冊機構。
pct=100 指出這項規則應 100% 用於電子郵件。
原則可指定若 DMARC 失敗時，您想要接收方伺服器遵循的原則。您可以將原則設定為 [無]、[隔離] 或 [拒絕]。

如需使用選項的相關資訊，請參閱在 Microsoft 365 中實作 DMARC 的最佳作法以熟悉概念。

範例:

原則設為 [無]

_dmarc.contoso.com 3600 IN  TXT  "v=DMARC1; p=none"

原則設為 [隔離]

_dmarc.contoso.com 3600 IN  TXT  "v=DMARC1; p=quarantine"

原則設為 [拒絕]

_dmarc.contoso.com  3600 IN  TXT  "v=DMARC1; p=reject"

一旦您已形成記錄，您需要在網域註冊機構中更新記錄。

DMARC 郵件

注意

郵件可能不會每天寄出。

在此範例中，DMARC TXT 記錄： dmarc.microsoft.com. 3600 IN TXT "v=DMARC1; p=none; pct=100; rua=mailto:d@rua.example.com; ruf=mailto:d@ruf.example.com; fo=1" ，您可以看到 rua 位址。此位址用來傳送用於分析的「匯總意見反應」，用來產生報表。

提示

請瀏覽 MISA 目錄，以檢視更多為 Microsoft 365 提供 DMARC 報告的協力廠商。請參閱 IETF.org 的「以網域為基礎的郵件驗證、報告和符合性 (DMARC)」，以取得 DMARC 'rua' 位址詳細資訊。

在 Microsoft 365 中實作 DMARC 的最佳作法

您可以逐步實作 DMARC，而不影響郵件流程的其餘部分。建立並實作遵循這些步驟的推出計畫。首先在子網域執行這些步驟，然後是其他子網域，最後是組織中的頂層網域，再移至下一個步驟。

監控實作 DMARC 的影響

從簡易的監視模式記錄開始，其可用於子網域或要求 DMARC 接收器向您傳送使用該網域的郵件相關統計資料之網域。監視模式記錄是已將原則設為無 (p=無) 的 DMARC TXT 記錄。許多公司發佈 p=無的 DMARC TXT 記錄，是由於其不確定發佈限制較嚴格的 DMARC 原則可能會損失多少電子郵件。

即使在您實作 SPF 或 DKIM 於郵件基礎結構之前，您即可這麼做。不過，如此將無法有效使用 DMARC 來隔離或拒絕郵件，直到您也同時實作 SPF 和 DKIM。當您引入 SPF 和 DKIM，透過 DMARC 所產生的報告將給出通過這些檢查的郵件數量和來源，以及那些沒有通過這些檢查的消息。您可以輕鬆查看有多少合法傳輸被其涵蓋或未涵蓋，並對問題進行疑難排解。您也會開始看到詐騙郵件傳出的數量，以及郵件的傳出位置。
要求外部郵件系統隔離未通過 DMARC 的郵件

當您相信您所有或大部分的合法傳輸都受到 SPF 及 DKIM 的保護，且您了解實作 DMARC 的影響後，您可以實作隔離原則。隔離原則是已將原則設為隔離 (p=隔離) 的 DMARC TXT 記錄。執行此動作即是要求 DMARC 接收器將來自您網域中未通過 DMARC 的郵件放至本機相等於垃圾郵件的資料夾，而不是客戶的收件匣。
要求外部郵件系統不接受未通過 DMARC 的郵件

最後一個步驟是實作拒絕原則。拒絕原則是已將原則設為拒絕 (p=拒絕) 的 DMARC TXT 記錄。執行此動作即是要求 DMARC 接收器不接受未通過 DMARC 檢查的郵件。
如何設定適用於子網域的 DMARC？

DMARC 的實作方式是將原則發佈為 DNS 中的 TXT 記錄，而且是階層式 (例如，針對 contoso.com 發佈的原則會套用至 sub.domain.contoso.com，除非已針對子域) 明確定義不同的原則。由於組織可能只能指定較少量的高層 DMARC 記錄，所以在覆蓋較廣的層面上，這很實用。如果您不想讓子網域承襲頂層網域的 DMARC 記錄，則須小心謹慎地設定明確的子網域 DMARC 記錄。

此外，當子網域不應傳送電子郵件時，您可以透過新增 [sp=reject] 值，以為 DMARC 新增萬用字元類型原則。例如：
```
_dmarc.contoso.com. TXT "v=DMARC1; p=reject; sp=reject; ruf=mailto:authfail@contoso.com; rua=mailto:aggrep@contoso.com"
```

Microsoft 365 如何處理未通過 DMARC 的輸出電子郵件

如果郵件從 Microsoft 365 輸出且未通過 DMARC，而您已將原則設為 p=隔離或 p=拒絕，則該郵件會透過輸出郵件的較高風險傳遞集區路由傳送。輸出電子郵件不可覆寫。

如果您發佈 DMARC 拒絕原則 (p=拒絕)，Microsoft 365 中的其他客戶將無法詐騙您的網域，因為透過服務轉送輸出郵件時，郵件無法通過您網域的 SPF 或 DKIM。不過，如果您確實發佈 DMARC 拒絕原則，但未透過 Microsoft 365 驗證所有電子郵件，某些輸入電子郵件可能會被標示為垃圾郵件 (如上所述)，或如果您未發佈 SPF 並嘗試透過服務轉送輸出，則郵件會被拒絕。例如，在形成 DMARC TXT 記錄時，如果您忘記包含某些代表您網域傳送郵件的伺服器及應用程式之 IP 位址，就會發生這種情況。

Microsoft 365 如何處理未通過 DMARC 的輸入電子郵件

如果傳送伺服器的 DMARC 原則是 p=reject，則 Exchange Online Protection (EOP) 會將郵件標示為詐騙郵件，而不是拒絕此郵件。換句話說，針對輸入電子郵件，Microsoft 365 會以相同的方式處理 p=reject 和 p=quarantine。系統管理員可以定義對防網路釣魚原則內分類為詐騙的郵件執行的動作。

Microsoft 365 如此設定，是因為某些合法的電子郵件可能無法通過 DMARC。比方說，如果郵件傳送至郵寄清單，然後再將郵件轉送至清單中的所有參與者，則此郵件可能無法通過 DMARC。如果 Microsoft 365 拒絕這些郵件，可能會遺失合法的電子郵件，而且無法再擷取回來。相反地，這些郵件仍無法通過 DMARC，但其會標示為垃圾郵件而不會被拒絕。如有需要，使用者仍可在收件匣中透過下列方法取得這些郵件：

使用者使用電子郵件用戶端來個別新增安全寄件者。
系統管理員可以使用詐騙詐騙深入解析或租用戶允許/封鎖清單，來允許來自偽造寄件者的郵件。
系統管理員為所有使用者建立 Exchange 郵件流程規則 (也稱為傳輸規則)，以允許這些特定寄件者的郵件。

如需詳細資訊，請參閱建立安全寄件者清單。

Microsoft 365 如何使用已驗證接收鏈結 (ARC)

所有 Microsoft 365 中託管的信箱現在都將取得 ARC 帶來的改良式郵件傳送，以及增強式反詐騙防護的權益。當電子郵件從原始伺服器路由傳送到收件者信箱時，ARC 會保留來自所有參與中繼或躍點的電子郵件驗證結果。在 ARC 之前，透過電子郵件路由傳送中的中繼所執行的修改，(例如轉寄規則或自動簽署)，可能在郵件到達收件者信箱時導致 DMARC 失敗。使用 ARC，Microsoft 365 可利用其驗證結果的加密保留確認電子郵件寄件者。

Microsoft 身為 ARC 密封者，因此 Microsoft 365 目前是使用 ARC 來確認驗證結果，但計畫在未來新增協力廠商 ARC 密封者的支援。

對 DMARC 實作進行疑難排解

如果您已設定網域的 MX 記錄，其中 EOP 並非第一個項目，則不會對您的網域強制 DMARC 失敗。

如果您是客戶，且您網域的主要 MX 記錄未指向 EOP，則您不會取得 DMARC 的效益。比方說，如果您將 MX 記錄指向內部部署郵件伺服器，並使用連接器將電子郵件路由傳送至 EOP，則不適用 DMARC。在此案例中，接收方網域是您其中一個公認的網域，但 EOP 不是主要的 MX。例如，假設 contoso.com 將其 MX 指向本身，並使用 EOP 作為次要 MX 記錄，contoso.com 的 MX 記錄會如下所示：

contoso.com     3600   IN  MX  0  mail.contoso.com
contoso.com     3600   IN  MX  10 contoso-com.mail.protection.outlook.com

所有或大部分的電子郵件首先會路由至 mail.contoso.com，因為它是主要的 MX，然後才會將郵件路由至 EOP。在某些情況下，您甚至可能不會將 EOP 列為 MX 記錄，而只要接上連接器來傳送電子郵件。 EOP 不必是第一個項目，DMARC 驗證也可完成。它只是可確保驗證，以確定所有內部部署/非 O365 伺服器會執行 DMARC 檢查。設定 DMARC TXT 記錄時，就能為客戶的網域 (非伺服器) 強制執行 DMARC，但實際上執行強制執行是由接收端伺服器執行。如果您將 EOP 設定為接收端伺服器，則 EOP 會執行 DMARC 強制執行。