MTA-STS 策略檢測工具
獲取域名的 _mta-sts TXT 記錄與 mta-sts.txt 策略檔案，診斷郵件傳輸過程中的強制 TLS 加密（MTA-STS）是否配置正確。
使用提示
- MTA-STS 是由“發信方”伺服器負責檢查的機制。一旦釋出策略，其他人發往你域名的郵件伺服器就會開始強制使用 TLS。
- 建議先以 mode: testing 執行數週至一個月，監控是否出現意外的投遞拒絕，再切換到 enforce，以確保過渡安全。
- max_age（策略有效期）通常設定在 604800 秒（7天）到 31557600 秒（1年）之間。數值過短會導致頻繁重新獲取策略檔案。
- mx 欄位可以使用萬用字元（如 *.example.com），但 TLS 證書的 SAN（Subject Alternative Name）必須與該萬用字元匹配。
- 只發布 DNS 記錄或只發布策略檔案都不起作用，只有兩者同時齊備時 MTA-STS 才會生效。
常見問題
“未配置 MTA-STS”本身並不罕見，目前大多數域名仍未採用。但如果希望增強對 STARTTLS 剝離攻擊的防護，值得考慮引入該機制。
SPF、DKIM、DMARC 用於驗證發信方身份、防止偽造。MTA-STS 與發信方身份驗證無關，它強制郵件傳輸鏈路本身使用 TLS 加密，防禦的是另一類威脅。
並非放在你自己的域名下，而是必須放在以“mta-sts.”為字首的子域名（例如 mta-sts.example.com）的 /.well-known/mta-sts.txt 路徑下，並通過有效的 TLS 證書提供服務。
不建議這樣做。應先以 testing 模式執行數週至一個月，藉助 TLS-RPT 監控投遞情況，確認不會出現意外拒收後再切換到 enforce，這樣更安全。
本工具僅檢查 TXT 記錄與策略檔案的語法及必填欄位是否齊全，並不驗證 TLS 證書的有效性，也不會對列出的 MX 主機執行實際的 TLS 握手。如需更嚴格的驗證，請配合 checktls.com 等專業工具使用。
閒話 ― 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 負責“可觀測性”，兩者並用是目前業界推薦的最佳實踐。