SPFは送信ドメイン認証の一つで、メールの送信元IPアドレスが許可された送信元かどうかを検証する技術です。メールの信頼性を担保するために重要な仕組みですが、「正しく設定したはずなのに認証に失敗する」といったケースに直面することも少なくありません。
SPF failが発生すると、受信サーバーから信頼性の低いメールだと判断され、正規のメールであっても拒否されたり、迷惑メールフォルダへ振り分けられたりする可能性があります。さらに、SPF failはDMARC認証の結果にも影響するため、放置せず適切に対処することが重要です。
本記事では、SPFの基本的な仕組みから、認証結果の見方、SPF failの主な原因、放置した場合のリスク、対処法までわかりやすく解説します。
目次
SPFは「Sender Policy Framework」の略称で、電子メールにおける送信ドメイン認証技術の一つです。メールの送信元IPアドレスがドメイン所有者によって許可されているかを確認することで、送信元の正当性を検証します。
SPFの概要や設定方法については、以下の記事で詳しく解説しています。
SPFレコードとは？ 書き方・設定手順・確認方法まで完全ガイド｜ベアメールブログ
SPFでは、以下のような流れで認証が行われます。
SPF failを放置すると、正規のメールであっても迷惑メールとして判定されたり、受信拒否されたりするリスクが高まります。さらに、認証失敗が続くと、送信元ドメインやIPアドレスの信頼性が低下するおそれがあります。
メール到達率の低下やビジネス機会の損失につながる可能性もあるため、放置せず適切な対応を取ることが重要です。
SPF failが発生すると、受信サーバーから信頼性の低いメールとして扱われやすくなります。受信側では、SPFの認証結果を迷惑メール判定の材料の一つとして利用しているため、SPF failが継続すると、正規のメールであっても迷惑メールフォルダへ振り分けられたり、受信拒否されたりする可能性があります。
GmailやMicrosoftなどのメールサービスでは、認証結果やユーザからの迷惑メール報告などをもとに送信元の評価を行っています。SPF failが継続すると、送信元ドメインやIPアドレスの信頼性（レピュテーション）が低下する可能性があります。
レピュテーションが低下すると、メールの到達率低下や、ドメイン全体への配信レート制限（スロットリング）、バウンス率の上昇などにつながるおそれがあります。
レピュテーションについては、以下の記事で詳しく解説しています。
IPレピュテーションとドメインレピュテーションとは？ レピュテーション向上のポイントを解説｜ベアメールブログ
DMARCは、SPFやDKIMの認証結果をもとに判定を行う仕組みです。DKIM認証がpassしていない場合や、DKIMアライメント（ヘッダFromとDKIM署名ドメインの整合性）を満たしていない場合には、SPF failによってDMARCもfailとなります。
その結果、DMARCポリシーをquarantineやrejectに設定している環境では、正規のメールであっても隔離や受信拒否の対象となることがあります。
DMARCについては、以下の記事で詳しく解説しています。
DMARCとは？ 仕組み・導入メリット・設定方法・注意点を基礎から解説｜ベアメールブログ
これらのリスクを軽減するためには、SPF認証結果を確認し、認証失敗の原因を把握することが重要です。本章では、メールヘッダでの認証結果の見方や、各認証結果の意味について解説します。
SPFの認証結果は、メールヘッダで確認できます。
例えばGmailでは、メールを開いて右上のメニューから「メッセージのソースを表示」をクリックすると、「PASS」「FAIL」などの認証結果の概要が表示されます。
より詳細な情報を確認したい場合は、メールヘッダ内の「Authentication-Results」を確認します。「spf=******」となっている箇所を見ると、SPF認証の結果や、認証対象となったドメイン、送信元IPアドレスがわかります。ブラウザの機能で「spf」と検索すると、該当箇所を見つけやすくなります。
メールヘッダの内容や確認方法については、以下の記事で詳しく解説しています。
メールヘッダの解析方法とは？ 各項目の見方とツール活用法を徹底解説｜ベアメールブログ
SPF認証では、送信元IPアドレスがSPFレコードに登録された送信元と一致しているかどうかを確認し、その判定結果として「Pass」「Fail」などが返されます。
送信側は、SPFレコードの all の前に付ける限定子によって、認証に失敗したメールをどのように扱ってほしいかを示します。ただし、実際にメールを受信するか、迷惑メールとして扱うか、拒否するかは、受信サーバー側のポリシーによって決定されます。
以下に、代表的なSPF認証結果とその意味をまとめます。
| 認証結果 | 意味 | 限定子 | 受信サーバーでの扱い | 補足 |
|---|---|---|---|---|
| Pass | 認証成功 （送信元IPが一致） | — | 正常に受信 | SPF認証を通過 |
| HardFail | 厳格な不一致判定 | – | 拒否または迷惑メール扱い | 厳格な運用ポリシー向け |
| SoftFail | 弱い不一致判定 | ~ | 迷惑メールとして扱われる可能性がある | 検証・移行段階で利用される |
| Neutral | 判定放棄 （中立） | ? | 受信側ポリシーに依存 | SPFの効果は限定的 |
| None | SPFレコードが存在しない | — | 受信側ポリシーに依存 | SPFが未設定の状態 |
| PermError | SPFレコードの構文エラーや設定不備 | — | fail扱いや拒否の可能性がある | 構文・参照回数・長さ制限に注意 |
| TempError | 一時的なDNS障害など | — | 一時的な認証エラー | 再試行で成功する場合がある |
Passは、送信元IPアドレスがSPFレコードに登録された送信元と一致する場合に返される結果です。SPF認証に成功している状態を示します。
HardFaillは、SPFレコードに送信元IPアドレスが含まれておらず、かつ「-all」により厳格な扱いが指定されている場合に返される結果です。多くの場合、メールは拒否されるか、迷惑メールフォルダへ振り分けられます。
SoftFailは、SPFレコードに不一致があるものの、「~all」によって緩やかな扱いが指定されている場合に返される結果です。メール自体は受信されることが多いですが、迷惑メールとして扱われる可能性があります。
Neutralは、SPFレコードに「?all」が指定されている場合に返される結果です。これは、送信元IPアドレスが正規の送信元であるとも、不正な送信元であるとも判断しないことを意味します。そのため、SPF認証によってメールの信頼性を積極的に高める効果はほとんどありません。
受信サーバーは、DKIMやDMARCの認証結果、送信元ドメインやIPアドレスのレピュテーション、メール本文の内容などを総合的に判断し、メールを受信するか、拒否するか、迷惑メールとして扱うかを決定します。
Noneは、送信元ドメインにSPFレコードが存在しない場合に返される結果です。限定子の有無とは関係なく発生する結果で、受信サーバーはSPF認証を実施できません。そのため、メールの信頼性はDKIMやDMARCの認証結果や、受信ポリシーなどをもとに判断されます。
PermErrorは、SPFレコードに構文エラーや設定ミスがある場合に返される結果で、限定子とは関係ありません。受信サーバーによっては、fail扱いや拒否の対象となる可能性があります。
具体例としては、以下が挙げられます。
TempErrorは、一時的なエラーが発生した場合に返される結果です。こちらも限定子とは関係なく、多くはDNSサーバーのタイムアウトや一時的な名前解決エラーなどが原因で発生します。時間をおいて再試行することで、認証に成功するケースもあります。
SPF failは、SPFレコードの設定不備や送信環境の変更など、様々な要因で発生します。本章では、代表的な5つの原因を紹介します。
| 認証結果 | 主な原因 |
|---|---|
| HardFail / SoftFail / Neutral | 原因1：IPアドレス未登録 原因2：転送によるIPアドレス変更 |
| None | 原因3：SPFレコードが存在しない |
| PermError | 原因4：SPFレコードの記述ミス 原因5：DNS参照回数の上限超過 |
認証結果：HardFail / SoftFail / Neutral
メール送信に使用するサーバーのIPアドレスがSPFレコードに登録されていないと、認証に失敗します。
例えば、新しいメール配信サービスを導入した際に、IPアドレスを追加し忘れてしまうと、そこから送ったメールがSPF failになります。その他、メールサーバーの増設・移行でも登録漏れが起こりやすいため注意しましょう。
認証結果：HardFail / SoftFail / Neutral
転送によって、送信元IPアドレスが送信サーバーのIPから転送サーバーのIPに変更された場合も、認証に失敗しやすくなります。
メールが転送されてもヘッダFromのドメインは変わらず、受信サーバー側で送信元IPとSPFレコードの照合を行う際に一致しなくなるためです。
認証結果：None
送信元ドメインにSPFレコードが設定されていない場合、受信サーバーはSPF認証を実施できません。
特に以下のようなケースで発生します。
認証結果：PermError
SPFレコードは決められた書式に従って記述する必要があり、構文に誤りがあると認証エラーとなります。
以下は、よくあるミスです。
認証結果：PermError
a、mx、include といったメカニズムを利用すると、そのたびにDNS参照が発生します。SPFでは、DNS参照回数は最大10回までと定められているため、これを超えると認証に失敗します。
特に外部サービスをincludeで追加している場合、その内部でさらに別の参照が呼び出されて、気づかないうちに上限を超えてしまうケースがあるため、注意が必要です。
DNS参照回数の制限については、以下の記事で詳しく解説しています。
SPFのDNSルックアップの回数制限とは？ 確認方法や対策を解説｜ベアメール ブログ
ここまで解説した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回以下に抑える |
新しいメール配信サービスを導入した際や、社内サーバーを増設・移行した際に、SPFレコードの更新が漏れるとSPF failが発生します。この場合は、漏れている送信元IPアドレスをSPFレコードに追加することで解決できます。
例：v=spf1 ip4:203.0.113.10 include:spf.example.com -allSPFレコードを更新した後は、テストメールを送信して、SPF認証がpassになっているか確認しましょう。
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とは？ 仕組み・導入メリット・設定方法・注意点を基礎から解説｜ベアメールブログ
送信ドメインにSPFレコードが存在しない場合、受信サーバーは認証を行えず、「None」と判定されます。この場合は、利用しているメールサーバーや配信サービスの送信元情報を記載したSPFレコードを、対象ドメインのDNSに追加することで解決できます。
例：v=spf1 ip4:203.0.113.10 include:spf.example.com -all
新規に取得したドメインや、外部のメールサービスを利用しているドメインで設定が漏れやすいため、注意が必要です。
SPF failは、レコードの書き方に誤りがある場合や、1つのドメインに対して複数のSPFレコードを設定している場合にも発生します。以下のような修正を行うことで、SPF failを解消できます。
レコードを修正したら、オンラインツールを利用して、正しい構文になっているか確認すると良いでしょう。MXToolBoxの「SPF Record Check」（https://mxtoolbox.com/spf.aspx）などでチェックできます。
SPFレコードの書き方については、以下の記事で詳しく解説しています。
SPFレコードとは？ 書き方・設定手順・確認方法まで完全ガイド｜ベアメール
SPFレコードでは、DNS参照回数は最大10回までと定められているため、上限を超えないように設計する必要があります。
DNS参照回数の制限超過を解消する方法を3つ紹介します。
SPFレコードの構成を見直すことで、DNS参照回数の超過を解消できる可能性があります。
代表的な最適化方法は以下の通りです。
フラット化とは、include や a、mx などの参照を展開し、IPアドレスを直接記述したSPFレコードに置き換える手法です。DNS参照回数を削減できるため、SPFルックアップ10回制限への対策として利用されます。
一方で、以下のような課題もあります。
最適化やフラット化だけでは参照回数を十分に減らせない場合は、SPFホスティングサービスを利用するのも有効です。
SPFホスティングサービスでは、提供元が include を展開し、常に最新のIPリストを自動生成します。管理者は、サービスから提供される1行の include をSPFレコードに追加するだけで、参照回数を抑えながら、IPアドレス更新にも自動で追随できます。
これにより、フラット化の弱点である手動更新の手間を軽減し、安定したSPF運用を行いやすくなります。
ベアメールの 「迷惑メールスコアリング」では、オプションとしてSPFホスティング機能を提供しています。既存のSPFレコードをインポートするだけで設定でき、DNS参照回数超過や文字数制限を自動で解消できます。
主な特長は以下の通りです。
これにより、レコードの短縮化や更新漏れ防止を実現し、複数のメール配信サービスを利用する環境でも、DNS更新作業の負担を大幅に軽減できます。
「SPFホスティング機能」の詳細については、以下の資料をご確認ください。
ベアメールの「迷惑メールスコアリング」では、テストメールを送信するだけで、SPFをはじめDKIM・DMARCの認証結果を確認できます。
さらに、送信元IPアドレスの評価、ブラックリストの登録状況、メール本文の内容、キャリアごとの到達度なども総合的に分析し、迷惑メールと判定されるリスクを可視化することが可能です。
メールの認証状況や配信環境の状態をひと目で確認できるため、認証エラーの原因特定や改善ポイントの把握に役立ちます。
「SPF認証がエラーになる原因を知りたい」「メールの配信状況を確認したい」といった場合は、ぜひお気軽にご相談ください。
SPF failは、送信元IPアドレスの未登録、SPFレコードの記述ミス、転送による送信元IPアドレスの変更、DNS参照回数の超過など、いくつかの典型的な原因によって発生します。原因を正しく把握し、適切に対処することが重要です。
ただし、転送による認証失敗など、SPFだけでは対応しきれないケースもあります。DKIMやDMARCを併せて導入することで、正規のメールが隔離されたり、受信拒否されたりするリスクを軽減することができます。
SPF failが発生した場合は、本記事で紹介した内容を参考に、設定や配信環境を見直してみてください。