SPF failの原因と解決法｜認証失敗の仕組みとケース別対策

Last Updated on 2025.11.28

メールログやバウンスメールを確認した際に「SPF fail」という表示を目にしたことはありませんか？これは、送信ドメイン認証の一つであるSPF認証に失敗した状態を示しています。

SPF failが発生すると、受信サーバーが「正規の送信元ではない」と判断し、正しいメールであっても拒否されたり、迷惑メールフォルダへ格納されたりする可能性があります。

本記事では、SPF failの原因や、放置した場合のリスク、そして解決方法をわかりやすく解説します。

SPF failを放置してはいけない理由

SPF failの状態では、メールが一時的に届くことはあっても、長期的に安定して配信される保証はありません。

この状態を放置すると、認証失敗が多いドメインとして受信サーバのフィルタリングシステムに学習され、最終的に信頼性の低い送信元ドメインと判断されます。

その結果、正規の送信元からのメールであっても迷惑メール判定や受信拒否のリスクが高まり、到達率やドメインレピュテーションの低下につながります。

外部へのメール送信が多い企業では、SPF failを放置することで、企業としての信頼低下やビジネス機会の損失を招くおそれがあります。放置による主な影響は次の通りです。

SPFスコアの低下

受信サーバーは Received-SPF の結果を、スパムスコアの計算に組み込みます。spf=fail が一定割合を超えると、ドメイン単位・IP単位でスコアが下がり、フィルタ閾値にかかりやすくなります。

フィードバックループでの負の学習

GmailやMicrosoft などでは、ユーザの「迷惑メール報告」と認証結果を突合し、スパム検知モデルに反映しています。SPF failが続くドメインは、この学習データ上で“信頼性が低い送信元”として扱われやすくなります。

ドメイン／IPレピュテーションの悪化

Google Postmaster Tools や Microsoft SNDS の評価にも影響し、ドメイン全体の配信レート制御（スロットリング）やバウンス率上昇を招く可能性があります。

DMARC整合性の欠落

SPF fail状態を放置すると、DMARC判定 (dmarc=fail) も同時に増加する可能性があります。これにより、DMARCポリシー quarantine／reject 適用時の誤隔離リスクが上昇します。

SPF認証結果と受信サーバーでの扱い方

SPF認証の結果は、送信元IPアドレスがSPFレコードと一致しているかどうかで判定されます。

受信サーバーは、この結果をもとに、メールを受信するか拒否するか、あるいは迷惑メールとして扱うかを判断します。一方で、送信側では、SPFレコードの all の前に付ける限定子によって、認証に失敗したメールをどのように扱ってほしいか示します。

ただし、最終的にメールをどう処理するかは受信サーバー側のポリシーによって決定されます。以下に、代表的な認証結果と受信サーバーの動作をまとめます。

認証結果	意味	限定子	受信サーバーでの扱い	補足
Pass	認証成功（送信元IPが一致）	—	正常に受信	SPF認証を通過
HardFail	厳格な不一致判定	`-`	拒否または迷惑メール扱い	厳格な運用ポリシー向け
SoftFail	弱い不一致判定	`~`	多くは迷惑メール扱い	検証・移行段階で利用される
Neutral	判定放棄（中立）	`?`	受信側ポリシーに依存	SPFの効果は限定的
None	SPFレコードが存在しない	—	fail扱いまたは独自判定	設定漏れによる発生が多い
PermError	SPFレコードの構文エラーや設定不備	—	fail扱い、拒否の可能性大	構文・参照回数・長さ制限に注意
TempError	一時的なDNS障害など	—	一時fail、再試行で成功することも	―

HardFail

HardFailは、SPFレコードに送信元IPが含まれておらず、かつ「-all」で厳格に指定されている場合に出る結果です。多くの受信サーバーはこの場合、メールを拒否するか、即座に迷惑メールフォルダへ振り分けます。

SoftFail

SoftFailは、SPFレコードに不一致があるものの「~all」によって弱い指示がされている場合に出る結果です。受信されますが、多くの場合は迷惑メール扱いとなり、到達率に悪影響を及ぼします。

Neutral

Neutralは、SPFレコードに「?all」が指定されている場合に出る結果です。正規・不正のどちらとも判定せず、中立的な扱いになります。認証の効果はほとんどなく、受信サーバーは他の要素（限定子、DMARCポリシー、転送時の判定など）を基に判断します。

None

Noneは、送信元ドメインにSPFレコードが存在しない場合に返される結果です。限定子の有無とは関係なく発生する結果で、受信サーバーはSPF認証を実施できず、不審なメールとして扱われやすくなります。

PermError

SPFレコードに構文エラーや設定ミスがある場合に返される結果で、限定子とは関係ありません。具体例としては以下が挙げられます。

