SPFレコード無料 チェッカー

SPFとは何か、そして2026年に重要な理由

Sender Policy Framework(SPF)は、DKIMやDMARCと並ぶ現代のメール認証の3本柱の1つです。RFC 7208で定義されており、ドメイン所有者がDNSに認可された送信サーバーのリストを公開することで、受信側のメールプロバイダーが受信メッセージが本当にそこから来ているかを検証できるようにします。SPFがなければ、誰でもあなたのドメインを装ってメールを送ることができ、GmailやYahooのような現代のプロバイダーは未認証メールを密かに迷惑メールに直接振り分けます。

2026年において、SPFはもはや任意ではありません。GmailとYahooの大量送信者要件(2024年に展開され、その後厳格化)では、1日5,000通を超えるメールを送信するドメインに対してSPFとDKIMを義務付けています。Microsoft 365とApple Mailも同様の基準を施行しています。設定ミスや欠落したSPFレコードは、迷惑メールフォルダ配置、収益損失、ブランドダメージに直結します。良いニュース:SPFは利用可能な配信性向上策の中で最も安価で迅速なものの1つです——正しく設定された単一のTXTレコードで、受信トレイ到達率が一夜にして20〜40%向上することがあります。

SPFレコードの構造

すべてのSPFレコードは、スペース区切りのメカニズムを含む単一のDNS TXTレコードです。Google WorkspaceとMailgunを使うドメインの典型的な例を以下に示します:

v=spf1 include:_spf.google.com include:mailgun.org ip4:203.0.113.10 ~all

• v=spf1 — バージョンタグ。すべてのSPFレコードはこれで始まる必要があります。v=spf2は存在しません——プロトコルは10年以上変更されていません。
• ip4: / ip6: — ip4: および ip6: — 明示的に許可されたIPアドレスまたはCIDR範囲。ip4:203.0.113.0/24はサブネット全体を認可します。これらはDNSルックアップを発生させないため最も安価なメカニズムです。
• include: — 別のドメインのSPFレコードを取り込みます。include:_spf.google.comは、Googleがそのテナント向けに認可するすべてのサーバーからのメールも受け入れるよう受信側に伝えます。各includeはDNSルックアップ1回としてカウントされ、ネストされたincludeも同様にカウントされます。
• a / mx — a および mx — ドメインのAレコード(ウェブサイトのサーバー)またはMXレコード(受信メールサーバー)のIPアドレスを認可します。控えめに使ってください:多くのドメインのウェブサーバーはメールを送信すべきではありません。
• 修飾子は結果を制御します。~all(ソフトフェイル)はマッチしないメールを疑わしいものとしてマークしますが受け入れます——テスト中に有用です。-all(ハードフェイル)はマッチしないメールを直接拒否します——本番推奨設定です。?all(neutral)は何もせず、無意味です。+allはインターネット上のすべてのIPを明示的に認可します——これは絶対に使わないでください。「私になりすましてください」と書かれた看板を玄関に置いたまま家を出るのと同じです。

SPFのよくある5つのエラーと修正方法

DNSルックアップが多すぎる(RFC 7208の制限:10回)

SPFは評価あたり最大10回のDNSルックアップを許可します。各include:、a:、mx:、exists:、redirect=がカウントされます。ネストされたincludeもカウントされます——include:_spf.google.com自体に4つのincludeが含まれている場合、その1つのメカニズムで5回のルックアップになります。制限を超えるとPermErrorが発生し、ほとんどの受信側はそれをハードフェイルとして扱います。修正方法:上記のSPFチェッカーですべてのincludeを監査し、未使用のベンダーを削除し、ベンダーが静的範囲を公開している場合はinclude:をip4:ブロックに置き換えるか、フラット化サービスを使ってください。

PermError:SPFレコードの構文が無効

よくある構文ミスには、v=spf1プレフィックスの欠落、スペースの代わりにセミコロンを使用、コピーペーストからの余分な文字、または修飾子(~all)をレコードの最後ではなく途中に置くことが含まれます。受信側はこれを設定の失敗と見なし、SPFを完全に失敗させます。修正方法:正確なレコードをバリデータに貼り付け、隠れたUnicode文字を探し、メカニズムがスペース区切りでall修飾子が最後にあることを確認してください。

