受信メールに対する強制 TLS ポリシー
DNS とレコード
DNS ルックアップ あらゆるドメインのすべての DNS レコード A レコードルックアップ ドメインの IPv4 アドレス AAAA レコードルックアップ ドメインの IPv6 アドレス MX ルックアップ ドメインのメールサーバー NS ルックアップ 権威ネームサーバー TXT ルックアップ TXT レコード、SPF、検証 CNAME ルックアップ 正規名（エイリアス）レコード SOA ルックアップ Start of Authority レコード SRV ルックアップ サービスロケーションレコード CAA ルックアップ どの CA が証明書を発行できるか 逆引き DNS（PTR） IP アドレスからホスト名へ DNSSEC チェック ドメインは署名され検証されているか？ DNS ヘルスチェック 委任と DNS の総合診断レポートメール到達性
SPF チェック Sender Policy Framework レコードを検証 DMARC チェック DMARC ポリシーを検査・評価 DKIM チェック DKIM 公開鍵を検索・検証 ブラックリストチェック IP をメールブロックリスト（DNSBL）と照合 SMTP テスト メールサーバーに接続し STARTTLS をチェック MTA-STS チェック 受信メールに対する強制 TLS ポリシー BIMI チェック メール用のブランドロゴレコード TLS-RPT チェック SMTP TLS レポートポリシーネットワークとウェブ
SSL 証明書チェック サイトの TLS 証明書と有効期限を検査 HTTP ヘッダーチェック レスポンスヘッダー、リダイレクト、セキュリティを検査 Ping（TCP） TCP 経由での到達性と遅延 ポートチェック どの一般的なポートが開いているかドメイン
WHOIS ルックアップ ドメイン、IP、ASN の登録データMTA-STSは、受信メールを認証済みのTLSで配信するようドメインに要求させ、ダウングレード攻撃や中間者攻撃から防御します。IPeekは_mta-stsのTXTレコードを読み取り、mta-sts.your-domainに公開されたポリシーファイルを取得します。攻撃者が黙って剥がせる日和見的なSTARTTLSが残すギャップを埋めます。
MTA-STSは2つの部分を使います。_mta-sts.your-domainのTXTレコードは、バージョンとポリシーIDを保持し、ポリシーが存在することを送信サーバーに伝え、更新時に変化します。ポリシー自体は、https://mta-sts.your-domain/.well-known/mta-sts.txt にHTTPS経由で配信される平文ファイルにあります。そのファイルには、バージョン、モード、許可されたMXホスト名、max_ageのキャッシュ有効期間が列挙されます。MTA-STSに対応する送信側はポリシーを取得してキャッシュし、それに照らして証明書の検証に失敗するMXへの配信を拒否します。
IPeekは、_mta-stsのTXTレコードが存在するか、ポリシーファイルがHTTPS経由で到達可能かを示します。最も重要なのはモードの値です。noneはポリシーが有効でないこと、testingは失敗が報告されるもののメールは流れること、enforceはTLS認証に失敗した場合に送信側が配信を中止しなければならないことを意味します。ポリシー内のmxエントリが実際のMXレコードと一致すること、ポリシーホストのHTTPS証明書が有効であることを確認してください。max_ageが高い値（多くは604800秒）だと、キャッシュされたポリシーが実時間の改ざんに耐えるため保護が向上します。
最もよくある間違いは、TXTレコードが存在するのにポリシーファイルが404やリダイレクトを返し、ポリシーを使用不能にしていることです。ポリシーホストは有効なHTTPSを配信しなければならないため、mta-sts.your-domainの期限切れまたは不一致の証明書は強制を完全に壊します。MXエントリがDNSとずれると、enforceに切り替えた時点で配信失敗を引き起こします。まずtestingで展開し、TLS-RPTレポートで失敗を監視し、すべてのMXが有効で一致する証明書を提示することを確認してからenforceへ移行してください。
testingモードでは、TLSの失敗を検出した送信側もメールを配信しますが、問題を報告するため、トラフィックをブロックせずに問題を発見できます。enforceモードでは、送信側は証明書の検証に失敗したMXへの配信を中止しなければなりません。まずtestingで始め、TLS-RPTレポートを監視し、失敗が現れなくなってからenforceへ切り替えてください。
ポリシーファイルは、mta-stsという名前のサブドメイン上の https://mta-sts.your-domain/.well-known/mta-sts.txt にHTTPS経由で配信されます。_mta-sts.your-domainのDNS TXTレコードは、ポリシーが存在することを告知しIDを運ぶだけで、モードや許可されたMXホストを含む実際のルールはそのHTTPSファイルにあります。MTA-STSが機能するには、両方が存在し有効である必要があります。
STARTTLSは日和見的です。暗号化を提供しますが、ネットワーク攻撃者がSTARTTLSの広告を剥がし、検知されないまま平文配信を強制できます。MTA-STSは、TLSが必須でありどのMX証明書を信頼すべきかを送信側に伝える公開ポリシーを追加するため、剥がされたり無効なTLS接続は黙ってダウングレードするのではなく配信失敗を引き起こします。STARTTLSをダウングレード攻撃に対して強化するものです。
いいえ。MTA-STSは、DNSSECではなくHTTPSとウェブPKIに信頼を意図的に依存するため、DANEより展開が容易です。ポリシーファイルのHTTPS証明書が認証を提供します。ドメインにすでにDNSSECがある場合は、DANEをMTA-STSと並行して運用できます。2つの仕組みは衝突せず補完し合うからです。
まずTXTレコードとポリシーファイルをtestingモードで公開し、次にTLS-RPTを有効化して、送信サーバーがTLS失敗のレポートをメールで送ってくるようにします。ポリシー内のMXホスト名がDNSと一致し、すべてのMXが有効な証明書を提示することを確認してください。通常のレポートサイクルにわたって失敗が報告されなくなったら、モードをenforceに変更し、ポリシーIDを更新します。