SPFレコードの構文が正しくない
同一ドメインに複数のSPFレコードが存在する
SPFルックアップ10回制限の超過
SPFレコードの長さ制限（255文字）を超える
SPFレコードが古く、ESP側の送信情報変更に追随できていない

TempError

TempErrorは、一時的なエラーが発生した場合に返される結果です。こちらも限定子とは関係なく、多くはDNSサーバーのタイムアウトなどが原因のため、再試行すると認証に成功するケースもあります。

SPF 認証が失敗する5つの原因

SPF failが発生する理由はいくつかありますが、認証結果を確認すれば原因を特定できます。以下では、代表的な失敗パターンを5つに整理し、それぞれの見分け方を併せて紹介します。

認証結果	主な原因
HardFail / SoftFail / Neutral	原因1：IPアドレス未登録原因2：転送によるIP変更
None	原因3：SPFレコードが存在しない
PermError	原因4：記述ミス原因5：参照回数の上限超過

原因1： IPアドレス未登録

認証結果：HardFail / SoftFail / Neutral

メール送信に使用したサーバーのIPアドレスがSPFレコードに登録されていないと、認証に失敗します。

例えば、新しいメール配信サービスを導入した際に、IPアドレスを追加し忘れてしまうと、そこから送ったメールがSPF failになってしまいます。他にも、メールサーバーの増設・移行でも登録漏れが起こりがちなので注意しましょう。

原因2：転送によるIP変更

認証結果：HardFail / SoftFail / Neutral

メールを自動転送している場合も認証に失敗しやすくなります。転送時、送信元IPアドレスは送信サーバーのIPから転送サーバーのIPへと変わります。

しかし、ヘッダーFromのドメインは変わらないため、受信サーバーは転送サーバーのIPをSPFレコードと照合した際に一致しないと判定し、認証失敗となります。

原因3：SPFレコードが存在しない

認証結果：None

送信ドメインにSPFレコードそのものが設定されていない場合、受信サーバーはSPF認証を実行できず、認証に失敗してしまいます。結果として、迷惑メールフォルダ行きや拒否のリスクが高まります。

特に以下のようなケースで起こります。

新規に取得したドメインにまだSPFレコードを設定していない
サブドメインを送信元に使っているが、SPFレコードを用意していない
過去に設定を削除してしまい、レコードが消えている

原因4：記述ミス

認証結果：PermError

SPFレコードには記述ルールと仕様上の制約があり、それに反していると認証エラーとなります。代表的なケースは以下の通りです。

ip4:の付け忘れ
不要な記号やスペースの混入
レコードの1行が255文字を超過している
1つのドメインに複数のSPFレコードを定義している
includeの誤用（存在しないドメイン指定、循環参照など）

原因5：参照回数の上限超過

認証結果：PermError

SPFレコードの仕様上、DNS参照回数は最大10回までと定められています。a、mx、include といったメカニズムを利用すると、そのたびにDNS参照が発生します。

外部サービスを利用する場合、多くはサービスが提供する設定例に従って include: を追加します。このとき、サービスごとに参照が積み重なるだけでなく、include: の内部でさらに別の参照が呼び出されることもあります。

そのため、利用するサービスが増えるほど参照回数が膨らみやすく、上限を超えると11回目以降の参照はエラーとなり、SPF認証が失敗してしまいます。

DNSルックアップの詳細については以下のブログを参考にしてください。

SPFのDNSルックアップの回数制限とは？確認方法や対策を解説｜ベアメールブログ

SPF failを解決する方法

ここまで見てきたSPF failの原因に対する、具体的な対処法を解説します。
以下の対応表を参考に、自社の状況に合った方法を確認してください。

SPF failの原因	対応する解決法
原因1：IPアドレス未登録	解決法1：送信元サーバーのIPやドメインをSPFに登録する
原因2：転送によるIP変更	解決法2：DKIM・DMARCを設定する
原因3：SPFレコードが存在しない	解決法3：SPFレコードを新規で設定する
原因4：記述ミス	解決法4：SPFレコードを修正する
原因5：参照回数の上限超過	解決法5：参照回数を10回以下に抑える

解決法1：送信元サーバーのIPやドメインをSPFに登録する

新しいメール配信サービスの導入や社内サーバーを増設・移行した際に、送信元IPをSPFレコードに登録し忘れるとSPF failが発生します。この場合は、漏れているIPアドレスやドメインをSPFレコードに追加することで解決できます。

例：v=spf1 ip4:203.0.113.10 include:spf.example.com -all

このように、SPFレコードに利用している送信元を正しく設定すれば、SPF failを防ぐことができます。特に新規サービス導入やサーバー移行のタイミングで更新漏れが起きやすいため、必ず確認することが重要です。

