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

最終更新日：2026.05.25

SPFは送信ドメイン認証の一つで、メールの送信元IPアドレスが許可された送信元かどうかを検証する技術です。メールの信頼性を担保するために重要な仕組みですが、「正しく設定したはずなのに認証に失敗する」といったケースに直面することも少なくありません。

SPF failが発生すると、受信サーバーから信頼性の低いメールだと判断され、正規のメールであっても拒否されたり、迷惑メールフォルダへ振り分けられたりする可能性があります。さらに、SPF failはDMARC認証の結果にも影響するため、放置せず適切に対処することが重要です。

本記事では、SPFの基本的な仕組みから、認証結果の見方、SPF failの主な原因、放置した場合のリスク、対処法までわかりやすく解説します。

SPFとは

SPFは「Sender Policy Framework」の略称で、電子メールにおける送信ドメイン認証技術の一つです。メールの送信元IPアドレスがドメイン所有者によって許可されているかを確認することで、送信元の正当性を検証します。

SPFの概要や設定方法については、以下の記事で詳しく解説しています。
SPFレコードとは？書き方・設定手順・確認方法まで完全ガイド｜ベアメールブログ

SPFの仕組み

SPFでは、以下のような流れで認証が行われます。

送信側：そのドメインを送信元としてメールを送信するサーバーのIPアドレスの情報を、SPFレコードとしてDNSに登録する
送信側：メールを送信する
受信側：メールを受信すると、送信元ドメイン（エンベロープFromドメイン）のDNSサーバーにSPFレコードを問い合わせる
受信側：受信したメールの送信元サーバーのIPアドレスと、SPFレコードに記載されたIPアドレスを照合する
受信側：照合結果にもとづいて、送信元IPアドレスの正当性を判定する
- 一致する場合：SPF認証成功（Pass）
- 一致しない場合：SPF認証失敗（Fail、Softfailなど）

SPF failを放置するとどうなる？

SPF failを放置すると、正規のメールであっても迷惑メールとして判定されたり、受信拒否されたりするリスクが高まります。さらに、認証失敗が続くと、送信元ドメインやIPアドレスの信頼性が低下するおそれがあります。

メール到達率の低下やビジネス機会の損失につながる可能性もあるため、放置せず適切な対応を取ることが重要です。

迷惑メール判定されやすくなる

SPF failが発生すると、受信サーバーから信頼性の低いメールとして扱われやすくなります。受信側では、SPFの認証結果を迷惑メール判定の材料の一つとして利用しているため、SPF failが継続すると、正規のメールであっても迷惑メールフォルダへ振り分けられたり、受信拒否されたりする可能性があります。

ドメイン／IPレピュテーションが悪化する

GmailやMicrosoftなどのメールサービスでは、認証結果やユーザからの迷惑メール報告などをもとに送信元の評価を行っています。SPF failが継続すると、送信元ドメインやIPアドレスの信頼性（レピュテーション）が低下する可能性があります。

レピュテーションが低下すると、メールの到達率低下や、ドメイン全体への配信レート制限（スロットリング）、バウンス率の上昇などにつながるおそれがあります。

レピュテーションについては、以下の記事で詳しく解説しています。
IPレピュテーションとドメインレピュテーションとは？レピュテーション向上のポイントを解説｜ベアメールブログ

DMARC認証に失敗する可能性が高まる

DMARCは、SPFやDKIMの認証結果をもとに判定を行う仕組みです。DKIM認証がpassしていない場合や、DKIMアライメント（ヘッダFromとDKIM署名ドメインの整合性）を満たしていない場合には、SPF failによってDMARCもfailとなります。

その結果、DMARCポリシーをquarantineやrejectに設定している環境では、正規のメールであっても隔離や受信拒否の対象となることがあります。

DMARCについては、以下の記事で詳しく解説しています。
DMARCとは？仕組み・導入メリット・設定方法・注意点を基礎から解説｜ベアメールブログ

SPF認証結果の見方と意味

これらのリスクを軽減するためには、SPF認証結果を確認し、認証失敗の原因を把握することが重要です。本章では、メールヘッダでの認証結果の見方や、各認証結果の意味について解説します。

認証結果の確認方法

SPFの認証結果は、メールヘッダで確認できます。

例えばGmailでは、メールを開いて右上のメニューから「メッセージのソースを表示」をクリックすると、「PASS」「FAIL」などの認証結果の概要が表示されます。

より詳細な情報を確認したい場合は、メールヘッダ内の「Authentication-Results」を確認します。「spf=******」となっている箇所を見ると、SPF認証の結果や、認証対象となったドメイン、送信元IPアドレスがわかります。ブラウザの機能で「spf」と検索すると、該当箇所を見つけやすくなります。

