SPF Fail: SPF認証失敗（SPF Fail）の一般的な原因と修正方法のイメージ画像

SPF Fail: 一般的な原因とその修正方法

SPF認証失敗の原因と正しい修正方法を解説


著者: Maitham Al Lawati
翻訳: 永 香奈子

この記事はPowerDMARCのブログ記事 SPF Fail: What It Means and How to Fix It の翻訳です。
Spelldataは、PowerDMARCの日本代理店です。
この記事は、PowerDMARCの許可を得て、翻訳しています。

主なポイント

  1. SPF認証失敗は、構文エラーやDNSルックアップ制限の超過、同一ドメインに複数のSPFレコードが存在することなどが原因で発生します。
  2. SPFでは、「Pass」「Fail」「Softfail」「Neutral」「Temporary Error」などの認証結果が返され、それぞれ異なる状態を示します。
  3. 同一ドメインに複数のSPFレコードがある場合は、「include」メカニズムを利用して1つのSPFレコードに統合することが重要です。
  4. DMARCレポートを定期的に確認することで、SPF認証失敗の原因を把握し、迅速な対策につなげることができます。
  5. メールの到達率を維持し、認証エラーを防ぐためには、SPFのベストプラクティスに沿った運用が欠かせません。

Sender Policy Framework（SPF）は、許可されたメールサーバから送信されたメールであることを検証し、メールのなりすましを防ぐためのメール認証プロトコルです。
SPFを適切に設定すると、受信メールサーバはメールが正規の送信元から送信されたものかどうかを確認できます。
その結果、スパムメールやフィッシングメールの防止につながります。

しかし、設定ミスや認証時の問題によって、SPF認証失敗（SPF Fail）が発生することがあります。
SPF認証失敗とは、受信メールサーバが送信元にメール送信の正当な権限があることを確認できなかった状態を指します。
その結果、メールが迷惑メールとして扱われたり、受信を拒否されたりする場合があります。

SPFとは？

Sender Policy Framework（SPF）は、メールが許可されたメールサーバから送信されたかどうかを検証するメール認証方式です。
分かりやすく言えば、「このドメインからメール送信を許可するサーバの一覧」をDNSに公開する仕組みです。

SPFの目的は、第三者が「From」アドレスを偽装し、正規の送信者になりすましてメールを送信することを防ぐことにあります。
受信メールサーバはSPFレコードを参照し、メールを送信したサーバが許可された送信元かどうかを確認します。

メール送信時のSPFの動作

SPFは次のような流れで動作します。

つまり、SPFは、不正な送信元からのメールが受信トレイへ届くのを防ぐための重要な仕組みです。

SPF認証失敗（SPF Fail）とは？

SPF認証失敗は、受信側のメールサーバが、送信サーバがそのドメインの代わりにメールを送信する権限を持っていないと判断した場合に発生します。
これは、送信サーバのIPアドレスがドメインのSPFレコードに記載された許可済み送信元と一致しないときに起こります。

メールサーバは、SPFポリシで定義されたメカニズムに基づいてSPFの結果を解釈します。
主な結果は以下のとおりです。

Pass
許可されたサーバから送信されています。
Fail
許可されていないサーバから送信されており、多くの場合メールは拒否されます。
Softfail
送信元はSPFレコードに登録されていませんが、疑わしいメールとして受信されます（通常は迷惑メールとして扱われます）。
Neutral
明確なポリシが設定されておらず、受信メールサーバは積極的な判定を行いません。

SPF認証に失敗すると、多くのメールサービスではメールが拒否されたり、迷惑メールフォルダへ振り分けられたりするため、メール到達率が大きく低下する可能性があります。

SPF認証失敗が発生する主な原因

SPF認証失敗は、次のような原因で発生します。

SPF認証に失敗した場合は、まず原因を特定し、適切に修正することが重要です。
原因の調査には、DMARCレポートを継続的に確認することが効果的です。
PowerDMARCでは、DMARC解析ツールを利用してSPF認証失敗の原因を分かりやすく分析できます。

SPF認証失敗の種類

SPFでは、認証結果を示すために「修飾子（Qualifier）」が使用されます。
主な修飾子は次のとおりです。

これらの修飾子は、受信メールサーバが認証結果に応じてメールをどのように扱うかを判断するために使用されます。
たとえば、認証に失敗したメールを拒否するか、迷惑メールとして扱うか、あるいは通常どおり受信するかは、SPFレコードに設定されたポリシによって決まります。

