SPF レコードが見つからない — でも設定したはず？5つの本当の原因（2026）

公開日 2026-07-08

データ基準日：2026-06-29 · 方法論 v7。 261 百万件のグレード済みドメインに対する集計センサスデータ。グレード方法についてはこちら。

チェッカーが「SPF レコードが見つからない」と言っても、設定したのに見当たらないなら、レコードは欠落しているのではなく「見えない」状態にあることがほとんどです。Defaults.Exposed による 261 百万件のドメインセンサスによると、1,013,416 件のドメイン — SPF を試みているドメインの約 138 件に 1 件 — が 2 つ以上の SPF レコードを公開しており、RFC 7208 §3.2 の PermError（多くのチェッカーが「見つからない」と報告する）を引き起こしています。

本当の原因は 5 つあり、どれも 1 回の作業で修正できます：ホストが間違っている、レコードが重複している、DNS タイプが間違っているかクォートが崩れている、ネームサーバーが一致していない、長さまたは CNAME の競合。以下に、確認すべき順番での各 60 秒のテストと修正手順を示します。

レコードが本当に存在するか確認する

最も一般的なケースから始めましょう。Defaults.Exposed センサスでグレードされた 261,086,232 件のドメインのうち、121,145,609 件 — 46.4% — には SPF レコードが全くありません。「設定したはずなのに」というケースの多くは、ステージングゾーンや、もはや権威を持たない古い DNS プロバイダーに追加されたレコードだったことが判明します。ネームサーバーが実際に指している DNS プロバイダー（多くの場合、レジストラとは異なります）で v=spf1 で始まる TXT レコードを確認してください。本当に存在しない場合は、調査を省略して SPF レコードの修正に直接進んでください。

SPF レコードを正しく確認する方法

Web チェッカーは自分のキャッシュリゾルバーを通じて DNS をクエリします。実際の状況を確認するには、ドメインの権威ネームサーバーに直接問い合わせてください：

# 権威ネームサーバーを見つける
dig NS yourdomain.com +short

# その 1 つに TXT レコードを直接問い合わせる
dig TXT yourdomain.com @ns1.yourdnshost.com +short

Windows の場合：nslookup -type=TXT yourdomain.com ns1.yourdnshost.com

解釈の 2 つのルール。第一に、v=spf1 で始まる行を数える — その数がコンテンツと同じくらい重要です。第二に、正しい名前をクエリしているか確認する：受信者はReturn-Path（RFC5321.MailFrom、「エンベロープ From」） のドメインに対して SPF を評価します — 受信者が見る From アドレスではありません。ニュースレターツールが bounce.yourdomain.com 経由でメールをバウンスする場合、頂点のレコードが完璧でも、受信者が調べるレコードではありません。

5 つの本当の原因とは

#	原因	60 秒テスト	修正
1	レコードが間違ったホストにある（サブドメイン vs 頂点）	Return-Path の正確なドメインを `dig TXT`	実際に送信する名前に公開する
2	2 つ以上の `v=spf1` レコード = PermError	`dig TXT` で 2 件以上の `v=spf1` 行が返る	ちょうど 1 つのレコードにマージする
3	タイプ 99 として公開、またはクォートが崩れている	レコードのタイプと余分なクォートを確認	1 つのきれいな TXT レコードとして再公開
4	キャッシュが古い・ネームサーバーが一致していない	各 NS に直接クエリして回答を比較	遅れているネームサーバーを修正し、古い TTL が切れるのを待つ
5	255 文字を超える分割または CNAME の競合	壊れた文字列チャンクまたは同じ名前の CNAME を探す	プロバイダーに文字列を正しく分割させ、CNAME された名前からレコードを移動

データ基準日：2026-06-29。

1. レコードが間違ったホストにあるか？

