共用方式為

SMTP DNS 型命名實體識別驗證 (DANE) 如何運作

  • 發行項

SMTP 通訊協定是用來在郵件伺服器之間傳輸郵件的主要通訊協定，根據預設，並不安全。 傳輸層安全性 (TLS) 通訊協定是在數年前引進，以支援郵件的 SMTP 加密傳輸。 它通常被投機地加以使用，而非作為一種要求方式使用，並留下大量的清晰文本的電子郵件流量，很容易被不法分子截獲。 此外，SMTP 會透過公用 DNS 基礎結構決定目的地伺服器的 IP 位址，此基礎結構容易受到詐騙和中間人 (MITM) 攻擊。 此弱點導致建立許多新標準，以提高傳送和接收電子郵件的安全性，其中一項標準是以 DNS 為基礎的具名實體驗證， (DANE) 。

DANE for SMTP RFC 7672 會使用傳輸層安全性驗證 (網域 DNS 記錄集中的 TLSA) 記錄來發出網域訊號，而其郵件伺服器支援 DANE。 如果沒有 TLSA 記錄，則郵件流程的 DNS 解析會如往常般運作，而不會嘗試任何 DANE 檢查。 TLSA 記錄會安全地發出 TLS 支援訊號，並發布網域的 DANE 原則。 因此，傳送郵件伺服器可以成功驗證使用 SMTP DANE 的合法接收郵件伺服器。 此驗證可讓您抵禦降級和MITM攻擊。 DANE 對 DNSSEC 有直接相依性，DNSSEC 是使用公開金鑰密碼處理進行 DNS 查詢的數位簽署記錄。 DNSSEC 檢查會發生在遞迴 DNS 解析程式上，這是對用戶端進行 DNS 查詢的 DNS 伺服器。 DNSSEC 可確保 DNS 記錄不會遭到竄改且為驗證。

當網域的 MX、A/AAAA 和 DNSSEC 相關資源記錄以 DNSSEC 驗證方式傳回給 DNS 遞歸解析程式之後，傳送郵件伺服器會要求對應至 MX 主機專案或專案的 TLSA 記錄。 如果 TLSA 記錄存在，且已使用另一個 DNSSEC 檢查進行驗證，DNS 遞歸解析程式會將 TLSA 記錄傳回給傳送郵件伺服器。