1.SPF None

受信メールサーバが送信ドメインのSPFレコードを確認できない場合は、「None」という結果になります。
これは、次のようなケースで発生します。

この状態では、送信ドメインがSPF認証を設定していないことを意味します。
そのため、SPFによる送信元の検証は行われず、メール認証の信頼性が低下します。
このような問題を防ぐためには、SPF Record Generatorなどを利用して、正しいSPFレコードを作成・公開することをおすすめします。

2.SPF Neutral

SPFレコードに?allを指定すると、認証結果にかかわらず「Neutral」が返されます。
これは、送信を許可するIPアドレスを明示せず、受信メールサーバにも特別な判断を求めない設定です。

そのため、受信メールサーバは送信元を積極的に信頼することも拒否することもなく、中立的な判定を返します。
通常、この設定は実運用ではあまり推奨されません。

3.SPF Softfail

SPF Softfailは~allによって指定されます。
この設定では、送信元IPアドレスがSPFレコードに登録されていなくても、受信メールサーバはメールを受け入れます。

ただし、そのメールは迷惑メールとして扱われたり、スパム判定の対象になったりする可能性があります。
たとえば、次のようなSPFレコードです。 


v=spf1 include:spf.google.com ~all

Softfailは、SPFを導入したばかりの段階で様子を見ながら運用したい場合によく利用されます。

4.SPF Hardfail

SPF Hardfailは-allによって指定されます。
この設定では、SPFレコードに登録されていない送信元から送信されたメールは拒否されます。

メールのなりすましやスプーフィング対策を強化したい場合は、この設定を採用することが推奨されます。
たとえば、次のようなSPFレコードです。 


v=spf1 include:spf.google.com -all

Hardfailを設定する前には、正当な送信元がすべてSPFレコードへ登録されていることを十分確認してください。

5.SPF Temperror（一時的なエラー）

SPF Temperror（Temporary Error）は、一時的なDNSエラーによって発生します。
たとえば、

などが原因です。
この場合、受信メールサーバは4xx系の一時エラーを返します。
一時的な障害であるため、時間を置いて再送すると正常に認証されることも少なくありません。

6.SPF Permerror（恒久的なエラー）

SPF Permerror（Permanent Error）は、SPFレコードそのものに問題がある場合に発生します。
受信メールサーバがSPFレコードを無効と判断すると、このエラーになります。
主な原因は次のとおりです。

補足

受信メールサーバはSPF認証の際にDNS検索を行います。
SPFではDNSルックアップ回数は最大10回までと定められており、この上限を超えるとSPFレコードは無効と判断され、Permerrorが返されます。
これは、SPF認証失敗の原因として非常によく見られるケースです。

SPF認証失敗を修正する方法

安定したメール到達率を維持するためには、SPF認証失敗を防ぐことが重要です。
以下のベストプラクティスを参考に、SPFレコードを適切に管理しましょう。

1.DNSルックアップ回数を制限内に収める

SPFでは、DNSルックアップは最大10回までという制限があります。
この上限を超えるとSPF認証は失敗し、Permerrorが返されます。
PowerDMARCでは、SPFマクロ（Macros）を利用してSPFレコードを最適化し、DNSルックアップ回数を制限内に収めることができます。

多くの場合、SPFフラットニング（SPF Flattening）よりも効率的な方法です。
SPFフラットニングを利用する場合でも、メールサービスプロバイダ（ESP）のインフラ変更に合わせてSPFレコードを更新する必要があります。
SPFマクロを活用することで、DNSルックアップ回数やVoid Lookupの制限を超えるリスクを抑えられます。

2.構文エラーや設定ミスを防ぐ

SPFレコードを手作業で作成すると、構文ミスや設定漏れが発生しやすくなります。
SPF Record Generatorなどのツールを利用すれば、正しい構文のSPFレコードを簡単に作成できます。

また、DNSへSPFを登録する際は、TXTレコードとして登録する必要があります。
誤って「SPF」や「CNAME」など別のレコードタイプを使用すると、SPF認証に失敗する原因となります。

3.正当な送信元をすべて登録する

SPFレコードには、自社だけでなく、メール配信に利用しているすべてのサービスを登録する必要があります。
例えば、

などの外部サービスを利用している場合は、それぞれが指定するSPF設定を追加してください。
また、メールサービスプロバイダは送信IPアドレスや設定内容を変更することがあります。