複数のSPFレコード(統合が必要)

RFC 7208は、同じドメイン上の複数のv=spf1 TXTレコードを明示的に禁止しています。これは通常、あるチームがGoogle Workspaceを追加し、別のチームがSendGridを調整なしに追加したときに発生します。2つのレコードを見た受信側はPermErrorをスローします。修正方法:単一のレコードに統合します。v=spf1 include:_spf.google.com include:sendgrid.net ~allが両方の個別レコードを置き換えます。

v=spf1 include:_spf.google.com include:sendgrid.net ~all

転送がSPFを壊す

受信者があなたのメッセージを別のアドレスに転送するとき、接続元IPは変わりますがReturn-Pathはあなたのまま——そのため転送ホップでSPFが失敗します。これは設計上の挙動ですが偽陰性を引き起こします。修正方法:アライメントにDKIMを頼る(DKIMは転送を生き延びる)、自分が管理する送信転送機能でSRSを実装する、SPFだけでは不十分であることを受け入れる——だからこそDMARCはSPFまたはDKIMを要求し、両方は要求しないのです。

サブドメインの継承の混乱

SPFは継承されません。mail.example.comとexample.comは別のホストであり、別々のSPFレコードが必要です。よくあるバグ:会社がエイペックスにSPFを公開しているが、マーケティングツールがupdates.example.comから送信している——受信側はサブドメインにSPFレコードがないと判断し、メールはアライメントに失敗します。修正方法:メールを送信すべきでないすべてのサブドメインにv=spf1 -allを公開し、送信するすべてのサブドメインに本物のポリシーを公開してください。

SPF設定のステップバイステップ

1. すべての送信サービスを棚卸しする

あなたのドメインを使ってメールを送信するすべてのシステムをリストアップしてください:マーケティングプラットフォーム(Mailchimp、HubSpot)、トランザクションプロバイダー(SendGrid、Postmark、Resend)、CRM、サポートデスク(Zendesk、Intercom)、給与計算、決済処理、自分のアプリケーションサーバー。1つでも漏れると、レコード公開後に正規メールが拒否されます。

2. フェイルポリシーを選ぶ(~all vs -all)

最初の1〜2週間はDMARCレポートで予期しないソースを監視しながら~all(ソフトフェイル)で開始します。すべての正規送信者がレコードに含まれていることを確認し、DMARCレポートが100%パス率を示したら、最大の保護のために-allに切り替えます。

3. レコードを構築する

可能な限りベンダーが公開しているinclude:メカニズム(例:include:_spf.google.com)を使ってください。includeのないサービスについては、公開されたIP範囲とともにip4:を使います。すべてのincludeとそのネストされたルックアップをカウントして、レコードを10ルックアップ制限内に保ちます。単一の修飾子で終わってください——~allまたは-all——両方を使ってはいけません。

4. TXTレコードをDNSに追加する

DNSプロバイダーのコントロールパネルで、host = @(またはドメインのエイペックス)、value = 引用符で囲んだSPF文字列全体の新しいTXTレコードを作成します。TTL 3600(1時間)が良いデフォルトです。DNSプロバイダーが自動的に引用符を付ける場合は、二重引用符にしないでください。

5. 検証して監視する

上記のチェッカーで、レコードがクリーンに解析され、ルックアップ数が10未満で、ポリシーが正しく設定されていることを確認します。次にmail-tester.comと自分のGmail/Outlookアカウントにテストメールを送信してください。rua=レポート付きのDMARCを設定し、見落とした送信者をキャッチします。継続的に監視してください——ベンダーIPは変わり、includeは追加され、半年前にクリーンだったSPFレコードが密かに壊れることがあります。

10回のDNSルックアップ制限を超えないようにする方法

10ルックアップ制限は、大規模でのSPF失敗の最も一般的な原因です。各include:はDNSクエリをトリガーし、includeをそれ自体が含むincludeはさらにトリガーします——たとえばSalesforceのSPFは単独で8回以上のルックアップに解決できます。3つの戦略で制限内に保ちます。1つ目、容赦なく監査する:もはや使っていないベンダーはレコードから削除する必要があります。月次でチェッカーを実行し、不要なincludeを削除してください。