解決法2：DKIM・DMARCを設定する

SPFは、転送などで送信元IPが変わるとfailになりやすいという弱点があります。DKIMやDMARCを併用することで、この弱点を補い正規のメールが拒否されにくい環境を整えられます。

DKIM：メールに電子署名を付けるため、IPが変わってもメールの正当性を証明できる
DMARC：SPFやDKIMの結果を総合的に判断し、受信側に「このメールは正当である」と示せる

これらを組み合わせれば、SPF failが発生しても正当な送信者としての信用を維持でき、不要な拒否や隔離を防ぐ助けになります。

DKIMとDMARCの詳細については以下のブログを参考にしてください。

DKIMとは？仕組みから導入方法までわかる入門ガイド｜ベアメールブログ

解決法3： SPFレコードを新規で設定する

送信ドメインにSPFレコードが存在しない場合、受信サーバーは認証を実行できず「None」と判定されます。この場合は、利用しているメールサーバーや配信サービスを正しく記載したSPFレコードを、対象ドメインのDNSに追加することで解決できます。

例：v=spf1 ip4:203.0.113.10 include:spf.example.com -all

新規に取得したドメインや外部のメールサービスを利用しているドメインで設定が漏れやすいため、注意が必要です。

解決法4：SPFレコードを修正する

SPF failは、レコードの書き方に誤りがある場合や、複数のSPFレコードを設定している場合にも発生します。以下のような修正を行うことで、SPFfailが解消されるようになります。

構文エラーの修正：不要なスペースや誤記を直す
レコード統一：1つのドメインには1つのSPFレコードのみを残す
DNS参照回数の調整：includeを多用すると10回の制限を超えることがあるため、不要なものを削除する

SPFレコードの書き方についての詳細は以下の記事をご参照ください。

SPFレコードとは？書き方・設定手順・確認方法まで完全ガイド｜ベアメール

解決法5：参照回数を10回以下に抑える

SPFではDNSの参照回数が10回までに制限されているため、この上限を超えないように設計する必要があります。具体的な方法は次の3つです。

最適化する

不要な参照を削除したり、効率的なメカニズムを選んだりすることで、多くの場合ルックアップ数の超過を解消できます。代表的な最適化の方法は以下の通りです。

ip4 や ip6 を使って直接IPアドレスを記載する
重複している参照先を削除する
サブドメインを分けて負荷を分散する

フラット化する

フラット化とは、include や a、mx などの参照をすべて解決し、IPアドレスだけで構成されたシンプルなSPFレコードに置き換える手法です。参照回数を10回以下に削減できますが、以下のような課題もあります。

TXTレコードの文字数制限（255文字や全体512文字制限）に当たりやすい
更新時にIPアドレスを都度書き換える必要があり、運用コストが増える
レコードが長くなり、可読性や保守性が低下する

SPFホスティングを利用する

最適化やフラット化だけでは参照回数を十分に減らせない場合は、SPFホスティングサービスを利用するのも有効です。SPFホスティングサービスでは、提供元が include を展開して常に最新のIPリストを自動生成します。管理者はそのサービスが提供する1行の include を書き込むだけで、参照回数を抑えつつIP更新にも自動で追随できます。

これにより、フラット化の弱点である手動更新の手間を解消し、安定したSPF運用を続けやすくなります。フラット化で限界を感じた場合は、より自動化された方法であるSPFホスティングを検討しましょう。

ベアメールの SPFホスティングは、既存のSPFレコードをインポートするだけで設定でき、DNS参照回数超過や文字数制限を自動的に解消します。主な特長は次のとおりです。

自動更新機能：送信元のIPやホスト名の変更を自動検知し、最新状態を維持
Web管理画面：SPF設定を一元管理し、DNS編集を不要化
通知機能：設定エラーや異常を自動検知し、管理者にアラート送信

これにより、レコードの短縮化・更新漏れ防止・認証結果の安定化を同時に実現。複数のメール配信サービスを利用する環境でも、DNS更新作業をほぼゼロにできます。

詳細については、紹介資料をご確認ください。

ベアメール SPFホスティング機能紹介資料

まとめ

SPF failは、IP未登録・記述ミス・転送・参照回数超過など、いくつかの典型的な原因により発生します。本記事で紹介した解決策を実行すれば、多くのケースで「メールが届かない」問題を改善できます。

一方、SPFだけでは対応しきれないケースもあるため、DKIMやDMARCを併せて導入することで、転送などの場面でも正規メールが正しく扱われやすくなります。

SPFエラーの原因を特定し、適切に対処することが、安定したメール配信の第一歩です。