MTA-STSとは

MTA-STSを読むときの前提

MTA-STS（Mail Transfer Agent Strict Transport Security）は、対象ドメイン宛のSMTP配送でTLSを使う方針を送信側MTAへ伝える仕組みです。DNS TXTで方針IDを公開し、HTTPS上のポリシーファイルでMX名とmode、max_ageを示します。

実務では、_mta-sts TXT、mta-stsホストのHTTPS公開、ポリシーファイル、mode、mx、max_age、証明書、MX変更、TLS-RPTのレポートを合わせて確認します。DNSだけ、またはWebファイルだけを見ても有効性は判断できません。

証跡には、対象ドメイン、_mta-sts TXT、ポリシーファイルURL、mode、mx一覧、証明書情報、MX回答、TLS-RPTの失敗レポート、確認時刻を残します。

policyのmodeと公開場所を見る

MTA-STSのポリシーは、https://mta-sts.example.com/.well-known/mta-sts.txt のようなHTTPS URLで公開されます。modeはtesting、enforce、noneがあり、testingで影響を観測してからenforceへ進めるのが基本です。

ポリシーファイルが取得できない、証明書が不正、DNS TXTのidが更新されていない、max_ageが長すぎると、送信側が古い方針を保持したり、配送失敗の原因になります。

• _mta-sts TXTとポリシーファイルの両方を確認する。
• modeとmax_ageを変更計画へ残す。
• enforce化前にtesting期間のレポートを見る。

MXと証明書の一致を確認する

MTA-STSでは、ポリシーファイルに記載したmxと、実際のMX宛先、SMTP接続先の証明書名が重要です。MXを変更したのにポリシーを更新しないと、送信側がTLS検証で配送を止めることがあります。

クラウドメールやメールゲートウェイでは、MX名、CNAME、証明書のSAN、実際の接続先が分かれます。受信基盤側の案内値をそのまま貼るだけでなく、実際のDNS回答とTLS証明書を突合します。

• MX回答とpolicyのmxを突合する。
• SMTP接続時の証明書SANを確認する。
• MX切替時はMTA-STSも同じ変更範囲に入れる。

TLS-RPTと配送影響を見る

MTA-STSを有効化すると、TLS失敗、証明書不一致、ポリシー取得失敗、MX不一致が配送影響として表面化します。TLS-RPTを受けると、失敗元や失敗理由を継続的に確認できます。

ただし、レポート件数だけでは業務影響は判断できません。対象送信元、失敗ドメイン、配送ログ、問い合わせ状況を合わせて、正規配送に影響しているかを分類します。

• TLS-RPTのrua宛先と保管場所を確認する。
• 失敗理由を証明書、MX、policy取得、TLSに分ける。
• enforce後の問い合わせ導線を用意する。

変更証跡と引き継ぎ

MTA-STS変更では、旧policy、新policy、_mta-sts TXT、mode、max_age、mx、証明書、MX変更予定、TLS-RPT確認結果、戻し条件を残します。enforce化後に戻す場合も、送信側キャッシュの影響を考慮します。

引き継ぎでは、DNS管理者、Web公開先管理者、メール基盤管理者、証明書管理者、関連語としてSTARTTLS、TLS-RPT、MX、SMTPを残すと追いやすくなります。

• policyとDNS TXTを同じ変更記録へ残す。
• max_ageとキャッシュ影響を明記する。
• MX変更時の確認手順へMTA-STSを入れる。

関連語

同じ主要カテゴリの用語

メールの学習順

同じ主要カテゴリの用語をまとめて確認できます。現在の用語を起点に、前後の用語へ進むと文脈を保ったまま読み進められます。

InfraEngKit内の関連機能