2026年9月23日

TLS-RPTとSPFを併用する設定｜役割の違い、TXTレコードの置き場所、よくある書き間違い

DNS・名前解決

TLS-RPT と SPF は、同じドメインに両方設定しても衝突しません。SPF はドメイン直下（example.com）の TXT レコード、TLS-RPT は _smtp._tls.example.com の TXT レコードと、置き場所も役割も別だからです。この記事では、2つの仕組みが何を担当しているかを整理したうえで、DNS への書き方、確認コマンド、管理画面で起きやすい入力ミス、メール事業者を移行するときの順序までを説明します。

2つの仕組みは「送信」と「受信」で担当が分かれる

最初に、それぞれが守っている方向を押さえておくと、設定で迷わなくなります。

SPF: あなたのドメインを名乗って送られるメールについて、「このサーバーから送ってよい」と受信側に宣言する仕組みです。WordPress のお問い合わせフォームの通知、WooCommerce の注文メール、メルマガ配信サービスなど、送信元になるサーバーを列挙します。
TLS-RPT: あなたのドメインの MX（メールサーバー）がメールを受け取るときに、相手のサーバーが TLS で暗号化して接続できたかどうかを、日ごとのレポートで知らせてもらう仕組みです（RFC 8460）。MTA-STS や DANE で暗号化を求めている場合、その検証に失敗した件数や理由もレポートに含まれます。

つまり SPF は「自分が送るメールの正当性」、TLS-RPT は「自分が受け取るメールの経路の安全性」を扱います。片方を設定しても、もう片方の代わりにはなりません。

DNSレコードの置き場所と書き方

SPF はドメイン直下に1つだけ

SPF はドメイン名そのもの（ホスト名を空欄や @ にする場所）に TXT レコードとして置きます。

example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com include:spf.example-mail.net -all"

同じ名前に v=spf1 で始まる TXT レコードが2つあると、SPF の評価はエラー（permerror）になります。送信サービスを追加するときは新しいレコードを作らず、既存のレコードに include: を書き足します。また、include: などで発生する DNS 参照は合計10回までという上限があります。サービスを足し続けると上限を超えやすいので、使っていないサービスは削除します。

TLS-RPT は `_smtp._tls` に置く

TLS-RPT は、ドメイン直下ではなく _smtp._tls というサブドメインに TXT レコードを作ります。

_smtp._tls.example.com.  3600  IN  TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

rua= にはレポートの送り先を書きます。mailto: のほか、HTTPS で受け取る https: 形式も規格上は使えます。送り先を複数にするときはカンマで区切ります。

この2つは名前が違うので、同じゾーンに並べても互いに影響しません。SPF の文字列に TLS-RPT の内容を混ぜたり、TLS-RPT をドメイン直下に置いたりする必要はありません。

管理画面で起きやすい入力ミス

DNS の管理画面によって、ホスト名欄の扱いが異なります。次の3点は、設定後に確認すると見つかりやすい誤りです。

ドメイン名の二重付与: ホスト名欄に _smtp._tls.example.com と入力すると、画面によっては末尾にドメイン名が自動で付き、_smtp._tls.example.com.example.com になります。多くの画面では _smtp._tls だけを入力します。
SPF の二重登録: メール事業者の手順書どおりに「新しい TXT レコードを追加」した結果、古い SPF と新しい SPF が並んでしまう例がよくあります。
引用符や全角文字の混入: コピー時に全角のセミコロンや余計な引用符が入ると、受信側はレコードを解釈できません。

digで確かめる

設定後は、管理画面の表示ではなく、実際に DNS が返す値を確認します。

# SPF（ドメイン直下の TXT から v=spf1 を探す）
dig TXT example.com +short | grep 'v=spf1'

# TLS-RPT
dig TXT _smtp._tls.example.com +short

# 権威DNSに直接聞いて、キャッシュの影響を除く
dig TXT _smtp._tls.example.com @ns1.example-dns.net +short