変更があった際には、SPFレコードも忘れず更新しましょう。
許可された送信元がSPFレコードへ登録されていないことは、SPF認証失敗の代表的な原因の一つです。

4.複数のSPFレコードを1つに統合する

1つのドメインには、SPFレコードを1件しか設定できません。
複数のSPFレコードが存在すると、SPF設定全体が無効と判断され、認証に失敗します。
複数のサービスを利用している場合は、「include」メカニズムを使用して、1つのSPFレコードにまとめましょう。

SPF認証失敗を防ぐためのベストプラクティス

ここまで紹介した対策に加え、以下のポイントも実践することで、SPF認証失敗をさらに減らし、メールセキュリティを強化できます。

DKIMを併用して転送メールに対応する
メールが転送されると、SPF認証は失敗することがあります。
一方、DKIMはメール本文とヘッダに電子署名を付与するため、転送後も認証を維持できます。
そのため、SPFだけでなくDKIMも併用することが重要です。
DMARCと組み合わせて運用する
SPFだけでは十分とは言えません。
SPF認証に失敗しても、DKIM認証が成功していれば、DMARCによってメールの正当性を確認できます。
SPF・DKIM・DMARCを組み合わせて運用することで、メール認証の精度が高まり、なりすまし対策を強化できます。
DMARCレポートを活用する
DMARCレポートを有効にすると、
  • SPF認証失敗
  • DKIM認証失敗
  • なりすましメール
などを継続的に把握できます。
SPFレコードを最新の状態に保つ
新しいメールサービスを導入したり、不要なサービスを停止したりした場合は、SPFレコードも忘れず更新してください。
古い設定を放置すると、認証エラーや不要なDNSルックアップの原因になります。
DNSレコードを定期的に確認する
DNSレコードは一度設定して終わりではありません。
定期的に確認し、
  • 構文エラーがないか
  • DNSルックアップ回数が上限を超えていないか
  • 不要な設定が残っていないか
などを点検することが重要です。

メール認証の失敗は、ドメインの信頼性やメール到達率に悪影響を及ぼします。
これらのベストプラクティスを実践することで、SPF認証失敗を最小限に抑え、安定したメール配信と高いメールセキュリティを実現できます。

まとめ

SPF認証失敗を防ぐことは、メールの信頼性を維持し、ブランドを保護するとともに、安定したメール配信を実現するために欠かせません。
SPFが正しく設定されていないと、送信したメールが迷惑メールとして扱われたり、受信を拒否されたりするだけでなく、第三者によるなりすましに悪用されるリスクも高まります。
こうしたリスクを防ぐには、ドメインを定期的に監視し、SPFレコードを最新の状態に保つことが重要です。

また、SPFだけでなく、DKIMやDMARCと組み合わせて運用することで、より強固なメール認証環境を構築できます。
SPF・DKIM・DMARCを組み合わせた多層的な対策を実施することで、認証精度が向上し、メールの到達率やドメインの信頼性を高めることができます。

SPFの設定に不安がある場合や、認証エラーを未然に防ぎたい場合は、PowerDMARCの各種ツールをご活用ください。
SPFレコードの管理や認証状況の可視化を通じて、メールセキュリティの強化とドメインの保護を支援します。

よくある質問

自分のメールがSPF認証に失敗しているかどうかは、どのように確認できますか？
メールヘッダでSPFの認証結果を確認するほか、DMARCレポートやSPF Checkerなどのツールを利用することで確認できます。
これらのツールを使用すれば、メールがSPF認証に成功しているかどうかや、失敗した場合の原因を把握できます。
SPF認証に失敗すると、メールがバウンスすることはありますか？
はい、あります。
SPFが「Hard Fail」と判定された場合、多くの受信メールサーバではメールが拒否され、バウンスメールが返されることがあります。
一方、「Softfail」の場合はメール自体は受信されることが多いものの、迷惑メールフォルダへ振り分けられる可能性があります。
SPFがあれば、DKIMやDMARCは不要ですか？
いいえ。
SPFだけでは、転送メールへの対応や認証状況の可視化、ドメイン全体の保護までは十分に行えません。

DKIMはメールが改竄されていないことを確認するための認証方式であり、DMARCはSPFとDKIMの認証結果を組み合わせて、メールの取り扱いを制御するとともに、認証状況をレポートとして可視化します。
そのため、SPF・DKIM・DMARCを組み合わせて運用することで、より高いレベルのメールセキュリティとなりすまし対策を実現できます。