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

  • 發行項

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

適用于 SMTP RFC 7672 的 DANE 會使用網域 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 並傳送給寄件者。

提示

如果您不是 E5 客戶，請使用 90 天的 Microsoft Purview 解決方案試用版來探索其他 Purview 功能如何協助貴組織管理數據安全性與合規性需求。 立即從 Microsoft Purview 合規性入口網站 試用中樞開始。 瞭解 有關註冊和試用版條款的詳細數據。

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 哈希。

Exchange Online 客戶如何使用 SMTP Dane Outbound？

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

Exchange Online 客戶如何使用 SMTP Dane 傳入？

目前，Exchange Online 不支援輸入 SMTP DANE。 輸入 SMTP DANE 的支援將於不久的將來提供。

根據 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 Online 的郵件流程

技術 其他資訊
郵件傳輸代理程式 - 嚴格傳輸安全性 (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 來驗證電子郵件，設定步驟

疑難排解使用 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 遠端連線分析器，並針對產生 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 報告。

範例記錄：

範例記錄

第二個方法是使用遠端連線能力分析程式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 遠端連線分析器，並針對產生 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 驗證但目前未通過的案例。

收到訊息之後：

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

注意事項

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

傳送輸出電子郵件時，如果接收網域已啟用 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)