SPF の行が2つ出る場合は統合が必要です。TLS-RPT が何も返らない場合は、ホスト名の入力やレコードの種類を見直します。

レポートの受け取りでつまずく点

レポート用の受信箱にSPFの追加は要らない

TLS-RPT のレポートは、Google や Microsoft などの送信側事業者が、自社のドメインから送ってきます。あなたのドメインの SPF はこの受信には関係しないため、レポートの処理サービスを使う場合でも、そのサービスを SPF の include: に加える必要はありません。SPF に加えるのは、あなたのドメインを名乗ってメールを送るサービスだけです。ここを混同して不要な include: を足すと、参照回数の上限に近づくだけになります。

レポートが迷惑メールに振り分けられる

レポートは JSON を gzip で圧縮した添付ファイルとして届くことが多く、受信側のフィルターによっては隔離されます。専用のアドレス（例: tlsrpt@）を作り、そのアドレス宛ては隔離しないように設定しておくと取りこぼしを防げます。届く頻度は送信側事業者によって異なり、1日に1通程度が目安です。

レポートを別ドメインで受け取る

DMARC では、別ドメインの宛先にレポートを送るとき、受け取る側のドメインに許可のレコードが必要です。TLS-RPT の規格にはこの仕組みがなく、rua= に別ドメインのアドレスを書くだけで送られます。ただし、送信側事業者の実装に差がある可能性もあるため、設定後に実際にレポートが届くかを数日見て確認してください。

メール事業者を移行するときの順序

Google Workspace や Microsoft 365 などへメールを移すときは、SPF と TLS-RPT（と MTA-STS）を一度に変えると、どこで問題が起きたのか分からなくなります。次の順序が安全です。

事前に TTL を短くする: MX、SPF の TXT、MTA-STS 関連レコードの TTL を 300 秒程度に下げ、数日待ちます。
SPF に新しい送信元を追加する: 移行期間は旧事業者と新事業者の両方を include: に並べます。
MTA-STS を使っている場合はポリシーを先に更新する: ポリシーファイルの mx: 行に新しい MX を追加し、_mta-sts の TXT レコードの id= を変えて更新を知らせます。新しい MX がポリシーに書かれていないと、enforce のままでは受信が失敗します。不安があれば、移行期間だけ mode: testing に戻します。
MX を切り替える: 切り替え後数日は TLS-RPT のレポートで、新しい MX への接続に失敗が出ていないかを確認します。
旧事業者を SPF から外す: 旧環境からの送信が止まったことを確認してから削除します。

WordPress からのメールを SMTP プラグイン（WP Mail SMTP など）で外部サービス経由にしている場合は、その送信サービスも SPF に含まれているかを最後に見直します。

SPFとTLS-RPTの次に考えること

SPF だけでは、メールの本文や差出人表示の改ざんまでは防げません。送信側は DKIM と DMARC を組み合わせて初めて、なりすまし対策として機能します。受信側では、TLS-RPT のレポートで失敗がないことを確かめてから MTA-STS を enforce に進める、という使い方が一般的です。TLS-RPT 単体では暗号化を強制しないので、「設定したから受信経路が守られた」とは考えないようにします。

規格の対応状況や、どの事業者がレポートを送ってくるかは変わることがあります（2026年10月現在）。設定前に、利用しているメール事業者のヘルプで対応状況を確認してください。

まとめ

SPF は送信の正当性、TLS-RPT は受信経路の暗号化の状況を扱い、役割が重なりません。
SPF はドメイン直下に1つ、TLS-RPT は _smtp._tls に置くので、併用しても衝突しません。
管理画面ではドメイン名の二重付与と SPF の二重登録に注意し、dig で実際の応答を確認します。
レポート受け取りのために SPF を変える必要はありません。専用アドレスを作り、隔離されないようにします。
メール事業者の移行は、TTL を下げる、SPF に追加、MX 切り替え、旧送信元の削除の順に進めます。