メールヘッダの画面キャプチャ。「Authentication-Results」を確認すると、SPF認証の結果や認証対象のドメイン、送信元IPアドレスがわかる

メールヘッダの内容や確認方法については、以下の記事で詳しく解説しています。
メールヘッダの解析方法とは？各項目の見方とツール活用法を徹底解説｜ベアメールブログ

認証結果の種類と受信サーバーでの扱い

SPF認証では、送信元IPアドレスがSPFレコードに登録された送信元と一致しているかどうかを確認し、その判定結果として「Pass」「Fail」などが返されます。

送信側は、SPFレコードの all の前に付ける限定子によって、認証に失敗したメールをどのように扱ってほしいかを示します。ただし、実際にメールを受信するか、迷惑メールとして扱うか、拒否するかは、受信サーバー側のポリシーによって決定されます。

以下に、代表的なSPF認証結果とその意味をまとめます。

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

Pass

Passは、送信元IPアドレスがSPFレコードに登録された送信元と一致する場合に返される結果です。SPF認証に成功している状態を示します。

HardFail

HardFaillは、SPFレコードに送信元IPアドレスが含まれておらず、かつ「-all」により厳格な扱いが指定されている場合に返される結果です。多くの場合、メールは拒否されるか、迷惑メールフォルダへ振り分けられます。

SoftFail

SoftFailは、SPFレコードに不一致があるものの、「~all」によって緩やかな扱いが指定されている場合に返される結果です。メール自体は受信されることが多いですが、迷惑メールとして扱われる可能性があります。

Neutral

Neutralは、SPFレコードに「?all」が指定されている場合に返される結果です。これは、送信元IPアドレスが正規の送信元であるとも、不正な送信元であるとも判断しないことを意味します。そのため、SPF認証によってメールの信頼性を積極的に高める効果はほとんどありません。

受信サーバーは、DKIMやDMARCの認証結果、送信元ドメインやIPアドレスのレピュテーション、メール本文の内容などを総合的に判断し、メールを受信するか、拒否するか、迷惑メールとして扱うかを決定します。

None

Noneは、送信元ドメインにSPFレコードが存在しない場合に返される結果です。限定子の有無とは関係なく発生する結果で、受信サーバーはSPF認証を実施できません。そのため、メールの信頼性はDKIMやDMARCの認証結果や、受信ポリシーなどをもとに判断されます。

PermError

PermErrorは、SPFレコードに構文エラーや設定ミスがある場合に返される結果で、限定子とは関係ありません。受信サーバーによっては、fail扱いや拒否の対象となる可能性があります。

具体例としては、以下が挙げられます。

SPFレコードの構文が正しくない
同一ドメインに複数のSPFレコードが存在する
SPFルックアップ10回制限を超えている
SPFレコードが長すぎる

TempError

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

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

SPF failは、SPFレコードの設定不備や送信環境の変更など、様々な要因で発生します。本章では、代表的な5つの原因を紹介します。

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

原因1：IPアドレスがSPFに登録されていない

認証結果：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レコードを設定していない
過去に設定を削除してしまい、SPFレコードが消えている

原因4：SPFレコードの構文ミス

認証結果：PermError

SPFレコードは決められた書式に従って記述する必要があり、構文に誤りがあると認証エラーとなります。

以下は、よくあるミスです。

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

原因5：DNS参照回数の上限を超えている

認証結果：PermError

a、mx、include といったメカニズムを利用すると、そのたびにDNS参照が発生します。SPFでは、DNS参照回数は最大10回までと定められているため、これを超えると認証に失敗します。

特に外部サービスをincludeで追加している場合、その内部でさらに別の参照が呼び出されて、気づかないうちに上限を超えてしまうケースがあるため、注意が必要です。

DNS参照回数の制限については、以下の記事で詳しく解説しています。
SPFのDNSルックアップの回数制限とは？確認方法や対策を解説｜ベアメールブログ

お役立ち資料のダウンロードページへ移動（『SPFルックアップエラーとは』：SPFルックアップエラーの原因、確認・改善方法を解説）

SPF認証に失敗したときの対処法

ここまで解説したSPF failの原因に対する、具体的な対処法を紹介します。

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

解決法1：IPアドレスをSPFレコードに登録する

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

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

SPFレコードを更新した後は、テストメールを送信して、SPF認証がpassになっているか確認しましょう。

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

SPFは、転送によって送信元IPアドレスが変わるとfailになりやすいという弱点があります。DKIMやDMARCを併用することで、この弱点を補い、メールが正規のものとして扱われやすくなります。

