SPFレコード生成ツールの検証方法とDNS公開前の注意点

無料のSPFレコード生成ツールを見つけ、Google Workspace、Mailchimp、CRMなどの項目をすべて選び、生成結果をそのままDNSに貼り付けたとします。二週間後、Gmailで請求書メールが550 5.7.26として拒否され、Outlookから550 5.7.515が返されることがあります。その結果、サポートへの問い合わせが増えてしまいます。

SPFレコード生成ツールが出力したのは、構文上は有効な内容です。しかし、実際に機能するレコードとは限りません。この隔たりがメール到達率に影響することがあります。DNS設定全体をまだ構築している場合は、まず独自ドメインでメールを設定する方法を確認してください。SPFは、MX、DKIM、DMARCを含む全体構成の一部です。

このガイドでは、自動生成ツールの出力が本番環境で機能しない理由、手元のツールを使って五分で監査する方法、そして本番運用に適したSPFレコードの構成を解説します。

SPFレコード生成ツールが実際に行うこと

SPFレコード生成ツールは、選択した項目に応じてプロバイダー固有のinclude:メカニズムを連結し、TXT形式のDNSレコードを作成するウェブツールです。送信サービスを選ぶと文字列が生成されます。ただし、通常は実際のDNSを照会せず、再帰的なルックアップ数も数えません。また、ドメインに既存のSPFレコードがいくつあるかも把握していません。

無料のSPFレコード生成ツールの多くは、実質的には文字列を組み立てるだけのものです。見た目が正しい出力は作れても、実際のDNS環境で機能するかまでは検証しません。構文が正しいことと、運用上問題なく機能することは別です。

SPFレコード生成ツールが見落としやすい3つの障害

本番環境で起きる重大なSPF障害の多くは、次の三つの問題に起因します。一般的なSPFレコード生成ツールは実際のDNSデータにアクセスできず、受信側が評価時に使うルックアップ計数ロジックも備えていないため、これらを検出できないことがあります。

1. レコード重複によるPermError

一つのドメインに設定するSPFレコードは一つです。RFC 7208では、受信サーバーがv=spf1で始まるTXTレコードを二つ検出すると、永続的エラーであるPermErrorを返すと規定されています。GmailやYahooでは、PermErrorがSPF未設定と同様に扱われることがあり、メールがバウンスしたり迷惑メールに振り分けられたりする可能性があります。

生成ツールは通常、既存レコードを確認しません。ドメインを数か月以上運用しているなら、レジストラ、以前のホスティング事業者、あるいは三年前にGoogle Workspaceを設定した担当者によるレコードが、すでに存在する可能性があります。確認せずに生成結果を公開するとレコードが重複し、それまで機能していた設定を壊すおそれがあります。

2. 再帰ルックアップの上限

RFC 7208では、SPF評価時のDNSルックアップを10回までに制限しています。この数には、各include:、a、mx、exists、redirectに加え、includeの内部で発生する入れ子のルックアップも含まれます。SPFレコード生成ツールは選択したメカニズムを数えても、その内部までは数えない場合があります。

生成ツールの表示は4回でも、受信サーバーが#11回目に達した時点で評価を中断する可能性があります。その場合、ドメインからのメールがSPFに失敗する可能性があります。画面に警告が出ず、バウンス通知も届かないことがあり、顧客からの連絡で初めて気付くケースもあります。

3. 空のルックアップの上限（RFC 7208 §11.1）

もう一つの制約として、空の結果（NXDOMAIN）を返すDNSクエリは2回までです。include:の入力ミスが一つあるだけで、空のルックアップが発生します。このような誤りが二つあると、生成ツールの構文チェックを通過していても、SPFレコード全体が失敗する可能性があります。

例：include:spf.trekmaill.net（「l」が一つ多い）。構文上は有効なので、SPFレコード生成ツールが正しいと判定することがあります。受信サーバーが照会しても結果が見つからず、空のルックアップ#1になります。誤ったincludeがもう一つあれば、レコード全体が失敗する可能性があります。

公開前にSPFレコード生成ツールの出力を監査する方法

