MTA-STSを設定すると届くレポートは、TLS-RPT（RFC 8460）という仕組みで送られる、gzip圧縮されたJSONファイルです。読むときは「誰が・いつの分を」「成功と失敗の件数」「失敗の種類（result-type）と相手のMXホスト」の3点を順に見ます。この記事では、レポートの受け取り方、JSONの主な項目の意味、jqを使った集計方法、失敗の種類ごとの確認と対処を説明し、testing モードから enforce モードへ移るときの判断材料にできるようにします。
レポートは何を報告しているのか
最初に向きを整理しておきます。TLS-RPTのレポートは、他社のメールサーバーが、あなたのドメイン宛てにメールを届けようとしたとき、TLS接続がうまくいったかどうかを、送信側の視点でまとめたものです。
- 対象は受信（あなたのドメインのMXサーバーへの配送）です。
- WordPressのお問い合わせフォームなど、サイトから送るメールの成否は、このレポートには出てきません。それは送信先のドメインが受け取るレポートに出る情報です。
- DMARCの集計レポートとは別物です。DMARCは送信元の認証（SPF・DKIM）の結果、TLS-RPTは配送経路の暗号化の結果を報告します。
レポートを受け取るには、MTA-STSのTXTレコードとは別に、TLS-RPT用のTXTレコードを公開しておく必要があります。
_mta-sts.example.com. TXT "v=STSv1; id=20261018T000000"
_smtp._tls.example.com. TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"公開されているかは次のように確認します。
dig _smtp._tls.example.com TXT +short
dig _mta-sts.example.com TXT +shortレポートは送信側の事業者ごとに、おおむね1日単位で届きます。大手のメール事業者を中心に送られていますが、どの事業者が送るかや送付の頻度は事業者の判断によります（2026年10月現在）。メールで届く場合、添付ファイルとして .json.gz 形式で付いています。
JSONの主な項目
添付ファイルを展開すると、次のような構造のJSONが出てきます。値は説明用の例です。
{
"organization-name": "Example Sender Inc.",
"date-range": {
"start-datetime": "2026-10-16T00:00:00Z",
"end-datetime": "2026-10-16T23:59:59Z"
},
"contact-info": "smtp-tls-reporting@sender.example",
"report-id": "2026-10-16T00:00:00Z_example.com",
"policies": [
{
"policy": {
"policy-type": "sts",
"policy-string": ["version: STSv1", "mode: testing", "mx: mx1.example.com", "max_age: 604800"],
"policy-domain": "example.com",
"mx-host": ["mx1.example.com"]
},
"summary": {
"total-successful-session-count": 1240,
"total-failure-session-count": 12
},
"failure-details": [
{
"result-type": "certificate-host-mismatch",
"sending-mta-ip": "192.0.2.25",
"receiving-mx-hostname": "mx2.example.com",
"receiving-ip": "203.0.113.20",
"failed-session-count": 12
}
]
}
]
}項目ごとの読み方は次のとおりです。
- organization-name / contact-info：レポートを送ってきた事業者と、その問い合わせ先。
- date-range：集計の対象期間。UTCで書かれているため、日本時間に直すと9時間ずれます。
- policy-type：送信側が適用したポリシーの種類。
stsはMTA-STS、tlsaはDANE、no-policy-foundはポリシーが見つからなかったことを表します。 - policy-string：送信側が実際に使ったMTA-STSポリシーの中身。送信側はポリシーを max_age の間キャッシュするため、ポリシーを更新した直後は、ここに古い内容が残っていることがあります。
- summary：成功と失敗のセッション数。ここで全体の失敗率をつかみます。
- failure-details：失敗の内訳。
result-typeが失敗の種類、receiving-mx-hostnameとreceiving-ipが接続しようとしたあなたのMXです。
jqで要点を取り出す
レポートの数が増えると、1件ずつ開いて読むのは大変です。jq を使えば必要な項目だけを表にできます。
gunzip -c report.json.gz > report.json
# 送信元と期間
jq '{org: ."organization-name", range: ."date-range", id: ."report-id"}' report.json
# ポリシーごとの成功・失敗件数
jq -r '.policies[] | [.policy."policy-type", .policy."policy-domain",
.summary."total-successful-session-count", .summary."total-failure-session-count"] | @tsv' report.json
# 失敗の内訳（種類・MX・IP・件数）
jq -r '.policies[] | ."failure-details"[]? | [."result-type",
(."receiving-mx-hostname" // "-"), (."receiving-ip" // "-"), ."failed-session-count"] | @tsv' report.json見るべきなのは、失敗が特定のMXホストに偏っているか、特定の送信事業者だけで起きているかです。全事業者で同じMXに同じ種類の失敗が出ていれば、原因はあなたのMX側にある可能性が高く、1社だけなら送信側の事情も考えられます。
失敗の種類ごとの確認と対処
result-type はRFC 8460で定められた値で、主なものは次のとおりです。
certificate-host-mismatch
MXサーバーの証明書に、MXホスト名が含まれていません。複数のMXのうち1台だけ証明書の設定が漏れている、というケースがよくあります。MXサーバーに直接つないで証明書を確認します。
openssl s_client -starttls smtp -connect mx2.example.com:25 -servername mx2.example.com </dev/null 2>/dev/null \
| openssl x509 -noout -subject -ext subjectAltName -enddate国内の家庭用回線などでは25番ポートへの外向きの接続が制限されていることが多いため、この確認はサーバーなど25番ポートに接続できる環境から行います。
certificate-expired / certificate-not-trusted
証明書の期限切れ、または信頼されていない証明書（自己署名や中間証明書の欠落）です。上のコマンドで期限を確認し、中間証明書を含めたチェーンが送られているかも見ます。自動更新を使っている場合は、更新後にメールサーバーが新しい証明書を読み込み直しているかも確認します。
starttls-not-supported
MXがSTARTTLSに対応していない、または特定のサーバーで無効になっています。メールサーバーの設定でSTARTTLSが有効か確認します。
sts-policy-fetch-error / sts-policy-invalid
送信側がポリシーファイルを取得できなかった、または書式が正しくなかったことを表します。次の点を確認します。
curl -sv https://mta-sts.example.com/.well-known/mta-sts.txt- HTTPSで200が返ること。リダイレクトは追わない決まりのため、別のURLへ転送する設定は失敗になります。
mta-sts.example.com用の有効な証明書があること。- Content-Type が
text/plainであること。 - 中身の
version、mode、mx、max_ageの書式が正しく、mxに実際のMXホスト名がすべて含まれていること。
sts-webpki-invalid / validation-failure
前者はポリシー取得時のHTTPS証明書の検証失敗、後者はそれ以外の検証エラーをまとめた種類です。additional-information や failure-reason-code に補足がある場合は、その内容を手がかりにします。
policy-type が no-policy-found になっている
MTA-STSを設定したつもりなのに no-policy-found と報告される場合は、_mta-sts のTXTレコードが見つかっていないか、ポリシーの取得に至っていません。TXTレコードの名前の綴りと、ポリシーファイルの公開状態を確認します。
enforce へ移るときの判断
MTA-STSは、まず mode: testing で公開し、レポートを数週間ほど観察してから mode: enforce に切り替えるのが安全です。testing では失敗してもメールは配送されますが、enforce ではポリシーに合わない接続での配送を送信側が見送るため、設定の不備がそのまま受信できない状態につながります。
切り替えの目安は、主要な送信事業者のレポートで失敗がほぼ無くなり、残った失敗の原因も説明できる状態です。ポリシーファイルを変更したら、_mta-sts のTXTレコードの id も新しい値に変えてください。id が変わらないと、送信側は更新に気づかず、キャッシュした古いポリシーを使い続けます。設定ファイルやDNSを変更する前には、現在の内容を控えておきます。
まとめ
- MTA-STSのレポートはTLS-RPTの仕組みで届くgzip圧縮のJSONで、受け取るには
_smtp._tlsのTXTレコードが必要。 - 報告されるのは、他社からあなたのMXへの配送の暗号化の結果。サイトからの送信メールの成否は含まれない。
summaryで失敗率をつかみ、failure-detailsのresult-typeとreceiving-mx-hostnameで原因の場所を絞る。jqで表にすると比較しやすい。- 証明書の不一致・期限切れ、ポリシーファイルの取得失敗が代表的な原因。openssl と curl でMXとポリシーファイルを直接確認する。
- testing で失敗が説明できる状態になってから enforce へ。ポリシー変更時はTXTレコードの id も更新する。