收到驗證 TLSA 記錄之後，傳送的郵件伺服器會建立與驗證 TLSA 記錄相關聯之 MX 主機的 SMTP 連線。 傳送郵件伺服器會嘗試設定 TLS，並將伺服器的 TLS 憑證與 TLSA 記錄中的數據進行比較，以驗證連線到寄件者的目的地郵件伺服器是否為合法的接收郵件伺服器。 如果驗證成功，則會使用 TLS) (傳輸訊息。 當驗證失敗或目的地伺服器不支援 TLS 時，Exchange Online 會從相同目的地網域的 DNS 查詢開始，於 15 分鐘後再試一次整個驗證程式，之後 15 分鐘，然後在接下來 24 小時內每小時重試一次。 如果在重試 24 小時後驗證持續失敗，訊息將會過期，且會產生具有錯誤詳細數據的 NDR 並傳送給寄件者。

DANE 的元件是什麼？

TLSA 資源記錄

TLS 驗證 (TLSA) 記錄可用來將伺服器的 X.509 憑證或公鑰值與包含記錄的功能變數名稱產生關聯。 只有在您的網域上啟用 DNSSEC 時，才能信任 TLSA 記錄。 如果您使用 DNS 提供者來裝載網域，DNSSEC 可能是使用網域進行設定時所提供的設定。 若要深入瞭解 DNSSEC 區域簽署，請瀏覽此連結：[DNSSEC 概覽|Microsoft Docs]。

範例 TLSA 記錄：

顯示TLSA記錄範例的螢幕快照。

TLSA 記錄類型有四個唯一的可設定欄位：

憑證使用狀況欄位：指定傳送電子郵件伺服器應如何驗證目的地電子郵件伺服器的憑證。

值 縮略字 描述
01 PKIX-TA 使用的憑證是 X.509 信任鏈的信賴錨點公用 CA。
11 PKIX-EE 檢查的憑證是目的地伺服器；DNSSEC 檢查必須驗證其真實性。
2 DANE-TA 從 X.509 樹狀結構使用伺服器的私鑰，該密鑰必須由信任鏈結中的信任錨點驗證。 TLSA 記錄會指定用來驗證網域 TLS 憑證的信賴錨點。
3 DANE-EE 只與目的地伺服器的憑證相符。

1 Exchange Online 遵循 RFC 實作指引，在使用 SMTP 實作 DANE 時，不應該使用 0 或 1 的憑證使用字段值。 當憑證使用量域值為 0 或 1 的 TLSA 記錄傳回 Exchange Online 時，Exchange Online 將其視為無法使用。 如果發現所有 TLSA 記錄都無法使用，Exchange Online 在傳送電子郵件時將不會執行 0 或 1 的 DANE 驗證步驟。 相反地，由於 TLSA 記錄的存在，Exchange Online 會強制使用 TLS 來傳送電子郵件、如果目的地電子郵件伺服器支援 TLS，則傳送電子郵件，或在目的地電子郵件伺服器不支援 TLS 時卸除電子郵件併產生 NDR。

在範例 TLSA 記錄中，[憑證使用量] 字段設定為 '3'，因此憑證關聯數據 ('abc123...xyz789') 只會與目的地伺服器的憑證進行比對。

選取器欄位：指出應該檢查目的地伺服器憑證的哪些部分。

值 縮略字 描述
0 憑證 使用完整憑證。
1 SPKI (主體公開金鑰資訊) 使用憑證的公鑰，以及識別公鑰要使用的演算法。

在範例 TLSA 記錄中，選取器字段設定為 『1』，因此憑證關聯數據會使用目的地伺服器證書的公鑰和識別公鑰要使用的演算法進行比對。

比對類型欄位：指出憑證在 TLSA 記錄中表示的格式。

值 縮略字 描述
0 完整 TSLA 記錄的資料是完整憑證或 SPKI。
1 SHA-256 TSLA 記錄中的數據是憑證或SPKI的SHA-256哈希。
2 SHA-512 TSLA 記錄中的數據是憑證或SPKI的SHA-512哈希。

在範例 TLSA 記錄中，[比對類型] 字段設定為 『1』，因此憑證關聯數據是來自目的地伺服器證書之主體公鑰資訊的 SHA-256 哈希。

憑證關聯資料：指定用於與目的地伺服器憑證進行對比的憑證資料。 此資料取決於選取器欄位值和對比類型值。

在範例 TLSA 記錄中，憑證關聯數據會設定為 『abc123.。xyz789'。 由於範例中的選取器域值設定為 『1』，因此會參考目的地伺服器證書的公鑰，以及識別為與它搭配使用的演算法。 而且，因為範例中的 [比對類型] 域值設定為 '1'，它會從目的地伺服器證書參考主體公鑰資訊的 SHA-256 哈希。

根據 SMTP DANE 的 RFC 實作指南，建議使用由憑證使用狀況欄位設為 3、選取器欄位設為 1，以及將符合類型欄位設為 1 的 TLSA 記錄。

具有 SMTP DANE 的 Exchange Online 的郵件流程

使用 SMTP DANE Exchange Online 的郵件流程程式，如下列流程圖所示、透過 DNSSEC 驗證網域和資源記錄安全性、在目的地郵件伺服器上驗證 TLS 支援，以及目的地郵件伺服器的憑證符合根據其相關聯的 TLSA 記錄所預期的專案。

SMTP DANE 失敗只會導致電子郵件遭到封鎖的案例只有兩種：

  • 目的地網域發出 DNSSEC 支援訊號，但一或多個記錄因非真實而遭傳回。

  • 目的地網域的所有 MX 記錄都有 TLSA 記錄，而且目的地伺服器的憑證都不符合每個 TSLA 記錄數據的預期，或目的地伺服器不支援 TLS 連線。

    顯示具有 SMTP DANE 之 Exchange 在線郵件流程的螢幕快照。

技術 其他資訊
郵件傳輸代理程式 - 嚴格傳輸安全性 (MTA-STS) 提供設定網域原則的機制，以指定目的地電子郵件伺服器是否支援 TLS，以及無法交涉 TLS 時該怎麼做，例如停止傳輸，以協助抵禦降級和中間人攻擊。 有關 Exchange Online 即將推出輸入和輸出 MTA-STS 支援的詳細資訊，將於今年稍後發佈。

Microsoft Ignite 2020 的 Exchange Online Transport 新聞 - Microsoft 技術社群

rfc8461 (ietf.org)
寄件者原則架構 (SPF) 會使用 IP 資訊，以確保目的地電子郵件系統信任從自訂網域所送出的郵件。 傳送者原則架構如何 (SPF) 防止詐騙
網域金鑰識別郵件 (DKIM) 使用 X.509 憑證資訊，以確保目的地電子郵件系統會信任從您自訂網域對外傳送的郵件。 如何將 DKIM 用於自訂網域中的電子郵件
以網域為基礎的郵件驗證、報告和一致性 (DMARC) 搭配寄件者原則架構和網域金鑰識別郵件來驗證郵件寄件者，並確保目的地電子郵件系統信任您網域傳送的郵件。 使用 DMARC 來驗證電子郵件，設定步驟

含 DNSSEC 的輸入 SMTP DANE

必要條件

開始之前，請確定您符合下列必要條件：

  1. 您必須已將網域新增為「已接受的網域」，且網域狀態在 Microsoft 365 系統管理 中心內必須是「狀況良好」。 檔假設網域的 MX 記錄設為優先順序 0 或 10，而且沒有「後援」或次要 MX 記錄。 如果您有後援 MX 記錄，您必須與 Exchange Online 系統管理員密切合作，以確保變更正確執行。
  2. 若要獲得功能的完整安全性優點，請確定您已為網域啟用 DNSSEC。
  3. 您必須具有 Exchange Online PowerShell 的存取權，以及執行 PowerShell Exchange Online 所述 Cmdlet 的許可權
  4. 如果您想要使用輸入 SMTP DANE 搭配 DNSSEC 保護的網域是在任何 smarthost 組態或任何連接器中參考，您必須先將 smarthost 名稱切換為 tenantname.mail.protection.outlook.com ，再遵循步驟。

注意事項

如果您想要針對使用第三方閘道的網域啟用 DNSSEC，您可以遵循步驟 1 到 3，遵循第三方閘道上步驟 3 結尾的附注來執行此動作。

警告

如果您想要為「已接受的網域」設定具有 DNSSEC 的 contoso.com輸入 SMTP DANE，而且您的商務合作夥伴正在使用您端點的連接器 contoso-com.mail.protection.outlook.com ，您必須與合作夥伴合作，讓他們更新其連接器以參考 tenantname.onmicrosoft.com 端點或 tenantname.mail.protection.outlook.com 端點，然後再使用 DNSSEC 設定輸入 SMTP DANE。 否則，您的商務合作夥伴的連接器郵件會在您完成啟用後失敗。 完成啟用之後，您的合作夥伴可以使用新的 contoso-com.<random>.mx.microsoft 端點來重新建立原始連接器。

使用 DNSSEC 設定輸入 SMTP DANE

注意事項

DNS 記錄布建和更新可能需要一些時間才能完成。 由於多層快取，DNS 變更可能需要比預期更長的時間才能顯示。

若要使用 DNSSEC 設定輸入 SMTP DANE，請執行下列步驟：

  1. 將現有 MX 記錄的 TTL 更新為最低的 TTL 可能 (，但不可低於 30 秒) 。 然後，等候先前的 TTL 到期，再繼續進行。 例如，如果現有 MX 記錄的 TTL 在您變更前為 '3600 秒' 或 '1 小時'，您必須等候 1 小時，才能繼續進行步驟 2。

  2. 連線至 Exchange Online PowerShell。

    警告

    如果您使用 MTA-STS，則必須將原則模式設定為「測試」，並更新 MTA-STS txt 記錄中的識別符。 (您可以使用UTC中的目前時間做為新的原則ID.) 然後，等候原則的「max_age」到期，再繼續進行。 例如，如果現有 STS 原則的「max_age」在您變更之前是 3600 秒 或 1 小時 ，您必須等候「1 小時」再繼續進行。

  3. 針對您想要針對 DNSSEC 啟用 SMTP DANE 的網域，您必須先在網域上啟用 DNSSEC，方法是執行下列命令 (將 “domain” 取代為您選擇的網域名稱，例如，contosotest.com) ：

    Enable-DnssecForVerifiedDomain -DomainName <DomainName>

    注意事項

    此命令可能需要幾分鐘的時間才能執行。

    成功執行的範例輸出

    結果 DnssecMxValue ErrorData
    成功 contosotest-com.o-v1.mx.microsoft

    成功回應會提供網域的 MX 值。 這個值是您要使用 DNSSEC 啟用之網域的新 MX 記錄所指向的名稱。 例如，contosotest-com.o-v1.mx.microsoft。

  4. 採用 「DnssecMxValue」 值，流覽至裝載網域的 DNS 註冊機構、使用步驟 3 中傳回的值新增 MX 記錄、將 TTL 設定為最低的可能值 (但不低於 30 秒) ，然後將新 MX 記錄的優先順序設定為 20。

    注意事項

    如果您使用第三方電子郵件閘道，並想要使用此值作為第三方電子郵件閘道將傳送輸入郵件的新 Exchange Online 目標主機，請流覽至第三方的系統管理入口網站，更新第三方用來傳送至 Exchange Online 的目標智慧型主機，然後驗證「郵件流程可透過 DNSSEC 測試運作 (請確定您在測試輸入期間選取了 [DNSSEC 驗證]，而不是 [遠端連線分析器： 測試輸入] 中的 [DANE 驗證 [包括 DNSSEC]Microsoft ) ]“。 如果郵件如預期般流動，您不需要繼續遵循下列步驟。 如果您想要為此網域啟用 SMTP DANE，請跳至步驟 7。

    警告

    如果您使用 MTA-STS，請確定原則模式已設定為「測試」。 然後，刪除包含舊版 MX 記錄資訊的目前 mx 數據列，並將新的 FQDN 新增至 MTA-STS 原則檔案作為新的 mx 數據列。 然後，更新原則中的原則標識碼和 MTA-STS TXT 記錄 (您可以使用 UTC 中的目前時間作為新的原則識別碼) 。

  5. 藉由展開 [測試步驟] 並確認以 mx.microsoft 結尾的 Mail Exchanger 已成功測試，確認新的 MX 正在透過輸入 SMTP Email 測試 https://testconnectivity.microsoft.com/tests/O365InboundSmtp/input () 運作。 視 DNS 快取而定，您可能必須重試此測試。

    範例成功輸出

    顯示輸出範例的螢幕快照，該輸出會通知成功實作的程式。

  6. 將指向 mail.protection.outlook.com 的舊版 MX 優先順序從目前的優先順序變更為 30;變更步驟 3 中所建立 MX 記錄的優先順序，使其設定為優先順序 0 (最高優先順序) 。

  7. 刪除結尾為 「mail.protection.outlook.com」、“mail.eo.outlook.com” 或 “mail.protection.outlook.de” 的舊版 MX 記錄。 然後，將 mx.microsoft 結尾 MX 記錄的 TTL 更新為 3600 秒。 您可以選擇性地使用 DNSSEC 測試來確認一切如預期般運作 (確定您在測試輸入期間選取了 [DNSSEC 驗證]，而不是 遠端連線分析器中的 [DANE 驗證 [包括 DNSSEC]) ]。 視 DNS 快取和 TTL 而定，您可能必須重試此測試。

    舊版 MX 記錄上的 TTL 過期后，成功的輸出看起來會像這樣：

    顯示輸出範例的螢幕快照，通知網域已成功通過 DNSSEC 驗證測試。

  8. 如果您想要在 DNSSEC 啟用完成後為該相同網域啟用 SMTP DANE，請執行下列命令 [以您選擇的網域名稱取代 (DomainName) ，例如，contosotest.com]：

    Enable-SmtpDaneInbound -DomainName <DomainName>
    結果 ErrorData
    成功

  9. 使用您選擇的在線工具和Microsoft 遠端連線分析器：測試輸入，確認TLSA 記錄已傳播 (可能需要 15-30 分鐘) 。

    當您完成 DNSSEC 啟用，且 TLSA) (SMTP DANE 記錄已由 Exchange Online 布建之後，即會顯示成功的輸出，如下列螢幕快照所示：

    顯示輸出範例的螢幕快照，該輸出會通知網域已成功通過 Dane 驗證測試。

    Exchange Online裝載多個 TLSA 記錄，以提高 SMTP DANE 驗證成功的可靠性。 預期某些 TLSA 記錄可能會無法通過驗證。 只要有 1 筆 TLSA 記錄通過驗證，就會正確設定 SMTP DANE，並使用 SMTP DANE 保護電子郵件。

    警告

    如果您使用 MTA-STS，請在驗證原則是否正常運作且郵件如預期般流動之後，將原則模式設定回「強制執行」，並更新 MTA-STS txt 記錄中的識別符。 (您可以使用UTC中的目前時間作為新的原則ID.)

限制

  1. 病毒式或自助式註冊網域：使用 DNSSEC 的輸入 SMTP DANE 目前不支援設定為「自助」的網域。
  2. onmicrosoft.com 網域：使用 DNSSEC 的輸入 SMTP DANE 目前不支援租使用者的 'onmicrosoft.com' 網域。 我們正在調查針對 onmicrosoft.com 網域使用 DNSSEC 的輸入 SMTP DANE 支援;不過，ETA 未知。
  3. 第三方閘道：在接受租使用者郵件的輸入路徑 (上使用第三方電子郵件閘道的客戶會執行一些處理，然後將它轉送至 Exchange Online) 只有在第三方閘道支援具有 DNSSEC 驗證的 SMTP DANE 時，才能使用此功能來保護從第三方網關轉送至 Exchange Online 的電子郵件。 此設定中的客戶必須使用 Exchange PowerShell 設定具有 DNSSEC 的輸入 SMTP DANE。
  4. 其他與郵件流程的第三方整合：輸出路徑上有第三方網關的客戶，其中電子郵件會透過連接器傳送至第三方，第三方會執行一些處理，然後重新提交至 Exchange Online，最後 Exchange Online 傳送電子郵件。 啟用此功能時，這些客戶可能需要與其第三方提供者合作，以免中斷。 將電子郵件提交回 Exchange Online 時，第三方轉送必須使用 DNS 查閱，並使用在功能啟用期間建立的新 MX 記錄主機名 -> contoso-com. (子域) .mx.microsoft。 第三方「不應該」使用舊的 MX 記錄主機名 -> contoso-com.mail.protection.outlook.com 因為 Exchange Online 會在我們到達 GA 之後的 48) 小時內 (48 小時內刪除 A 記錄。
  5. 完全委派的網域：由Microsoft所裝載並使用NS委派的網域，讓Microsoft的名稱伺服器對網域具有權威性，並透過 DNSSEC 支援輸入 SMTP DANE。 我們打算針對這些網域支援具有 DNSSEC 的輸入 SMTP DANE;不過，ETA 未知。

使用 DNSSEC 啟用輸入 SMTP DANE 時所發生的偵錯問題

Enable/Disable-DnssecForVerifiedDomain 和 Enable/Disable-SmtpDane 輸入的問題

  1. DomainNotFound

    訊息 (DNSSEC) ：'DNSSEC 啟用/停用失敗，因為 AAD 中不存在網域 contoso.com。」
    SMTP DANE () 訊息 ：

    • 「SMTP DANE 啟用/停用失敗，因為網域 contoso.com 不存在於 AAD 中。」
    • 「SMTP DANE 啟用/停用失敗，因為在已接受的網域清單中找不到網域 contoso.com。」
      原因：在已接受的網域清單中找不到提供的網域。
      動作 () ：流覽至 Microsoft 365 系統管理 中心，並確定已向租用戶驗證網域。 如果 Microsoft 365 系統管理 中心內的網域狀況良好，請流覽至 Exchange 管理員 中心，並確定網域已新增為「已接受的網域」。

    DNSSEC

    結果 DnssecMxValue ErrorData
    錯誤 ErrorCode： 'DomainNotFound' ErrorDetails 'DNSSEC 啟用失敗...

    SMTP DANE

    結果 ErrorData
    錯誤 ErrorCode： 'DomainNotFound' ErrorDetails 'SMTP DANE 啟用...

  2. DnsSecOperationFailed

    訊息 (DNSSEC) ：『DNSSEC 啟用/停用失敗，因為 AdditionalErrorDetails。 稍後再重試作業。
    訊息 (SMTP DANE) ：SMTP DANE 啟用/停用失敗，因為 AdditionalErrorDetails。 稍後再重試作業。
    原因：嘗試建立適當的 DNS 區域和/或記錄失敗。
    動作 () ：嘗試重新執行 Cmdlet。

    DNSSEC

    結果 DnssecMxValue ErrorData
    錯誤 ErrorCode： 'DnssecOperationFailed' ErrorDetails 'DNSSEC 啟用失敗...

    SMTP DANE

    結果 ErrorData
    錯誤 ErrorCode： 'DnssecOperationFailed' ErrorDetails 'SMTP DANE 啟用...

  3. PartitionNotFound

    SMTP DANE (訊息) ：「SMTP DANE 啟用/停用失敗，因為網域 contoso.com 沒有數據分割。」
    原因：網域未啟用 DNSSEC。
    動作 () ：確定您使用已啟用 DNSSEC 的網域。

    結果 ErrorData
    錯誤 ErrorCode： 'PartitionNotFound' ErrorDetails 'SMTP DANE 啟用

  4. DomainNotSupported

    訊息 (DNSSEC) ：'指定的網域是 onmicrosoft 網域：contoso-com.onmicrosoft.com。'
    SMTP DANE (訊息) ：'指定的網域是 onmicrosoft 網域：contoso-com.onmicrosoft.com。'
    原因：網域是初始或MOERA網域。 目前不支援這些專案。
    動作 (的) ：確定您使用的網域結尾不是 『onmicrosoft.com』。

    DNSSEC

    結果 DnssecMxValue ErrorData
    錯誤 ErrorCode： 'DomainNotSupported' ErrorDetails 'The specified domain ...

    SMTP DANE

    結果 ErrorData
    錯誤 ErrorCode： 'DomainNotSupported' ErrorDetails 'The specified domain ...
Get-DnssecStatusForVerifiedDomain 的問題

  1. 訊息：'EG001： 無法擷取網域 [{domain}] 的 DNSSEC 功能狀態。'
    原因：在 Exchange Online 中驗證網域的設定時，我們發現網域尚未新增至 Exchange Online。 如果您認為您已將此網域新增至 Exchange Online，請重試執行 Cmdlet，因為這可能是暫時性問題。
    動作 (要採取的) ：重試 Cmdlet。 如果持續失敗，請流覽至 Microsoft 365 系統管理 中心，並完成此網域的設定程式。

  2. 訊息：'EG002： 網域 [{domain}] 未驗證組織的網域。
    原因：在 Exchange Online 中驗證網域的設定時，我們發現網域已新增至 Exchange Online 但尚未驗證。
    動作 () ：流覽至 Microsoft 365 系統管理 中心，並完成此網域的設定和驗證程式。

  3. 訊息：「取得 [{domain}] 網域的 MX 記錄時發生 DNS 查詢錯誤。」
    原因：在 DNS 驗證期間，我們在查詢網域時收到一般 DNS 失敗。
    動作 () ：重試執行 Cmdlet。 您可能需要檢閱您嘗試使用 SMTP DANE 搭配 DNSSEC 啟用之網域的設定。

  4. 訊息：找不到網域 [{domain}]。'
    原因：在 DNS 驗證期間，我們在查詢網域時收到 NXDOMAIN 失敗。
    動作 (的) ：在驗證網域的 MX 記錄組態之後，重試執行 Cmdlet。 某些 DNS 提供者最多可能需要 48 小時的時間進行 DNS 傳播。

  5. 訊息：找到 'ED003： Domain [{domain}]。 找不到任何驗證的 MX 記錄。'
    原因：在 DNSSEC 驗證期間，我們找不到解析為 DNSSEC 保護 A 記錄的 MX 記錄， (MX 記錄) 的 'hostname' 值的 A 記錄。
    動作 (的) ：在驗證網域的 MX 記錄組態之後，重試執行 Cmdlet。 某些 DNS 提供者最多可能需要 48 小時的時間進行 DNS 傳播。

  6. 訊息：'EX002：MX 記錄的值不符合預期的值。'
    原因：在 MX 驗證期間，我們找不到符合預期記錄的 MX 記錄。
    動作 () ：檢閱您網域中的 MX 記錄。 請確定一筆 MX 記錄符合執行 或 Get-DnssecStatusForVerifiedDomain之後Enable-DnssecForVerifiedDomain輸出的預期記錄。

  7. 訊息：「EX003：MX 記錄的優先順序不符合預期的優先順序。」
    原因：在 MX 驗證期間，我們發現預期的 MX 記錄，但其優先順序未設定為 0。
    動作 (的) ：設定 MX 記錄 (包含執行Enable-DnssecForVerifiedDomainGet-DnssecStatusForVerifiedDomain或) 時傳回的值為優先順序 0。

  8. 訊息：「EX004：有不同的 MX 記錄，其喜好設定與預期的相同。」
    原因：在 MX 驗證期間，我們發現最高優先順序的 MX 記錄不是預期的 MX 記錄。
    動作 () 採取：如果您已完成使用 DNSSEC 設定輸入 SMTP DANE 的步驟 1 到 4，請切換 MX 記錄的優先順序以完成步驟 5 和 6，讓預期的 MX 為 0 (最高優先順序) 、驗證設定，然後刪除舊版 MX 記錄。

  9. 訊息：「EX005：有不同的 MX 記錄喜好設定低於預期的 MX 記錄。」
    原因：在 MX 驗證期間，我們發現網域的 MX 記錄不符合預期的 MX 記錄。
    動作 () 採取：如果您已完成使用 DNSSEC 設定輸入 SMTP DANE 的步驟 1 到 5，請刪除舊版 MX 記錄來完成步驟 6。

  10. 訊息：「EX006：有不同的 MX 記錄喜好設定高於預期的 MX 記錄。」
    原因：在 MX 驗證期間，我們發現不同 MX 記錄的喜好設定高於預期的 MX 記錄。
    動作 () ：將舊版 MX 記錄 (以 mail.protection.outlook.com、 mail.eo.outlook.com 或 mail.protection.outlook.de) 結尾設為優先順序 20。

  11. 訊息：'EX007：找不到 MX 記錄。'
    原因：在 MX 驗證期間，我們找不到符合預期記錄的 MX 記錄。
    動作 () ：檢閱您網域中的 MX 記錄。 請確定一個 MX 記錄符合執行 或 Get-DnssecStatusForVerifiedDomain之後Enable-DnssecForVerifiedDomain輸出的預期記錄。

  12. 訊息：「EX008：找到正確的 MX 記錄，但喜好設定低於預期。」
    原因：在 MX 驗證期間，我們發現預期的 MX 記錄具有錯誤的優先順序。
    動作 () ：設定 MX 記錄 (包含執行 Enable-DnssecForVerifiedDomain 時傳回的值，或 Get-DnssecStatusForVerifiedDomain) 為優先順序 0。

  13. 訊息：'EX009：找到正確的 MX 記錄，但喜好設定高於預期。'
    原因：在 MX 驗證期間，我們發現預期的 MX 記錄具有錯誤的優先順序。
    動作 () ：設定 MX 記錄 (包含執行 Enable-DnssecForVerifiedDomain 時傳回的值，或 Get-DnssecStatusForVerifiedDomain) 為優先順序 0。

  14. 訊息： 'EX010： 搜尋網域 [{domain}] 的 MX 記錄時發生未知的錯誤。」
    原因：在 MX 驗證期間，我們遇到一般 DNS 錯誤。
    動作 (的) ：在驗證網域的 MX 記錄組態之後，重試執行 Cmdlet。 某些 DNS 提供者最多可能需要 48 小時的時間進行 DNS 傳播。

  15. 訊息：'EX012： 找不到網域 [{domain}] 的 MX 記錄。'
    原因：在 MX 驗證期間，我們找不到符合預期記錄的 MX 記錄。
    動作 () ：檢閱您網域中的 MX 記錄。 請確定一個 MX 記錄符合執行 或 Get-DnssecStatusForVerifiedDomain之後Enable-DnssecForVerifiedDomain輸出的預期記錄。

  16. 訊息：'EX013： 網域 [{domain}]] 的 MX 記錄未知。
    原因：在 MX 驗證期間，我們找不到符合預期記錄的 MX 記錄。
    動作 () ：檢閱您網域中的 MX 記錄。 請確定一個 MX 記錄符合執行 或 Get-DnssecStatusForVerifiedDomain之後Enable-DnssecForVerifiedDomain輸出的預期記錄。

  17. 訊息：'ES001：當模式為 ''enforced' 時，原則中預期遺漏 MX 記錄。」
    原因：在 MTA-STS 驗證期間，我們找不到符合您預期記錄的 mx 值。
    動作 () ：設定要測試的 MTA-STS 原則模式;然後，新增 mxhostname 值 (在 MTA-STS 原則中執行或 Get-DnssecStatusForVerifiedDomain) 為數據列時Enable-DnssecForVerifiedDomain傳回。

  18. 訊息：『ES002：找不到與原則比較的預期 MX 記錄。 先啟用網域 [{domain}] 的 DNSSEC 功能。'
    原因：找到 MTA-STS，但無法擷取網域的 DNSSEC 狀態。
    動作 () ：完成使用 DNSSEC 設定輸入 SMTP DANE 中的步驟。

使用 DNSSEC 減輕輸入 SMTP DANE 的郵件流程問題

啟用具有 DNSSEC 的輸入 SMTP DANE 之後，郵件流程問題有 3 個主要案例：

  1. SMTP DANE 驗證失敗的問題：如需如何減輕此問題的資訊，請 減輕 SMTP DANE 驗證失敗。
  2. DNSSEC 驗證失敗的問題：如需如何減輕此問題的資訊，請參閱 減輕 DNSSEC 驗證失敗。
  3. MX 值的問題：如需如何減輕此問題的資訊，請參閱 減輕 MX 值的問題。
減輕 SMTP DANE 驗證失敗

若要減輕 SMTP DANE 驗證的影響，請執行下列命令：

Disable-SmtpDaneInbound -DomainName <DomainName>
降低 DNSSEC 驗證失敗

  1. 若要減輕 DNSSEC 驗證失敗的任何影響，您必須透過 DNS 提供者停用網域 (contoso.com) 上的 DNSSEC。

    注意事項

    如果停用 DNSSEC 無法解決問題，則可能是 MX 值的問題。

  2. 一旦您透過 DNS 提供者停用網域上的 DNSSEC，請向您的 DNS 提供者開啟支援票證，以決定如何安全地重新啟用網域的 DNSSEC。

減輕 MX 值的問題

  1. 確定您的 MX 值符合 Microsoft 365 系統管理 中心 - 設定 ->> 網域中的值。

  2. 選取網域，選取 [DNS 記錄]，然後執行 [檢查健康情況]。

  3. 請確定 MX 記錄顯示為 [確定];如果沒有，請將值更新為系統管理中心所提供的值。

  4. 流覽至您的 DNS 註冊機構，並尋找網域的 MX 記錄。 主機名值會是：

    <MX token>.<subdomain>.mx.microsoft

  5. 使用下列主機名值建立第二筆 MX 記錄，並將優先順序設定為 20：

    <MX token>.mail.protection.outlook.com

    注意事項

    將 「MX Token」 值取代為步驟 4 中您網域目前 MX 記錄中的 MX 令牌。 例如，contosotest.com 的 MX 令牌是 contosotest-com。

  6. 確定在步驟 5 中建立的 MX 正常運作。

    重要事項

    確保第二筆 MX 記錄正常運作的方法之一，是使用 Microsoft Remote Connectivity Analyzer。

    1. 輸入網域 (例如，contoso.com) 到测试中;然後選 取 [執行測試]。
    2. 開啟 測試步驟。
    3. 開啟 測試步驟 ，以 測試網域 「admin@ (domain) 」 的輸入 SMTP 郵件流程。
    4. 在 [嘗試擷取網域 ' (domain) ' 的 DNS MX 記錄下開啟 [其他詳細數據]。
    5. 確認 (MX 令牌) .mail.protection.outlook.com MX 記錄狀況良好。

  7. 如果郵件流程使用 MX token.mail.protection.outlook.com 記錄，請執行下列命令：

    Disable-DnssecForVerifiedDomain -DomainName <DomainName>

  8. 刪除符合下列值的 DNSSEC MX 記錄：

    <MX token>.<subdomain>.mx.microsoft

  9. 請確定您在步驟 5 中建立的 MX 記錄是唯一的 MX 記錄，並將它設定為優先順序 0 (最高優先順序) 。

Exchange Online 客戶如何搭配 DNSSEC 使用輸出 SMTP DANE？

作為 Exchange Online 客户，不需要為傳出電子郵件設定這種增強的電子郵件安全性。 此增強的電子郵件安全性是我們為您建置的功能，預設會針對所有 Exchange Online 客戶開啟，並在目的地網域通告 DANE 支援時使用。 若要獲得使用 DNSSEC 和 DANE 檢查傳送電子郵件的優點，請與您交換電子郵件的商務合作夥伴聯絡，要求他們實施 DNSSEC 和 DANE，以便他們可以使用這些標準接收電子郵件。

針對使用 SMTP DANE 傳送電子郵件進行疑難解答

目前，使用 Exchange Online 傳送電子郵件時，DANE 有四個錯誤碼。 Microsoft 正在積極更新此錯誤碼清單。 這些錯誤將會顯示在：

  1. 透過郵件追蹤詳細資料檢視的 Exchange 系統管理中心入口網站。

  2. 由於 DANE 或 DNSSEC 失敗而未傳送訊息時產生的 DDR。

  3. 遠端連線能力分析程式工具 Microsoft 遠端連線分析程式。

    NDR 代碼 描述
    4/5.7.321 starttls-not-supported: 目的地郵件伺服器必須支援 TLS，才能接收郵件。
    4/5.7.322 certificate-expired: 目的地郵件伺服器的憑證已過期。
    4/5.7.323 tlsa-invalid: 網域無法通過 DANE 驗證。
    4/5.7.324 dnssec-invalid: 目的地網域傳回無效的 DNSSEC 記錄。

    注意事項

    目前，當網域發出支援 DNSSEC 但 DNSSEC 檢查失敗時，Exchange Online 不會產生 4/5.7.324 dnssec-invalid 錯誤。 它會產生一般 DNS 錯誤：

    4/5.4.312 DNS query failed

    我們正積極努力修正這項已知限制。 如果您收到此錯誤語句，請流覽至 Microsoft Remote Connectivity Analyzer，然後針對產生 4/5.4.312 錯誤的網域執行 DANE 驗證測試。 結果會顯示它是 DNSSEC 問題還是不同的 DNS 問題。

疑難解答 4/5.7.321 starttls-not-supported

此錯誤通常表示目的地郵件伺服器發生問題。 收到訊息之後：

  1. 檢查已正確輸入目的地電子郵件地址。
  2. 提醒目的地電子郵件系統管理員您收到此錯誤碼，以便他們判斷目的地伺服器是否正確設定，以使用 TLS 接收郵件。
  3. 重試傳送電子郵件，並查看 Exchange 系統管理中心入口網站中郵件的訊息追蹤詳細資料。

針對 4/5.7.322 憑證過期的問題進行疑難解答

必須向傳送的電子郵件伺服器出示尚未過期的有效 X.509 憑證。 X.509 憑證必須在到期後更新，通常每年更新一次。 收到訊息之後：

  1. 提醒目的地電子郵件系統管理員您收到此錯誤碼，並提供錯誤碼字串。
  2. 允許更新目的地伺服器憑證的時間，並更新 TLSA 記錄以參考新憑證。 然後，重試傳送電子郵件，並查看 Exchange 系統管理中心入口網站中郵件的訊息追蹤詳細資料。

針對 4/5.7.323 tlsa-invalid 進行疑難解答

此錯誤碼與 TLSA 記錄錯誤有關，只有在已傳回 DNSSEC-authentic TLSA 記錄之後才能生成。 在 DANE 驗證期間，在記錄已傳回之後發生許多情況，可能導致生成程式碼。 Microsoft 正積極處理此錯誤碼所涵蓋的案例，以讓每個案例都有特定的程式碼。 目前，其中一或多個案例可能會導致生成錯誤碼：

  1. 目的地郵件伺服器的憑證與正版 TLSA 記錄的預期不相符。
  2. 正版 TLSA 記錄未正確設定。
  3. 該目的地網域正在遭受攻擊。
  4. 任何其他 DANE 失敗。

收到訊息之後：

  1. 向目的地電子郵件管理員發出您收到此錯誤碼的警示，並提供錯誤碼字元串。
  2. 允許目的地電子郵件系統管理員檢查其 DANE 設定和電子郵件伺服器證書有效性。 然後，重試傳送電子郵件，並查看 Exchange 系統管理中心入口網站中郵件的訊息追蹤詳細資料。

針對 4/5.7.324 dnssec-invalid 進行疑難解答

當目的地網域指出它是 DNSSEC-authentic，但 Exchange Online 無法驗證為 DNSSEC-authentic 時，就會產生此錯誤碼。

收到訊息之後：

  1. 向目的地電子郵件管理員發出您收到此錯誤碼的警示，並提供錯誤碼字元串。
  2. 讓目的地電子郵件管理員有時間檢閱其網域的 DNSSEC 設定。 然後，重試傳送電子郵件，並查看 Exchange 系統管理中心入口網站中郵件的訊息追蹤詳細資料。

針對使用 SMTP DANE 接收電子郵件進行疑難解答

目前，接收網域的系統管理員有兩種方法可用來驗證和疑難解答其 DNSSEC 和 DANE 設定，以使用下列標準從 Exchange Online 接收電子郵件：

  1. 採用 RFC8460 引進的 SMTP TLS-RPT (傳輸層安全性)
  2. 使用遠端連線能力分析程式工具 Microsoft 遠端連線分析程式

TLS-RPT https://datatracker.ietf.org/doc/html/rfc8460 是一種報告機制，讓寄件者向目的地網域系統管理員提供有關 DANE 和 MTA-STS 在這些各自目的地網域的成功和失敗的詳細資訊。 若要接收 TLS-RPT 報告，您只需要在網域的 DNS 記錄中新增 TXT 記錄，其中包含要接收報告的電子郵件地址或 URI。 Exchange Online 會以 JSON 格式傳送 TLS-RPT 報告。

下表的數據是記錄的範例：

類型 網域名稱 TTL 記錄
TXT _smtp._tls.microsoft.com 3600 v=TLSRPTv1;rua=https://tlsrpt.azurewebsites.net/report

第二個方法是使用遠端連線能力分析程式Microsoft 遠端連線分析程式，其可以針對 Exchange Online 在服務外傳送電子郵件時，針對 DNS 設定執行相同的 DNSSEC 和 DANE 檢查。 此方法是針對設定中的錯誤進行疑難解答的最直接方式，以使用這些標準從 Exchange Online 接收電子郵件。

進行錯誤疑難解答時，可能會產生下列錯誤碼：

NDR 代碼 描述
4/5.7.321 starttls-not-supported: 目的地郵件伺服器必須支援 TLS，才能接收郵件。
4/5.7.322 certificate-expired: 目的地郵件伺服器的憑證已過期。
4/5.7.323 tlsa-invalid: 網域無法通過 DANE 驗證。
4/5.7.324 dnssec-invalid: 目的地網域傳回無效的 DNSSEC 記錄。

注意事項

目前，當網域發出支援 DNSSEC 但 DNSSEC 檢查失敗時，Exchange Online 不會產生 4/5.7.324 dnssec-invalid 錯誤。 它會產生一般 DNS 錯誤：

4/5.4.312 DNS query failed

我們正積極努力修正這項已知限制。 如果您收到此錯誤語句，請流覽至 Microsoft Remote Connectivity Analyzer，然後針對產生 4/5.4.312 錯誤的網域執行 DANE 驗證測試。 結果會顯示它是 DNSSEC 問題還是不同的 DNS 問題。

疑難解答 4/5.7.321 starttls-not-supported

注意事項

這些步驟適用于電子郵件系統管理員使用 SMTP DANE 從 Exchange Online 接收電子郵件的疑難排解。

此錯誤通常表示目的地郵件伺服器發生問題。 遠端連線分析程式正在測試連接的郵件伺服器。 通常有兩種案例能生成此程式碼：

  1. 目的地郵件伺服器完全不支援安全通訊，而且必須使用純文本的非加密通訊。
  2. 目的地伺服器未正確設定，並忽略了 STARTTLS 命令。

收到訊息之後：

  1. 檢查電子郵件地址。
  2. 找出與錯誤語句相關聯的 IP 位址，以便識別與語句相關聯的郵件伺服器。
  3. 檢查郵件伺服器的設定，確定其已設定為接聽 SMTP 流量， (埠 25 和 587) 。
  4. 請稍候幾分鐘，然後再次嘗試使用遠端連線分析程式工具進行測試。
  5. 如果仍然失敗，請嘗試移除 TLSA 記錄，然後再次使用遠端連線分析程式工具進行測試。
  6. 如果沒有任何失敗，此訊息可能表示您用來接收郵件的郵件伺服器不支援 STARTTLS，而且您可能需要升級為可使用 DANE 的郵件伺服器。

針對 4/5.7.322 憑證過期的問題進行疑難解答

注意事項

這些步驟適用于電子郵件系統管理員使用 SMTP DANE 從 Exchange Online 接收電子郵件的疑難排解。

必須向傳送的電子郵件伺服器出示尚未過期的有效 X.509 憑證。 X.509 憑證必須在到期後更新，通常每年更新一次。 收到訊息之後：

  1. 檢查與錯誤語句相關聯的IP，以便識別與其相關聯的郵件伺服器。 找出您識別的電子郵件伺服器上過期的憑證。
  2. 登入憑證提供者的網站。
  3. 選取過期的憑證，然後按照指示續約並支付續約費用。
  4. 您的提供者驗證購買之後，您可以下載新的憑證。
  5. 將更新的憑證安裝到其關聯的郵件伺服器。
  6. 使用新憑證的數據更新郵件伺服器的相關聯 TLSA 記錄。
  7. 等候適當的時間後，使用遠端連線分析程式工具重新測試。

針對 4/5.7.323 tlsa-invalid 進行疑難解答

注意事項

這些步驟適用于電子郵件系統管理員使用 SMTP DANE 從 Exchange Online 接收電子郵件的疑難排解。

此錯誤碼與 TLSA 記錄錯誤有關，只有在已傳回 DNSSEC-authentic TSLA 記錄之後才能生成。 但，在 DANE 驗證期間，在記錄已傳回之後發生許多情況，可能導致生成程式碼。 Microsoft 正積極處理此錯誤碼所涵蓋的案例，以讓每個案例都有特定的程式碼。 目前，其中一或多個案例可能會導致生成錯誤碼：

  1. 正版 TLSA 記錄未正確設定。
  2. 憑證尚未在未來的時間範圍有效/設定時間。
  3. 目的地網域正在遭受攻擊。
  4. 任何其他 DANE 失敗。

收到訊息之後：

  1. 檢查與錯誤語句相關聯的IP，以識別與其相關聯的郵件伺服器。
  2. 識別與已識別郵件伺服器相關聯的 TLSA 記錄。
  3. 確認 TLSA 記錄的設定，以確保它向寄件者發出訊號，以執行偏好的 DANE 檢查，且 TLSA 記錄中包含正確的憑證資料。
    1. 如果您必須更新記錄中不一致之處，請稍候幾分鐘，然後使用遠端連線分析程式工具重新執行測試。
  4. 在識別的郵件伺服器上尋找憑證。
  5. 檢查憑證有效的時段。 如果設定為在未來日期開始有效性，則必須針對目前的日期更新。
    1. 登入憑證提供者的網站。
    2. 選取過期的憑證，然後按照指示續約並支付續約費用。
    3. 您的提供者驗證購買之後，您可以下載新的憑證。
    4. 將更新的憑證安裝到其關聯的郵件伺服器。

針對 4/5.7.324 dnssec-invalid 進行疑難解答

注意事項

這些步驟適用于電子郵件系統管理員使用 SMTP DANE 從 Exchange Online 接收電子郵件的疑難排解。

當目的地網域指出其為 DNSSEC-authentic，但 Exchange Online 無法驗證為 DNSSEC-authentic 時，就會產生此錯誤碼。 本節不適用於 DNSSEC 問題的疑難解答，並著重於網域先前已通過 DNSSEC 驗證但目前未通過的案例。

注意事項

如果 Exchange Online 在目的地網域的 TLSA 查詢上收到來自 DNS 伺服器的 SERVFAIL 回應，也會產生此錯誤碼。

收到訊息之後：

  1. 如果您使用 DNS 提供者，例如 GoDaddy，請對您的 DNS 提供者發出錯誤警示，讓他們可以處理疑難解答和組態變更。
  2. 如果您要管理自己的 DNSSEC 基礎結構，則有許多 DNSSEC 設定錯誤可能會產生此錯誤訊息。 檢查您的區域先前是否通過 DNSSEC 驗證的一些常見問題：
    1. 當父區域保留一組 DS 記錄，指向子區域中不存在的專案時，信任鏈結就會中斷。 DS 記錄的這類指標可能會藉由驗證解析程式，將子區域標示為假名。
      • 若要解決，請查閱子網域 RRSIG 金鑰識別碼，並確保它們符合父區域發佈之 DS 記錄中的金鑰識別碼。
    2. 網域的 RRSIG 資源記錄無效、已過期或有效期間尚未開始。
      • 使用有效的時段為網域生成新的簽章以解決。

傳送輸出電子郵件時，如果接收網域已啟用 DNSSEC，我們會查詢與網域中的 MX 專案相關聯的 TLSA 記錄。 如果未發佈任何 TLSA 記錄，則 TLSA 查閱的響應必須是 NOERROR (沒有此網域) 或 NXDOMAIN 要求類型的記錄， (沒有這類網域) 。 如果未發佈 TLSA 記錄，DNSSEC 需要此回應;否則，Exchange Online 會將缺少回應解譯為 SERVFAIL 錯誤。 根據 RFC 7672，SERVFAIL 回應不受信任;因此，目的地網域無法通過 DNSSEC 驗證。 這個電子郵件接著會延遲，並出現下列錯誤：

450 4.7.324 dnssec-invalid: Destination domain returned invalid DNSSEC records

如果電子郵件寄件者回報訊息的收據

如果您使用 DNS 提供者，例如 GoDaddy，請對您的 DNS 提供者發出錯誤警示，讓他們可以針對 DNS 回應進行疑難解答。 如果您要管理自己的 DNSSEC 基礎結構，這可能是 DNS 伺服器本身或網路的問題。

常見問題集

作為 Exchange Online 客戶，我可以退出宣告使用 DNSSEC 和/或 DANE 嗎？

我們強烈相信 DNSSEC 和 DANE 將會大幅增加我們服務的安全性位置，並且讓我們的客戶受益。 我們在過去一年努力降低此部署可能對Microsoft 365 個客戶造成的潛在影響風險和嚴重性。 我們將主動監視和追蹤部署，以確保其推出時的負面影響會降到最低。因此，無法使用租用戶層級例外狀況或退出。 如果您在啟用 DNSSEC 和/或 DANE 時遇到任何問題，本文件中記錄的各種調查失敗的方法將可協助識別錯誤來源。 在大部分情況下，問題會與外部目的地合作對象有關，而您必須與這些商務合作夥伴溝通，讓他們必須正確設定 DNSSEC 和 DANE，才能使用這些標準從 Exchange Online 接收電子郵件。

DNSSEC 與 DANE 如何關聯？

DNSSEC 會套用公鑰基礎結構，以確保回應 DNS 查詢所傳回的記錄是驗證的，藉此將信任層新增至 DNS 解析。 DANE 可確保接收端郵件伺服器為真實 MX 記錄的合法和預期郵件伺服器。

MTA-STS 與適用于 SMTP 的 DANE 之間有什麼不同？

DANE 和 MTA-STS 的用途相同，但 DANE 需要 DNSSEC 進行 DNS 驗證，而 MTA-STS 則依賴憑證授權單位單位。

為什麼投機型 TLS 不夠？

如果兩個端點都同意支援，則投機型 TLS 會加密兩個端點之間的通訊。 不過，即使 TLS 加密傳輸，網域在 DNS 解析期間可能已遭詐騙，因此它會指向惡意執行者端點，而非網域的實際端點。 此詐騙是透過使用 DNSSEC 實作 MTA-STS 和/或 SMTP DANE 來解決的電子郵件安全性差距。

為什麼 DNSSEC 不足？

DNSSEC 無法完全抵禦攔截式攻擊，並從TLS降級 (，以清除郵件流程案例的文字) 攻擊。 新增 MTA-STS 和 DANE 以及 DNSSEC 可提供完整的安全性方法，以防範 MITM 和降級攻擊。

尋找並修正新增網域或 DNS 記錄之後所發生的問題

DNSSEC 概觀 |Microsoft Docs

使用 DMARC 來驗證電子郵件，設定步驟 - Office 365 | Microsoft Docs

如何將 DKIM 用於自訂網域中的電子郵件 - Office 365 | Microsoft Docs

寄件者原則架構 (SPF) 如何防止詐騙 - Office 365 - Microsoft Docs

Microsoft Ignite 2020 的 Exchange Online Transport 新聞 - Microsoft 技術社群

rfc8461 (ietf.org)