SPFレコード生成ツールの出力を公開する前に、実際のDNSに対して次の三項目を確認してください。所要時間は通常五分ほどで、生成ツールが見落としやすい重大な問題を確認できます。対象は、重複レコード、過剰なルックアップ階層、壊れた構文です。macOS、Linux、Windowsのコマンドプロンプトで利用できます。

手順1：既存レコードを確認する

DNSを変更する前に、次のコマンドを実行します。

nslookup -type=txt yourdomain.com

v=spf1で始まる行が二つあれば、レコードが重複しています。新しい内容を公開する前に、手作業で一つのレコードに統合してください。

# Broken - two records, PermError guaranteed:
"v=spf1 include:_spf.google.com -all"
"v=spf1 include:spf.trekmail.net -all"

# Fixed - merged into one:
v=spf1 include:_spf.google.com include:spf.trekmail.net -all

手順2：再帰ルックアップを数える

レコード内の各include:について、その内容を照会します。

dig +short txt _spf.google.com

出力：

"v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"

このinclude:_spf.google.comだけで、実際には4回のルックアップが発生します。レコード内の各プロバイダーについて同様に確認し、合計してください。合計が10を超える場合は構成を見直す必要があります。一般的な方法は、トランザクションメールをサブドメイン（send.yourdomain.com）に移し、より短い専用レコードを設定することです。

手順3：メカニズムを監査する

SPFレコード生成ツールが作成した文字列を、次の表と照らし合わせてください。

SPF構文チェックリスト

初稿をSPFレコード生成ツールで作った場合も、文字列を手作業で記述した場合も、DNSに触れる前に次の項目を確認してください。重複レコード、再帰ルックアップの上限、安全性の低いポリシーフラグなど、生成ツールでは検出できないことがある障害を確認できます。

1. 一ドメインにつき一レコード。重複している場合は統合し、二つのレコードを公開しないでください。
2. v=spf1で始める。別表記は使わず、文字列を正確に記述します。
3. -allまたは~allで終える。+allや?allは使用しないでください。
4. IPをincludeより前に置く。ip4:とip6:のメカニズムはDNSルックアップを消費しません。先に記述すると、評価時間の短縮に役立ちます。
5. 自己参照を避ける。include:yourdomain.comは無限ループを作るため、削除します。
6. IPを手作業でフラット化しないでください。ただし、最新状態を維持する自動化がある場合は除きます。GoogleがIPを変更した際に更新しなければ、目立った通知がないままメール送信に支障が出る可能性があります。
7. ルックアップ合計 ≤ 10。入れ子のincludeを含め、すべて数えます。

本番運用向けレコードの例：

v=spf1 ip4:192.0.2.1 include:spf.trekmail.net include:_spf.google.com -all

IPを先に置き（ルックアップを消費しません）、次にincludeを並べ、最後をHardFailにします。基本構成はこれだけです。

制作会社や中小企業がSPFレコード生成ツールだけでは対応しにくくなる理由

一つのドメインと一つか二つの送信サービスだけなら、SPFレコード生成ツールは導入時に役立ちます。しかし規模が拡大し、制作会社が数十社のクライアントを管理したり、中小企業が多数のSaaSを利用したりすると、運用上のリスクが繰り返し発生しやすくなります。ポートフォリオ全体のルックアップ数や重複レコードを一元的に把握できないためです。

従来の方法では、クライアントごとに異なる生成ツールのセッションから個別のSPFレコードを作り、監査履歴も残りません。あるドメインがルックアップ上限に達しても、三日間気付かれないことがあります。その間に、クライアントの配信評価が損なわれる可能性があります。

ビジネスレベルでメール基盤を保護する方法を包括的に知るには、ビジネスメールを保護するためのガイドをご覧ください。SPFだけでなく、必要な基本対策全体を解説しています。

TrekMailでSPF生成ツールに伴う問題を減らす方法

SPFが複雑になる主な理由は、複数の外部送信サービスを管理しながら、10回のルックアップ上限を超えないようにする必要があるためです。主要なメール基盤にTrekMailを使用すると、両方の負担を軽減できます。そのため、中心となる送信ドメインでは、SPFレコード生成ツールの実行、入れ子のルックアップの計数、メカニズムの監査を繰り返す必要が少なくなります。

