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

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

SPFで配信のDMARC認証を担保するために

2024年4月18日
著者: 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エラーの最も一般的な原因とその解決方法について説明します。

メール認証におけるSPF（Sender Policy Framework）とは何か？

Sender Policy Framework（SPF）は、メールが認可されたメールサーバから送信されたものであるかを確認するためのメール認証方法です。
これは、ドメインのDNSレコードに公開された「承認済み送信者の一覧」と考えることができます。
SPFの主な役割は、悪意のある第三者が「From（送信元）」アドレスを偽装して受信者をだます「メールなりすまし」を防止することです。

受信側のメールサーバは、SPFレコードを確認することで、メッセージが本当にそのドメインから送信されたものであるかを検証できます。
SPFがメール配送の過程でどのように機能するかを以下に示します。

  1. 送信ドメインは、自身のDNSにSPFレコードを公開し、自分の代わりにメールを送信することを許可するサーバを指定します。
  2. メールが受信されると、受信側のサーバはドメインのSPFレコードを参照します。
  3. サーバは、送信サーバのIPアドレスがSPFレコード内の許可リストに含まれているかを確認します。
  4. その結果に基づき、サーバはメールを受け入れるか、スパムとしてマークするか、拒否するかを判断します。

要するに、SPFは不正なメールが受信箱に届くのを防ぐためのチェックポイントとして機能します。

SPF Failとは何か？

SPF Fail（SPF失敗）とは、受信側のメールサーバが、送信サーバがそのドメインの代わりにメールを送信する権限を持っていないと判断した場合に発生します。
これは、送信サーバのIPアドレスがドメインのSPFレコードに記載された許可済み送信元と一致しないときに起こります。
メールサーバは、SPFポリシーで定義されたメカニズムに基づいてSPFの結果を解釈します。主な結果は以下のとおりです。

SPFが失敗すると、多くのメールプロバイダはそのメールを完全に拒否するか、スパムフォルダに振り分けるため、メールの到達率が大幅に低下します。

SPFエラー（SPF Failures）が発生する理由

SPFエラーは、以下のような原因で発生することがあります。

メールでSPFが失敗した場合は、まず原因を特定して修正することが重要です。
そのためには、DMARCレポートを定期的に監視することが有効です。
PowerDMARCのDMARCアナライザーを使用すると、SPF認証失敗のレポートを簡単に分析できます。

SPF Failureの種類

以下は、SPFレコードの[mechanisms]の前にプレフィックスとして追加される修飾子[qualifiers]とその意味です。

Pass（通過）:+
メールがSPF認証に合格する。
Fail（失敗）:-
メールがSPF認証に失敗し、拒否される。
Softfail:~
メールがSPF認証に失敗するが、配信は許可される（ただし、疑わしいものとしてマークされる）。
Neutral:?
SPF認証に対する明確な判断を示さず、メールの処理を受信者に委ねる。

これらの指定が重要なのは、メールが拒否された場合に、受信側がどの程度厳格に扱うかを送信ドメイン側で制御できるためです。
たとえば、SPFで「Fail」と判定されたメールでも、「Pass」として扱うように設定したり、「Neutral（中立）」を指定して特に処理を行わないように設定することも可能です。

1. SPFの結果がnoneの場合

最初のケースでは、受信メールサーバがDNSルックアップを実行し、DNS内でドメイン名を見つけることができなかった場合、noneが返されます。
また、送信者のDNSにSPFレコードが存在しない場合もnoneが返されます。
これは、送信者がこのドメインに対してSPF認証を設定していないことを意味します。

この場合、SPF認証は失敗し、-allとして評価されます。
この問題を回避するために、当社の無料SPFレコード生成ツールを使用して、エラーのないSPFレコードを今すぐ生成してください。

2. SPFの結果がneutralの場合

ドメインにSPFを設定する際、SPFレコードに?allメカニズムを付与した場合、送信メールのSPF認証チェックがどのような結果になっても、受信MTAは中立（neutral）の結果を返します。
これは、SPFをneutralモードに設定すると、ドメイン所有者はメール送信を許可したIPアドレスを指定せず、許可されていないIPアドレスからの送信も許容することになるためです。

これは、SPFをニュートラルモードで設定しているためであり、この状態では、どのIPアドレスがそのドメインの代わりにメールを送信できるかを明示的に指定していません。
その結果、認可されていないIPアドレスからの送信も許可してしまうことになります。

