本文為機器翻譯文章。如需檢視英文版,請選取 [原文] 核取方塊。您也可以將滑鼠指標移到文字上,即可在快顯視窗顯示英文原文。
譯文
原文

使用 DMARC 來驗證 Office 365 中的電子郵件

Exchange Online
 

上次修改主題的時間:2016-12-09

網域式訊息驗證、 報告和符合性 (DMARC)適用於傳送者原則架構 (SPF) 和 DomainKeys 找出郵件 (DKIM) 以進行驗證郵件寄件者,並確定目的地電子郵件系統信任來自您網域傳送的郵件。實作與 SPF 和 DKIM DMARC 提供其他保護詐騙和網路釣魚電子郵件。DMARC 協助接收的郵件系統決定如何處理郵件會從您網域傳送未通過 SPF 或 DKIM 檢查。

電子郵件訊息可能包含多個的建立者或寄件者地址。這些地址會用於其他用途。例如,請考慮下列位址:

  • "Mail From 」 地址會識別寄件者並指定要傳送傳回通知訊息,例如未傳遞通知傳送發生任何問題的位置。這會出現在電子郵件訊息的信封部分,而且通常不會顯示電子郵件應用程式。有時稱為5321.MailFrom 地址] 或 [反向路徑地址

  • "From 」 地址郵件應用程式所顯示 From 地址的地址。這個位址會識別作者的電子郵件。也就是信箱的人員或負責的系統 撰寫郵件。此有時稱為5322.From 地址

SPF 使用 DNS 的 TXT 記錄指定網域提供授權的傳送端 IP 位址清單。一般而言,SPF 檢查僅會執行對 5321.MailFrom 地址。這表示的 5322.From 地址未經過驗證時使用 SPF 本身。這可讓使用者可以在何處取得郵件通過 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 we have the right information for your account.
S: 
S: http://short.url/woodgrovebank/updateaccount/12-121.aspx
S:
S: Thank you,
S: Woodgrove Bank
S: .

在此記錄、 寄件者地址如下:

  • 郵件的地址 (5322.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 時,接收伺服器也會執行對 From 地址進行檢查。在上述範例中,位置 woodgrovebank.com,DMARC TXT 記錄時再對 From 地址] 核取失敗。

SPF DNS 記錄,例如 DMARC 的記錄是 DNS 文字 (TXT) 記錄,以協助防止詐騙和網路釣魚。您在 DNS 中發佈 DMARC TXT 記錄。DMARC TXT 記錄來驗證對 alleged 擁有人的傳送端網域的電子郵件作者的 IP 位址驗證電子郵件訊息的原點而言。 DMARC TXT 記錄會識別授權的外寄電子郵件伺服器。目的地的電子郵件系統可以然後確認他們收到的郵件來自已授權的外寄電子郵件伺服器。

Microsoft 的 DMARC TXT 記錄會類似如下:

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

Microsoft 會傳送其 DMARC 報告Agari、 第 3 協力廠商。 Agari 收集和分析 DMARC 報告。

您不需要執行設定 DMARC 收到 Office 365 中的郵件的事情。我們已經為您處理的每個項目。如果您想要了解有什麼至郵件的傳遞我們 DMARC 檢查,請參閱如何在 Office 365 控點輸入電子郵件的失敗 DMARC失敗。

如果您使用 Office 365,但不使用自訂的網域,也就是使用 onmicrosoft.com,您不需要執行任何動作來設定或您的組織實作 DMARC。已設定 SPF 與 Office 365 會自動產生 DKIM 簽章的撥出的郵件。如需此簽章的詳細資訊,請參閱預設 DKIM 與 Office 365 的行為

如果您已自訂的網域或使用除了 Office 365 的內部部署 Exchange 伺服器,必須以手動方式實作 DMARC 輸出郵件。自訂網域實作 DMARC 包含下列步驟:

如果您已經設定 SPF 然後您已經完成此練習。不過,對於 DMARC、 有其他考量。識別網域的郵件的來源時有兩個必須回答的問題:

  • 哪些 IP 位址從我的網域傳送郵件?

  • 傳送之郵件的協力廠商提供我代理,將 5321.MailFrom 和 5322.From 的網域相符吗?

既然您擁有的所有您有效寄件者清單您可以遵循的步驟來在 Office 365 中設定 SPF 以協助防止詐騙

例如,假設 contoso.com 將郵件從內部部署 Exchange 伺服器的 IP 位址為 192.168.0.1,與 web 應用程式的 IP 位址是 192.168.100.100、 Exchange Online、 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 記錄會將帳戶協力廠商的寄件者。

一旦您已設定好 SPF,您需要 DKIM 設定。DKIM 可讓您將數位簽章新增至郵件標頭中的電子郵件訊息。如果您不要設定 DKIM 並改用允許預設 DKIM 設定用於您的網域的 Office 365、 DMARC 可能會失敗。這是因為預設 DKIM 組態 5322.From 地址不自訂網域使用初始 onmicrosoft.com 網域。這會強制 5321.MailFrom 與中所有的電子郵件從您網域傳送的 5322.From 地址不符。

如果您已在代理傳送者信箱的第三方寄並傳送的郵件已不相符的 5321.MailFrom 5322.From 地址,DMARC 將失敗的電子郵件。若要避免發生這種情況,您必須為您特別搭配的協力廠商傳送者的網域設定 DKIM。這可讓驗證電子郵件從這個第 3 廠商服務 Office 365。 不過,它也可讓其他人,例如 Yahoo、 Gmail,並 Comcast、 確認電子郵件傳送給他們的協力廠商好像它是您所傳送的電子郵件。這是有用因為它可讓您建立信任關係不論其信箱所在網域的客戶及同時 Office 365 將不會將郵件標示為垃圾郵件因為詐騙因為其通過驗證檢查網域。

如需設定您的網域,包括如何設定 DKIM 協力廠商的寄件者,以讓他們可以詐騙網域,DKIM 指示請參閱 < 使用 DKIM 驗證從您在 Office 365 中的自訂網域傳送的輸出電子郵件

雖然這裡未提及其他語法選項,但是這些是 Office 365 的最常用的選項。表單以格式網域 DMARC TXT 記錄:

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

其中:

  • 網域是您想要保護的網域。根據預設,記錄會從網域和所有子網域保護郵件。例如,如果您指定 _dmarc.contoso.com,然後 DMARC 保護郵件來自網域和所有子網域,例如 housewares.contoso.com 或 plumbing.contoso.com。

  • TTL應該永遠為相當於一小時。TTL,其中一個小時 (1 小時) 所使用的單位分 (60 分鐘) 或秒 (3600 秒) 目視網域登錄器。

  • pct = 100 表示此規則應用於電子郵件的 100%。

  • 原則會指定要接收伺服器來追蹤 DMARC 失敗時哪些原則。您可以將原則設定為 none、 隔離或拒絕。

如需使用哪些選項,熟悉中實作 DMARC Office 365 中的最佳作法的概念。

範例:

原則設定成 [無

_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"

一旦您已建立您的記錄,您需要更新在網域註冊機構的記錄。如需 Office 365 將 DMARC TXT 記錄新增至 DNS 記錄的指示,請參閱Office 365 管理 DNS 記錄時建立 DNS 記錄

您可以逐漸實作 DMARC 而不會影響其餘的郵件流程。建立及實作推展遵循這些步驟的計劃。運用以上各個步驟前一個子網域,則其他子網域,最後才使用移至下一個步驟之前在組織中的最上層網域。

  1. 監視實作 DMARC 的影響

    開始使用 「 簡單 」監視模式記錄要求的 DMARC 接收器傳送給您時請參閱使用該網域的郵件相關的統計資料的網域或子網域。監控模式記錄是已設定成 [無其原則的 DMARC TXT 記錄 (p = none)。許多公司發佈 DMARC TXT 記錄與 p = none 因為其不確定符合關於多少電子郵件時可能會遺失所發佈的更嚴格的 DMARC 原則。

    即使您已經訊息基礎結構中實作 SPF 或 DKIM 之前您可以這麼做。不過,您將不能夠有效地隔離或使用 DMARC 直到也實作 SPF 及 DKIM 拒絕郵件。為您引進 SPF 與 DKIM,透過 DMARC 產生的報告會提供號碼和這些檢查及的未傳遞的郵件的來源。您可以輕鬆看見合法的流量中有多少是或並未涵蓋它們,以及排解問題。您也將開始查看多少詐騙郵件寄往,並從何處。

  2. 要求外部郵件系統隔離失敗 DMARC 的郵件

    當您認為的所有或大部分的合法的流量會受到 SPF 及 DKIM,且您了解實作 DMARC 的影響時,您可以實作隔離原則。隔離原則是已設為隔離其原則的 DMARC TXT 記錄 (p = 隔離)。依照此您提出失敗 DMARC 到本機相當於 [垃圾郵件] 資料夾,而不是客戶的收件匣的 DMARC 接收器放來自您網域的郵件。

  3. 要求外部郵件系統不接受失敗 DMARC 的郵件

    最後一個步驟實作拒絕原則。拒絕原則是已設為拒絕其原則的 DMARC TXT 記錄 (p = reject)。當您這麼做時,您要求 DMARC 接收器不以接受失敗 DMARC 檢查的郵件。

如果郵件是從 Office 365 輸出和失敗 DMARC,且您已將原則設定為 p = 隔離或 p = 拒絕,透過外寄郵件的高風險傳遞集區路由傳送郵件。沒有任何覆寫的外寄電子郵件。

如果您發佈 DMARC 拒絕原則 (p = 拒絕),因為郵件無法傳遞 SPF 或 DKIM 網域時轉送訊息透過此服務 Office 365 中的任何其他客戶可以詐騙網域。 不過,如果您不要發佈 DMARC 拒絕原則,但不具有電子郵件的所有經過驗證透過 Office 365 的某些部分可能會標示為垃圾郵件的內送電子郵件 (述上方),或如果您不發佈 SPF 並嘗試以轉送輸出透過此服務會被拒絕。 發生這種情況,例如,如果您忘記要包含的伺服器和應用程式的表單 DMARC TXT 記錄時,代表您的網域傳送郵件的 IP 位址部分。

如果傳送伺服器 DMARC 原則是 p = 拒絕,EOP 會將郵件標示為而拒絕它不是垃圾郵件。換句話說,如內送電子郵件、 Office 365 來說 p = 拒絕和 p = 隔離相同的方式。

由於某些合法電子郵件可能會失敗 DMARC office 365 設定類似。例如,郵件可能會失敗 DMARC 傳送到接著會轉送至清單中的所有參與者訊息郵寄清單。如果 Office 365 拒絕這些訊息、 人員無法失去合法電子郵件與已擷取其因而。 但是,這些訊息還是會失敗 DMARC 但將標記為垃圾並不會拒絕。若有需要,使用者可以仍屬這些訊息其收件匣中透過這些方法:

  • 使用者安全寄件者個別新增使用其電子郵件用戶端

  • 系統管理員建立 Exchange 傳輸規則 (ETR) 允許這些特定的寄件者的郵件的所有使用者。

如果您已設定網域的 MX 記錄其中 EOP 不是第一個項目、 DMARC 失敗將未強制執行為您的網域。

如果您是 Office 365 客戶,而且您的網域主要 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

All、 或最多只電子郵件將第一次會路由傳送到 mail.contoso.com 自主要 MX,且郵件會取得路由傳送至 EOP。在某些情況下,可能不甚至是列為進行封鎖 EOP MX 記錄所有及向上連接器路由傳送電子郵件只是連接資訊。EOP 必須是網域的 MX 記錄以您網域的強制執行 DMARC 失敗的順序中的第一個項目。

想 DMARC 的詳細資訊嗎?這些資源可以幫助。

 
顯示: