MTA-STSは、DNSレコードとWebでホストされるポリシーファイルという2つの場所に同時に存在し、その両方が一致していなければならないという点で、メールレコードの中でも珍しい存在です。だからこそ、ほとんどのMTA-STSの問題は、レコードの欠落ではなく設定の不一致なのです。
チェッカーが検証する内容
完全なチェックでは、4つが揃っていることを確認します。_mta-sts TXTレコードが存在し有効なidを持つこと、ポリシーファイルがmta-sts.yourdomain.com/.well-known/mta-sts.txtにて信頼された証明書とともにHTTPS経由で到達可能であること、ポリシーのmodeが意図したものであること、そしてそこに列挙されたmxホストが実際にあなたの公開されたMXレコードと一致することです。いずれか1つでもずれていると、送信サーバーはあなたのポリシーを強制できません。
よくあるMTA-STSの失敗
- TXTレコードはあるがポリシーファイルがない。 DNSレコードが、配信されていないポリシーを指しており、送信者は強制なしにフォールバックします。
- ポリシーファイルが有効なHTTPS経由でない。
mta-stsサブドメインには独自の信頼されたTLS証明書が必要です。自己署名または期限切れの証明書では取得に失敗します。 - MXの不一致。 ポリシー内の
mx行が実際のMXホストと一致せず、正規のメールサーバーが証明書検証に失敗します。 testingまたはnoneのまま。 ポリシーは公開されていますが、実際にはTLSを強制していません。idが変更されていない。 ポリシーを編集した後、DNSレコードのidを変更しなければ、送信者はキャッシュされた古いバージョンを使い続けます。
安全な導入：enforceの前にtesting
MTA-STSは段階的に展開しましょう。まずmode: testingで公開し、TLS-RPTと組み合わせて、メールをブロックすることなくTLS失敗のレポートを受け取ります。レポートがクリーンになりMXリストが確認できたら、mode: enforceに切り替えます。適切なmax_age（1週間が一般的）を設定して、送信者がポリシーをキャッシュしつつも、妥当な期間内に変更を取り込むようにします。
MTA-STSとTLS-RPTは協調して機能する
MTA-STSは暗号化された配信を強制し、TLS-RPT（RFC 8460）は、その強制を信頼するための可視性を与えます。報告がなければ、あなたは手探りで強制していることになります。両方を一緒に導入し、証明書の破損が静かにバウンスするメールではなくレポートとして表面化するようにしましょう。
MTA-STSがメールスタックのどこに位置するか
MTA-STSは受信メールを転送中に保護しますが、送信者を認証するわけではありません。それは送信側のSPF、DKIM、DMARCの役割です。ドメイン認証チェッカーを実行してそれらを一度にすべて確認し、SPFレコードをAutoSPFで有効かつ10ルックアップ上限内に保つことで、スタックの認証側を暗号化側と同じくらい強固にしましょう。なぜSPFを定期的にチェックすべきかと疑問に思う方へ。新しい送信者によるずれがその理由です。