MTA-STS 策略檢測工具
獲取域名的 _mta-sts TXT 記錄與 mta-sts.txt 策略檔案，診斷郵件傳輸過程中的強制 TLS 加密（MTA-STS）是否配置正確。
診斷郵件投遞的 TLS 強制（MTA-STS）
SMTP 的加密本是一件「能則為之」的隨意事，故而半途插足的攻擊者只消把 STARTTLS 的告示抹去，便可將往來壓回明文。MTA-STS 正是堵上這一口子的約定，它告訴發信方：寄往本網域的郵件必須走 TLS。 本工具會把 _mta-sts 的 TXT 記錄與政策檔案一併取來，報出設定是否齊全。
這套安排最令人困惑之處，是 DNS 裡並不存放政策本身。 TXT 記錄所載的不過是標示版本的 id；實體則經 HTTPS 自 https://mta-sts.您的網域/.well-known/mta-sts.txt 發放。 故而此機制的信任，落在網站憑證而非 DNS 之上。而最常卡住人的，是把 mode 留在 testing。 在那種狀態下，縱使 TLS 失敗，投遞照舊放行，惟有取值為 enforce 時，強制才真正生效。 通行的採用次第是：先停在 testing，看 TLS-RPT 的報告直到確信無物受損，然後才轉入 enforce。
使用方法
-
輸入網域
只給網域即可，形如
example.com。 -
查看 TXT 記錄
看有無
v=STSv1與id=。 每更新一次政策，id便要改一次。 -
閱讀政策檔案的內容
其中列著三項：
mx、max_age與mode。 -
確認 mode
停在
testing便什麼也沒強制。 取到enforce，政策方才有效。
用好本工具的小技巧
- MTA-STS 是由“發信方”伺服器負責檢查的機制。一旦釋出策略，其他人發往你域名的郵件伺服器就會開始強制使用 TLS。
- 建議先以 mode: testing 執行數週至一個月，監控是否出現意外的投遞拒絕，再切換到 enforce，以確保過渡安全。
- max_age（策略有效期）通常設定在 604800 秒（7天）到 31557600 秒（1年）之間。數值過短會導致頻繁重新獲取策略檔案。
- mx 欄位可以使用萬用字元（如 *.example.com），但 TLS 證書的 SAN（Subject Alternative Name）必須與該萬用字元匹配。
- 只發布 DNS 記錄或只發布策略檔案都不起作用，只有兩者同時齊備時 MTA-STS 才會生效。
這些情境會用到
檢視自家網域
此機制須 DNS 與 HTTPS 雙雙就位方能運轉，故可揪出缺了哪一半。
轉入 enforce 之前先查一遍
趁還在 testing，把設定上的差錯掃清。
添了 MX 之後重新審視
忘了把新的 MX 主機寫進政策的 mx，投往該主機的郵件便會被拒。
弄清往來對象做到了哪一步
可以看出對方是否對自家郵件強制了 TLS。
MTA-STS 的術語
- _mta-sts TXT
- 承載標示政策版本之
id的 DNS 記錄。 政策本身不存於此。 - 政策檔案
- 實體，置於
https://mta-sts.您的網域/.well-known/mta-sts.txt。既經 HTTPS 發放，便須有一份有效的憑證。 - mode
enforce、testing、none三者之一。在testing之下，縱使檢查失敗郵件照送。- max_age
- 發信方可將政策快取的秒數。取值越長保護越強，可變更散開得也越慢。
- mx
- 要強制 TLS 的 MX 主機清單。凡不在此列的主機，投遞一概被拒。
- STARTTLS 降級
- 中間人抹去 STARTTLS 的告示以逼出明文的攻擊。MTA-STS 正是為防它而設。
常見問題
閒話 ― STARTTLS 的弱點與 MTA-STS 誕生的背景
長期以來，SMTP 傳輸加密依賴於 1999 年標準化的 STARTTLS 機制——先以明文建立連線，再切換到加密通道。2014 年，安全研究人員確認了真實存在的“STARTTLS 剝離攻擊”：由於 STARTTLS 協商本身發生在加密啟用之前，路徑中的攻擊者可以篡改伺服器響應，隱藏其對 STARTTLS 的支援，從而誘使對方退回到明文通訊。
問題的根源在於 STARTTLS 刻意設計為“對方不支援 TLS 時優雅降級為明文”這一相容性特性，而攻擊者恰恰可以利用這一點，偽裝成對方不支援 TLS。大約在 2015 年前後，谷歌自身的測量資料顯示，在某些國家和某些運營商網路中，STARTTLS 剝離攻擊已經大規模發生。
MTA-STS（RFC 8461，2018年釋出）正是業界對此問題的回應，由谷歌、微軟、雅虎等共同制定。域名通過 DNS TXT 記錄宣告支援 MTA-STS，再發布一份通過 HTTPS 獲取的策略檔案，列出允許的 MX 主機與 TLS 要求。策略一旦獲取便會按 max_age 快取，此後若發生降級嘗試即可被檢測並拒絕，而不是被悄悄接受。
MTA-STS 通常與 TLS-RPT（TLS 報告，RFC 8460）搭配使用，後者可讓域名所有者在發信伺服器無法建立 TLS 時收到報告。MTA-STS 負責“強制執行”，TLS-RPT 負責“可觀測性”，兩者並用是目前業界推薦的最佳實踐。