有効な出発点は v=spf1 レコードが 1 つであること
SPF ポリシーのないドメインは、SPF 許可の根拠を一切提供しません。v=spf1 の TXT レコードが複数あるドメインは、自動的に結合されるのではなく、SPF の永続エラーになります。
返されたレコードは、DNS が公開しているとおりに読んでください。古いプロバイダーの include、意図しない空白、誤ったサブドメインに置かれたポリシーは、いずれも結果を変えます。
無料ツール
SPF レコードチェッカー
任意のドメインを入力して、SPF レコードを取得・検証します。レコード全文、各メカニズムの解説、設定が正しいかを確認できます。
SPF レコードとは？
SPF（Sender Policy Framework）レコードは、特定のメールサーバーがドメインに代わってメールを送信することを許可する DNS TXT レコードです。DKIM および DMARC と並ぶ、3 つの中核的なメール認証プロトコルの 1 つです。メッセージが届くと、受信側メールサーバーは送信ドメインの SPF レコードを照会し、配信元 IP アドレスが許可されているかを確認します。
SPF はメール到達率の基盤です。有効な SPF レコードがないと、ドメインからのメールはスパム判定されたり、完全に拒否されたりする可能性が高まります。主要な受信トレイプロバイダー（Gmail、Outlook、Yahoo）は、SPF の結果を主要な信頼シグナルとして扱います。Google と Yahoo は、大量送信者の要件として SPF を必須としています。
SPF レコードは、許可された送信者を記述する一連のメカニズムを使います。一般的なメカニズムには、ip4 および ip6（特定の IP アドレスまたは範囲）、mx（ドメインのメールサーバー）、include（別ドメインの SPF レコードへの委任）があります。レコードは all メカニズムで終わり、明示的に列挙されていない送信者の扱いを定義します。~all（softfail）、-all（hardfail）、?all（neutral）です。
SPF メカニズムの解説
ip4
特定の IPv4 アドレスまたは CIDR 範囲を許可します。例: ip4:203.0.113.1 または ip4:203.0.113.0/24。
ip6
特定の IPv6 アドレスまたは範囲を許可します。例: ip6:2001:db8::1。
mx
ドメインの MX レコードに記載されたメールサーバーを許可します。送信と受信のメールサーバーが同じ場合に便利です。
include
別ドメインの SPF レコードを取り込み、評価します。Google Workspace や SendGrid などの第三者送信者を許可するために使います。
a
ドメインの A または AAAA レコードの IP アドレスを許可します。メールも送信する Web サーバーに便利です。
all
他のメカニズムに一致しなかった送信者に適用される Catch-All（包括指定）です。~(softfail)、-(hardfail)、?(neutral) の接頭辞を付けます。
ライブ DNS の根拠
SPF チェッカーがドメインの公開レコードから確認できること
SPF チェッカーは公開 TXT ポリシーを取得し、受信側が評価できる許可ルールを明らかにします。設定の診断であり、すべての実メッセージが合格することを保証するものではありません。
メカニズムは許可されたインフラを識別します
ip4 と ip6 はネットワークを直接指定します。include、a、mx、exists、redirect は追加の DNS 処理を引き起こし、別プロバイダーが管理するレコードに依存する場合があります。
ポリシーは構文的に正しくても、誤ったシステムを許可していることがあります。解析が成功したことを業務設定の承認と見なさず、各メカニズムを現行の送信者一覧と照合してください。
ポリシーを読む
SPF メカニズム、修飾子、照会負荷の解釈方法
有用な問いは、レコードが存在するかどうかだけではありません。レコードを評価できるか、許可の境界が実際のメールフローと一致しているかです。
Pass は接続元をその SPF 識別子について許可します
SPF が評価するのは MAIL FROM または HELO で使われるドメインであり、必ずしも表示上の From ヘッダーではありません。したがって、合格した送信元は技術的には許可されていても、受信者が見るアドレスとの DMARC アライメントには失敗することがあります。
Softfail、fail、neutral、permerror はそれぞれ異なる結果です
~all と -all は、一致しない送信元に対するポリシーの強さが異なります。?all は肯定的な主張をしません。無効な構文、重複ポリシー、過剰な DNS 評価は permerror を生じます。通常の fail として解釈せず、修正してください。
再帰的な include は 10 回照会の上限を隠すことがあります
include チェーン全体で、DNS を引き起こすメカニズムを数えてください。トップレベルのレコードに include が 2 つしかなくても、それらのプロバイダーが十分な a、mx、include、exists、redirect 操作に展開し、RFC の上限を超えることがあります。
広いポリシーは合格しても、保護が弱いことがあります
+all はすべての送信者を許可します。大きな IP 範囲や不要な include も、なりすましを容易にします。SPF チェッカーは、TXT 文字列が v=spf1 で始まることだけを確認するのではなく、許可範囲を狭める助けになるべきです。
診断ワークフロー
DNS の結果からメッセージ単位の証明まで、SPF レコードチェッカーを使う
規律ある確認は、公開ポリシーと実際の送信識別子をつなぎます。
- 1
エンベロープ送信者ドメインを正確に確認する
実際に送信したメッセージまたはプロバイダー設定を調べて return-path ドメインを特定し、組織のルートが評価されると仮定せず、そのドメインを照会してください。
- 2
各メカニズムを稼働中の送信者に対応づける
各 include、IP 範囲、a、mx の許可の所有者を特定してください。正当なメールを送らなくなったことを確認したあとでのみ、古い送信元を削除してください。
- 3
結果を Authentication-Results と比較する
すべての本番プラットフォームから送信し、受信ヘッダーの spf=、smtp.mailfrom、DMARC アライメントを確認してください。単独の DNS 照会では観測できない識別子の不一致を捕捉できます。
- 4
修正したポリシーを生成して公開する
レコードがない、または構造が誤っている場合は、SPF レコードジェネレーターで 1 つの統合ポリシーを作成し、公開し、DNS キャッシュの期限が切れたあと、このチェッカーを再実行してください。
結果の境界
SPF チェッカーが教えてくれないこと
SPF はドメイン単位のシグナルの 1 つです。受信者、コンテンツ、完全な認証に関する問いには、単体では答えられません。
表示上の From アドレスが保護されていることは証明しません
DMARC には、アライメントした SPF または DKIM の識別子が必要です。別の return-path ドメインは SPF に合格しても、表示上の From ドメインは保護されないままです。
DKIM や DMARC が機能していることは証明しません
それらの個別の DNS レコードとポリシーには、DKIM チェッカー と DMARC チェッカーを使ってください。
受信トレイへの到達は予測しません
受信側は認証に加え、送信レピュテーション、苦情率、コンテンツ、エンゲージメント、独自のフィルターを組み合わせます。SPF の合格は多くの送信者にとって必要な根拠ですが、受信トレイを保証するものではありません。
受信側メールボックスは検証しません
レコードは、ドメインの代わりに誰が送信してよいかを記述します。宛先アドレスがメールを受信できるかは、メール検証で確認してください。
プロトコルリファレンス
SPF の挙動を診断するときは RFC 7208 を使う
プロバイダーのダッシュボードは SPF を簡略化しますが、受信側は公開ポリシーをプロトコルに従って評価します。
RFC 7208 は公開と評価を定義します
IETF の RFC 7208 は、SPF の識別子、TXT レコード、メカニズム、修飾子、DNS 制限、結果コードを定義します。重複レコードと permerror の挙動についての公式リファレンスです。
確認から、送信者の完全な設定へ進む
SPF を修正したあと、DKIM ジェネレーターでメッセージ署名を追加し、DMARC ジェネレーターでアライメントしたポリシーを公開してください。
関連メールツール
次のツールは、証拠の種類で選んでください。受信者、発見、DNS とインフラ、送信者ワークフローです。
無料ツール
SPF レコード生成
数秒でドメイン用の有効な SPF DNS レコードを生成。メールサーバーと include ディレクティブを追加し、ポリシーを選択。無料、登録不要。
ドメインまたはインフラの証拠であり、メールボックスの証明ではありません。
無料ツール
DKIM チェッカー
任意のドメインとセレクターの DKIM レコードを確認。公開鍵の全文と、DKIM 署名が正しく設定されているかを表示します。無料、登録不要。
ドメインまたはインフラの証拠であり、メールボックスの証明ではありません。
無料ツール
DMARC チェッカー
任意のドメインの DMARC レコードを確認できます。ポリシー、アライメント設定、レポート送信先、設定の正しさを表示します。無料、登録不要。
ドメインまたはインフラの証拠であり、メールボックスの証明ではありません。
無料ツール
DNS チェッカー
任意のドメインの A、AAAA、MX、TXT、NS、CNAME レコードを確認できます。ライブ DNS 照会で即座に結果を表示します。無料、登録不要です。
ドメインまたはインフラの証拠であり、メールボックスの証明ではありません。
メールツール
メール到達性テスト
実際のメッセージサンプルでメール到達性テストを実行。SPF、DKIM、DMARC、DNS、ブラックリスト、スパムフィルター、ヘッダー、コンテンツ根拠を確認します。
送信者またはメッセージの診断であり、アドレス発見ではありません。
メール検証ツール
メールベリファイア
構文、MX、SMTP メールボックス、使い捨て、ロール、catch-all を実行する無料メール検証で、メールアドレスが有効かを確認します。
受信者の証拠であり、送信者や DNS 設定ではありません。
よくある質問
1. ドメインに SPF レコードがない場合、どうなりますか？
SPF レコードのないドメインは、SPF チェックに失敗します。受信サーバーはこれを中立（neutral）の結果として扱いますが、他のシグナルと組み合わさるとスパム判定の可能性が高まります。Google と Yahoo は、すべての大量送信者に SPF レコードを求めています。メールを送信するドメインは、いずれも SPF レコードを公開すべきです。
2. ドメインに複数の SPF レコードがある場合、どうなりますか？
同じドメインに v=spf1 で始まる TXT レコードが 2 つ以上あると、SPF の永続エラー（permerror）になります。SPF の評価は完全に失敗し、そのドメインからのすべてのメールが SPF に失敗します。すべてのルールを 1 つの SPF レコードにまとめる必要があります。
3. SPF fail とは何ですか？
SPF fail は、配信元 IP アドレスがドメインの SPF レコードで許可されていないことを意味します。結果は all メカニズムに依存します。~all は softfail（疑わしいが、通常は配信されます）を引き起こし、-all は hardfail（通常は拒否されるかスパムに振り分けられます）を引き起こします。中立の ?all はどちらにも影響しません。
4. SPF の permerror とは何ですか？
permerror（permanent error、永続エラー）は、設定上の問題により SPF を評価できないときに発生します。最も多い原因は、ドメインに複数の SPF レコードがある場合、またはレコードの DNS 照会メカニズムが多すぎる場合（10 を超える）です。permerror はドメインからのすべてのメールを SPF 失敗にするため、すぐに修正してください。
5. SPF レコードに include ディレクティブはいくつ置けますか？
SPF は評価中に最大 10 回の DNS 照会を許可します。include、a、mx、ptr、exists の各メカニズムは 1 回の照会として数えられ、それらの中の入れ子の include もカウントされます。合計照会が 10 を超えると permerror になります。
6. 長すぎる SPF レコードは、どう修正しますか？
SPF レコードが 10 回の照会上限に近づいている場合は、SPF flattening（フラット化）を検討してください。すべての include を実際の IP アドレスに解決し、include メカニズムを直接の ip4/ip6 エントリに置き換えます。これにより、それらのエントリの照会回数は 0 になりますが、プロバイダーが IP 範囲を変更するたびにレコードを更新する必要があります。