3. SPFの結果がsoftfailの場合

SoftfailはNeutralと似ていますが、~allメカニズムによって識別されます。
この設定は、送信サーバのIPアドレスがDNSに登録されたSPFレコード内に存在しない場合でも、受信側のMTAがメールを受け入れて配信するものの、スパムとしてマークされる可能性があることを意味します。
これは、SPF認証が完全に失敗したわけではないものの、認証が不完全または疑わしい状態であることを示します。

そのため、SPF Softfailが発生すると、メールがスパムフォルダに振り分けられることが多く、結果的にメールの到達率低下につながる場合があります。
以下はSPF Softfailの例です。 


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

4. SPFの結果がhardfailの場合

hardfailは、受信MTAがSPFレコードに記載されていない送信元からのメールを拒否する状態を指します。
これは-allメカニズムによって指定されます。

SPF Hardfailを設定すると、ドメインのなりすましやメールスプーフィング（送信元偽装）からの保護を強化できます。
したがって、ドメインの安全性を確保したい場合は、SPFレコードにHardfailを構成することが推奨されます。
以下はSPF hardfailの例です。 


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

SoftfailとHardfailの具体的な違いを学びましょう。

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

SPF認証が失敗する一般的で、しばしば無害な理由の一つに、SPF Temperror（一時的エラー）があります。
これは、DNSタイムアウトなどのDNSエラーによって発生します。
名前が示す通り一時的なエラーであり、4xxのステータスコードを返し、SPF認証の一時的な失敗を引き起こします。

これはSPF認証の途中で一時的に失敗したことを意味しますが、後で再試行するとSPF Passの結果が得られる場合があります。
つまり、SPF Temperrorは恒久的な設定ミスではなく、通信やDNS応答の一時的な障害によるもので、時間経過後に自然に解消されるケースが多いエラーです。

6. SPF Permerror（永続的エラー）

ドメインで発生するもう一つの一般的なエラーが、SPF Permerror（永続的エラー）です。
これは、SPF認証の過程で恒久的な設定エラーが発生した場合に起こり、受信側のMTA（メール転送エージェント）によってSPFレコードが無効と判断されたことを意味します。DNSルックアップの実行中にMTAがSPFを無効と判断する理由は多数あります。

SPFが破損または無効化される主な原因は以下の通りです。

注: MTAがメールのSPFチェックを実行する際、DNSに問い合わせるか、DNSルックアップを行い、メールの送信元の正当性を確認します。
SPFでは最大10回のDNSルックアップが許可されており、これを超過するとSPFが機能しなくなり、Permerror（永続的エラー）を返します。
これはSPF Failの非常に一般的なエラーです。

SPF Failを修正する方法

スムーズなメール配信のためには、SPF認証が失敗しないことが重要です。
SPF Failを修正するには、以下のベストプラクティスに従ってください。

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

RFCで指定されたDNSルックアップ回数を超過する場合は、この回数を制限内に収めるようにしてください。
PowerDMARCは、顧客がSPFレコードを最適化し、この厳格な制限内に収めるのを支援します。
マクロは、SPFフラット化よりも効率的にDNSクエリ数を削減できる場合が多いです。

ただし、SPFフラット化を選択する場合、専用のツールを使用することで設定作業を簡略化できます。
とはいえ、メールサービスプロバイダ（ESP）がインフラを変更するたびに、SPFレコードを手動で更新する必要がある点には注意が必要です。
一方で、SPF DNSレコード内にマクロ（Macros）を使用すると、DNSのVoid Lookupやルックアップ回数の上限超過を回避でき、常にSPF制限内で運用することが可能になります。

2. 構文および設定エラーを回避する

SPFレコードを手動で実装すると構文エラーが発生しやすく、それが原因で失敗することがあります。
SPFの正しい構文を使用するために、自動SPFレコード生成ツールを使用してレコードを作成してください。

DNSでSPFを設定する際は、必ずリソースタイプとして「TXT」を使用してください。
「CNAME」や「SPF」などの誤ったリソースタイプを設定すると、設定エラーが発生し、SPFが失敗する原因となります。

3. すべての送信元を承認する