よくあるパターン：メールが yourdomain.com から来るのに SPF が mail.yourdomain.com に追加されている、またはその逆。SPF は下位継承しません — 頂点のレコードはサブドメインについて何も言っておらず、その逆も同様です。Return-Path の名前と正確に一致する場所に公開してください。独自のバウンスサブドメインから送信するベンダーは、そのサブドメインにレコードが必要です — 通常、ベンダーが提供する CNAME または TXT です（GoDaddy の SPF セットアップガイドにはこれらのフィールドの場所が示されています）。

2. SPF レコードが 2 つあるか？

最も見出しになる原因であり、メール認証において最も誤解を招くエラーメッセージです。RFC 7208 §3.2 は明確です：ドメインはちょうど 1 つの SPF レコードを持たなければなりません。2 つ以上あると PermError になり、受信者はどちらが権威を持つか推測する代わりに SPF を無効として扱います。一部のチェッカーはこの状態を正確に報告します（「複数のレコードが見つかりました」）が、純粋な結果を報告するものもあります：有効な SPF レコードが見つかりません。パネルでレコードを確認してチェッカーが壊れていると結論付けます。そうではありません — レコードが 1 つ多すぎるのです。

センサスでは、1,013,416 件のドメインが 2 つ以上の SPF レコードを持っていることが判明しました — SPF を試みているドメインの約 138 件に 1 件 — すべて SPF が事実上無効になっています。通常、プロバイダー変更の際に発生します：新しいプロバイダーのウィザードが古いものを編集するのではなく、新しいレコードを追加してしまうのです。修正はマージであり、2 番目のレコードを追加することではありません：すべてを 1 つの v=spf1 … ~all 行にまとめ、残りを削除してください。詳細は2 つの SPF レコードはないも同然をご覧ください。マイグレーション後に発生した場合は、プロバイダー切り替え後に SPF が動作しなくなった場合を参照してください。マージする際は、すべての include: を盲目的に連結しないでください — それぞれが SPF の 10 という上限に対して DNS ルックアップを消費し、「見つからない」から PermError: DNS ルックアップ過多に変わることがあります。

3. 間違ったレコードタイプを公開したか、UI が壊したか？

初期の SPF には独自の DNS レコードタイプがありました（タイプ 99、文字通り「SPF」と名付けられていました）。廃止されました：RFC 7208 は TXT を要求し、受信者はタイプ 99 をクエリしません。一部の DNS パネルはまだレコードタイプのドロップダウンに「SPF」を提供しています；それを選択するとレコードは実際に存在し、整形されており、見えません。タイプカラムを確認して TXT として再公開してください。

より微妙な問題はクォートです。クォートで囲まれた値を、独自にクォートを追加するフィールドに貼り付けると ""v=spf1 …"" が生成されます — これはもはや v=spf1 で始まらないため、検証者にとっては存在しないも同然です。dig の出力が真実を示します；DNS パネルは視覚的にそれを隠すことがよくあります。

4. 本当に「まだ伝播中」なのか？

「伝播するまで 24〜48 時間かかります」は DNS において最も過剰に処方されるアドバイスです。伝播はキャッシュの期限切れに過ぎません：レコードの TTL が経過すれば（通常 1 時間、24 時間を超えることはほとんどありません）、すべてのリゾルバーが新しい回答を見ることができます。24 時間後にまだ見つからない？伝播が原因ではありません。

2 つの本当の原因：ネガティブキャッシュ — レコードを追加する前にあなたを調べたリゾルバーが、ネガティブ TTL が期限切れになるまで「そのようなレコードはない」という回答をキャッシュしている — そしてマイグレーション後のネームサーバーの不一致 — ドメインが古いプロバイダーのネームサーバーを新しいものと並べてリストしており、世界の半分はもはや編集しないゾーンを読んでいる。各リストされたネームサーバーに直接クエリしてください；回答が異なる場合、原因が見つかりました。実際に編集しているプロバイダーのみが権威を持つように、レジストラの NS 委任を修正してください。

5. レコードが長すぎるか、CNAME によってブロックされているか？