DKIMは、メールに電子署名を付与することで、メールが改ざんされていないかを検証する仕組みです。転送によってIPアドレスが変わっても、DKIM署名が送信ドメインで付与され、転送後も保持されていればpassします。

DMARCは、SPFやDKIMの認証結果をもとに、なりすましメールではないかを検証する仕組みです。SPFまたはDKIMのいずれかでpassし、かつアライメントを満たしていれば、DMARCもpassとなります。

そのため、DKIM・DMARCを併用することで、SPF failが発生した場合でも正当な送信元としての信頼性を維持し、不要な拒否や隔離を防ぐ助けになります。

DKIMとDMARCについては、以下の記事で詳しく解説しています。
DKIMとは？仕組みから導入方法までわかる入門ガイド｜ベアメールブログ
 DMARCとは？仕組み・導入メリット・設定方法・注意点を基礎から解説｜ベアメールブログ

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

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

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

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

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

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

構文エラーの修正：不要なスペースや誤記を直す
レコード統一：1つのドメインには1つのSPFレコードのみを設定する

レコードを修正したら、オンラインツールを利用して、正しい構文になっているか確認すると良いでしょう。MXToolBoxの「SPF Record Check」（https://mxtoolbox.com/spf.aspx）などでチェックできます。

SPFレコードの書き方については、以下の記事で詳しく解説しています。
SPFレコードとは？書き方・設定手順・確認方法まで完全ガイド｜ベアメール

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

SPFレコードでは、DNS参照回数は最大10回までと定められているため、上限を超えないように設計する必要があります。

DNS参照回数の制限超過を解消する方法を3つ紹介します。

最適化する

SPFレコードの構成を見直すことで、DNS参照回数の超過を解消できる可能性があります。

代表的な最適化方法は以下の通りです。

重複している参照先を削除する
用途ごとにサブドメインを分け、SPFレコードを分散する

フラット化する

フラット化とは、include や a、mx などの参照を展開し、IPアドレスを直接記述したSPFレコードに置き換える手法です。DNS参照回数を削減できるため、SPFルックアップ10回制限への対策として利用されます。

一方で、以下のような課題もあります。

TXTレコードの文字数制限（255文字や全体512文字制限）を超過しやすい
IPアドレス変更時に都度レコードを書き換える必要があり、運用負荷が増大する
レコードが長くなり、可読性が低下する

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

最適化やフラット化だけでは参照回数を十分に減らせない場合は、SPFホスティングサービスを利用するのも有効です。

SPFホスティングサービスでは、提供元が include を展開し、常に最新のIPリストを自動生成します。管理者は、サービスから提供される1行の include をSPFレコードに追加するだけで、参照回数を抑えながら、IPアドレス更新にも自動で追随できます。

これにより、フラット化の弱点である手動更新の手間を軽減し、安定したSPF運用を行いやすくなります。

ベアメールの「迷惑メールスコアリング」では、オプションとしてSPFホスティング機能を提供しています。既存のSPFレコードをインポートするだけで設定でき、DNS参照回数超過や文字数制限を自動で解消できます。

主な特長は以下の通りです。

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

これにより、レコードの短縮化や更新漏れ防止を実現し、複数のメール配信サービスを利用する環境でも、DNS更新作業の負担を大幅に軽減できます。

「SPFホスティング機能」の詳細については、以下の資料をご確認ください。

SPF認証結果や迷惑メール判定リスクをまとめて確認するには

ベアメールの「迷惑メールスコアリング」では、テストメールを送信するだけで、SPFをはじめDKIM・DMARCの認証結果を確認できます。

さらに、送信元IPアドレスの評価、ブラックリストの登録状況、メール本文の内容、キャリアごとの到達度なども総合的に分析し、迷惑メールと判定されるリスクを可視化することが可能です。

メールの認証状況や配信環境の状態をひと目で確認できるため、認証エラーの原因特定や改善ポイントの把握に役立ちます。

「SPF認証がエラーになる原因を知りたい」「メールの配信状況を確認したい」といった場合は、ぜひお気軽にご相談ください。

まとめ

SPF failは、送信元IPアドレスの未登録、SPFレコードの記述ミス、転送による送信元IPアドレスの変更、DNS参照回数の超過など、いくつかの典型的な原因によって発生します。原因を正しく把握し、適切に対処することが重要です。

ただし、転送による認証失敗など、SPFだけでは対応しきれないケースもあります。DKIMやDMARCを併せて導入することで、正規のメールが隔離されたり、受信拒否されたりするリスクを軽減することができます。

SPF failが発生した場合は、本記事で紹介した内容を参考に、設定や配信環境を見直してみてください。