SPFレコード内で、サードパーティベンダーを含むすべての送信元を適切に承認していることを確認してください。
ベンダーは、送信IPのリストを変更または追加することがよくあります。

そのため、これらの変更を常に把握し、自身のSPFレコードにも最新の送信元情報を反映させる必要があります。
認可済み送信元をSPFレコードに含め忘れると、正当なメールであっても不要なSPFエラーが発生する原因となります。

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

同じドメインに対して複数のSPFレコードが存在すると、SPFの設定が無効になり、SPFの失敗につながります。
このような場合は、includeメカニズムを使用して、複数のレコードを1つのレコードに統合することを推奨します。

SPFのベストプラクティス

上記のSPFベストプラクティスに従うことで、ドメイン所有者は不要なSPFの失敗を大幅に減らすことができます。
さらにメールセキュリティを強化するために、企業が実施できる追加のベストプラクティスを以下に示します。

転送メールによるSPFの失敗を防ぐために、DKIMを使用する
メール転送ではSPFが失敗することが多いですが、DomainKeys Identified Mail（DKIM）を有効にすることで、認証を保持し、正当なメールとして受信される可能性を高めることができます。
DMARCとDKIMを併用する
SPFが失敗しても、DKIMが成功していれば、DMARC（Domain-based Message Authentication, Reporting, and Conformance）によりメールを正当と判定できます。
DMARCレポートを有効にして、SPFの失敗とその原因を監視する
DMARCレポートを定期的に監視することで、SPFエラーの発生状況や原因を把握し、早期に問題を特定・修正できます。
SPFレコードを最新状態に保つ
新しいサードパーティメールサービスを追加したり、既存のものを削除した場合は、必ずSPFレコードを見直し・更新してください。
DNSレコードを定期的に監査・テストする
DNSレコードが正確で一貫性を保っているか、またSPFルックアップ制限（10回）を超えていないかを定期的に確認しましょう。

メール認証の失敗は、ドメインの信頼性と評判を損なう重大なリスクです。
これらのベストプラクティスを実施することで、SPFエラーのリスクを最小限に抑え、より高いメール到達率とブランド保護を実現できます。

結論

SPFエラーを修正することは、信頼性の維持、ブランド評判の保護、そして確実なメール配信を実現するうえで極めて重要です。
SPF設定が不適切なままだと、メールがスパムとして扱われたり、拒否されたり、さらには攻撃者に悪用されてなりすましの手段として使われる危険性があります。
最善の対策は予防的アプローチを取ることです。

ドメインを定期的に監視し、SPFレコードを常に最新の状態に保ち、SPF・DKIM・DMARCといった複数のメール認証プロトコルを併用する多層防御を導入しましょう。
これにより、認証チェックに合格する可能性が大幅に向上し、メール通信の安全性を強化できます。
SPF設定が正しく構成されているか確認し、不要なエラーを防ぎたい場合は、PowerDMARCの機能を活用して、メールセキュリティを強化し、ドメインの不正利用を防止することをおすすめします。

よくある質問

自分のメールがSPFで失敗しているかどうかを確認するには？
メールヘッダーを確認することで、SPFの検証結果を確認できます。
また、DMARCレポートやSPFチェッカー（SPF検証ツール）を使用することで、送信したメールがSPF認証に成功しているか、失敗しているかを確認することができます。
SPFの失敗が原因でメールがバウンス（配信失敗）することはありますか？
はい、あります。 SPFが「Hardfail（‐all）」として失敗した場合、受信サーバはそのメールを完全に拒否し、バウンス（配信拒否）を発生させることがあります。
一方で、サーバによってはメールを受け入れるものの、スパムフォルダに振り分ける場合もあります。
SPFを設定していれば、DKIMやDMARCは不要ですか？

いいえ、必要です。
SPFだけでは、転送メールの保護やドメイン単位でのレポート機能を提供できません。
DKIM（DomainKeys Identified Mail）は、メール本文と署名の整合性を保証し、改ざんを防ぎます。

さらに、DMARC（Domain-based Message Authentication, Reporting, and Conformance）は、SPFとDKIMの結果を統合し、ドメインレベルでの可視性と、スプーフィング対策の強化を実現します。
これら3つ（SPF・DKIM・DMARC）を組み合わせることで、メール認証の信頼性を高め、ブランドの安全性を確保することができます。