TXT レコード内の 1 つの文字列は最大 255 文字です。長い SPF レコードは合法ですが、1 つのレコード内で複数のクォートされた文字列に分割する必要があります — DNS プロバイダーのインターフェースは定期的にこの分割を台無しにし、値を切り詰めたり、もはや解析されないようにメカニズムの途中で壊したりします。レコードが長い場合は、dig の出力で突然終わる値を確認してください。

別に、DNS は CNAME が既にある名前に TXT レコードを禁止しています。mail.yourdomain.com がプロバイダーへの CNAME であれば、そこに SPF を置くこともできません — 一部のパネルはそれを受け入れますが、CNAME のみを提供します。レコードを CNAME が指す場所に置くか（コントロールしている場合）、送信名前が CNAME されないように再構成してください。クリーンな TXT 処理を持つプロバイダーはどちらも簡単にします — Cloudflare の SPF セットアップガイドを参照してください。

ステップごとの修正方法

defaults.exposed の無料スキャンを実行する — ライブ DNS を読み取り、何かを変更する前に 5 つの状態のどれにいるかを教えてくれます。
どのネームサーバーが権威を持つか確認し（dig NS）、すべてが一致していることを確認します。
正確な Return-Path ドメインの権威ネームサーバーで TXT をクエリします。
v=spf1 の行を数える：ゼロ → 1 つ公開；2 つ以上 → 1 つにマージ。
タイプが TXT であること、値がちょうど v=spf1 で始まること、余分なクォートや切り詰めがないことを確認します。
TTL を 1 サイクル待ってから再スキャンし、どこでもきれいに解決されることを確認します。

よくある質問

DNS パネルでレコードを確認できるのに、なぜチェッカーは「見つからない」と言うのか？ 通常、原因 2 または 4 です：2 番目の v=spf1 レコードが両方を無効にします — 一部のツールが「見つからない」として報告する PermError であり、2026-06-29 時点で 1,013,416 件のドメインがこの状態にあります — またはパネルが実際に権威を持つ DNS ではありません。

修正が反映されるまでどのくらいかかるか？ TTL 1 サイクル — 通常 1 時間、最大 24 時間。それ以上かかる場合、「伝播」は説明になりません；ネームサーバーの一致から始めて 5 つの原因を再確認してください。

DNS パネルが提供する「SPF」レコードタイプを使うべきか？ いいえ。タイプ 99 は廃止されています；RFC 7208 は TXT のみを要求します。タイプ 99 のレコードは現代の受信者には見えません。

レコードが見つかるようになったのに、なぜメールが SPF を失敗するのか？ SPF は Return-Path ドメインに対して確認されるためであり、From ヘッダーに対してではなく、レコードは実際にあなたのために送信するサーバーをリストしている必要があります。見つかることはステップ 1 です；SPF レコードの修正ガイドはパスについて説明しています。

SPF レコードがないことは本当にそんなに一般的か？ はい — Defaults.Exposed センサスでグレードされた 261,086,232 件中 121,145,609 件のドメイン（46.4%）（2026-06-29 時点）が SPF を全く公開していません。見つからないのがインターネットのデフォルト状態です。

オーナーにレポートを送る

レコードがきれいに解決されたら、再スキャンを実行して、このドメインのビジネスオーナーまたはクライアントに採点済みレポートを転送してください。何が壊れていたか、何を修正したか、ドメインが現在どの状態にあるかを平易な言葉で示します — サイバー保険の更新やサプライヤーのセキュリティアンケートで求められる証拠そのものです。このレポートが作業の領収書になります。

SPF レコードを無料で確認する

5 つの「見つからない」状態のどれにいるかを、プライベートにオーナーのみで確認できます。

ドメインを確認 → · SPF を修正 → · プロバイダー切り替え後に SPF が動作しなくなった場合 → · グレード方法について → · 集計データのみ。データは EU で保存・処理されます。