中小企業向け：一つのIncludeで保守を簡素化

TrekMailのStarterプラン（$3.50/月）では、送信メールがTrekMailのマネージドSMTPを経由します。SPFレコードは次の一行にまとめられます。

v=spf1 include:spf.trekmail.net -all

TrekMailは、このincludeの背後でIPローテーションと送信者評価を管理します。そのため、レコードを頻繁に変更したり、SPFレコード生成ツールを再び使ったりする必要は通常ありません。ただし、六か月後に新しいSaaSツールを追加する際は、実際の送信構成に応じて再監査の要否を確認してください。

制作会社向け：各クライアントに一つのテンプレート

従来の方法では、100社のクライアントに対して100回の異なる生成作業から100個のSPFレコードを作り、それぞれが再帰ルックアップのリスクを抱えます。いずれかのレコードが、通知されないまま失敗する可能性もあります。

TrekMailでは、各クライアントのドメインに同じテンプレートを使用できます。

v=spf1 include:spf.trekmail.net -all

Agencyプラン（$23.25/月）では、一つのダッシュボードから1,000+個のドメインを管理できます。社内メールをTrekMailに標準化すると、主要な通信経路における再帰ルックアップの問題を減らせます。複数ドメインの構成を拡張している場合は、マルチドメインメールホスティングによって管理方法がどう変わるかをご覧ください。

TrekMailでSPFと併せて必要となるDNS設定全体については、必要なDNSレコードのドキュメントをご覧ください。MX、DKIM、DMARCを含む四種類をまとめて解説しています。

SPFレコード生成ツールのよくある質問

初めてSPFレコード生成ツールを使った後、出力したレコードが機能しない場合によく生じる疑問をまとめました。いずれも、生成ツールが確認する構文検証と、実際のDNS確認が必要な運用上の検証との差に関係しています。

二つの生成ツールで出力を相互確認できますか？

可能ですが、二つ目のSPFレコード生成ツールを使っても根本的な問題は解決しません。異なるツールから異なる文字列が出力されることがあり、どちらも実際のDNSにある重複レコードを検出したり、再帰ルックアップを正確に数えたりできるとは限りません。上記のCLI手順が、より信頼性の高い確認方法です。

生成ツールでは有効と表示されるのに、なぜメールがバウンスするのですか？

SPFレコード生成ツールにおける「有効」は、通常、構文が正しいことを意味するだけで、実際の環境で機能することまでは保証しません。この食い違いの一般的な原因は、重複レコードによるPermErrorと、10回を超える再帰ルックアップです。いずれも画面上の検証だけでなく、実際のDNSを確認する必要があります。

-allと~allはいつ使い分けますか？

本番環境では通常、-all（HardFail）を使用し、未承認の送信元を拒否します。送信元をすべて列挙できたか確信がない移行期間に限り、~all（SoftFail）を使用します。これは一時的な状態であり、最終設定ではありません。?allや+allを初期値とするSPFレコード生成ツールは、適切な到達性ポリシーよりも、表面的に機能して見えることを優先している可能性があります。

要点

無料のSPFレコード生成ツールは、文字列の初稿を作る出発点としては便利です。しかし、そのまま本番運用の最終設定にするのは適切ではありません。生成ツールが見落としやすい重複レコード、再帰ルックアップ超過、空のルックアップエラーは、気付きにくいバウンスやPermErrorにつながり、原因の特定に時間がかかることがあります。

必要なのは、より高機能なSPFレコード生成ツールとは限りません。五分ほどのCLI監査で、重複レコードを確認し、入れ子のルックアップを数え、メカニズムを点検してから公開します。

生成ツールを使う工程自体を省きたい場合、TrekMailでは送信経路を一つのinclude:に集約できます。DNSの中心的な設定は一行になり、ルックアップの計算やPermErrorの調査にかかる負担を減らせます。

14日間の無料トライアルを開始できます。クレジットカードが必要で、いつでも解約できます。