2つ目、ベンダーが安定したIP範囲を公開している場合、include:をip4:に置き換えます。SendGrid、Mailgun、Amazon SESはすべて静的ブロックを公開しています。include:sendgrid.netの代わりにip4:198.61.254.0/24を使うと、2回ではなく0回のルックアップで済みます。トレードオフはメンテナンスです——ベンダーが新しいIPを追加したときに手動で更新する必要があります。

3つ目、避けられないネストされたincludeにはSPFフラット化サービス(例:easydmarc.com、dmarcian)を使います。これらのサービスはすべてのincludeをip4:ブロックのフラットなリストに解決し、1つのincludeで参照する単一のホスト型SPFレコードとして再公開します。デメリットはサードパーティへの運用依存です——慎重に評価し、停止を監視してください。

SPF、DKIM、DMARC:連携の仕組み

SPFだけでは不十分です。3つのプロトコルは多層防御を構成します:SPFは送信サーバーのIPを認証し、DKIMはメッセージ内容に暗号署名し、DMARCはこれらを可視のFromアドレスと結びつけ、認証が失敗したときの対応を受信者に指示します。SPFは転送で壊れ、DKIMは転送を生き延びますが鍵ペアを生成してDNSに公開鍵を追加する必要があるためデプロイが難しくなります。両方を組み合わせるとDMARCのアライメントは、SPFまたはDKIMのいずれかがパスすればパスするため、両方をデプロイすると、転送、メーリングリスト、ARC信頼チェーンが一般的な現実の配信シナリオで冗長性と完全なカバレッジが得られます。DMARCがなければ、SPFとDKIMは診断ツールに過ぎず、受信側は結果を緩く使うか無視するかもしれません。p=rejectのDMARCを使えば、認証ポリシーを公開的にコミットし、地球上のすべての受信側になりすましメールを直接破棄するよう指示できます。これが現代のメールセキュリティ標準であり、クリーンなSPFレコードから始まります。推奨されるデプロイ順序は:まずSPF(TXTレコード1つ、即時の影響)、次にDKIM(鍵生成とDNS)、その後rua=レポート付きp=noneのDMARCで2週間の監視、その後段階的にp=quarantineへ、最終的にp=rejectへ厳格化します。監視をスキップすることが、DMARCロールアウト中に正規メールが破棄される最も一般的な原因です。

GmailとYahoo 2026年要件

2024年2月以降、GmailとYahooは、ユーザーに1日5,000通以上のメッセージを送信するすべての大量送信者に対して、SPF、DKIM、DMARCを公開し、ワンクリック登録解除ヘッダー(Post URL付きのList-Unsubscribe)を維持し、Postmaster Toolsで測定される迷惑メール苦情率を0.3%未満に保つことを要求しています。Microsoft 365はSmartScreenを通じて同様のルールを施行し、Apple MailはiCloudと管理対象Apple ID全体でDMARCを厳格に追従しています。2026年にはこれらの基準がさらに厳格化されました:DMARCは未認証の大量トラフィックに対してp=quarantineまたはそれ以上である必要があり、転送メールの評価チェーンにARC信頼が追加され、苦情率0.1%超で配信が削減されるようになりました——0.3%のハードキャップに達する前にです。失敗はソフトな警告ではありません——あなたのメールは迷惑メールに送られるか、SMTP層で直接拒否されます。非バルク送信者でさえも影響を受けます。フィルタは一般化するためです:1日200通を送信するB2B送信者でも、Gmailの機械学習分類器がすべてのメッセージのスコアリングに同じ認証シグナルを再利用するため、クリーンなSPF、DKIM、DMARCの恩恵を受けます。要するに、SPFはもはやベストプラクティスではありません——配信性の前提条件です。今日上記のチェッカーを実行してSPFがパスすることを確認し、その後DKIMとDMARCに進んでスタックを完成させてください。

関連ガイド

• DMARC Policy Setup Guide — How SPF fits into the full email authentication stack