MailData

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

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

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

2024年4月18日
著者: Maitham Al Lawati
翻訳: 永 香奈子

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

Sender Policy Framework（SPF）は、組織がスパムを減らし、送信元を認証するために、長年メールシステムで使用してきたメール認証プロトコルの一つです。
しかし、SPF Failureの原因となる様々なエラーが発生することは、よくあることです。
この記事では、SPFが失敗する原因とその修正方法について説明します。

以下は、SPF Failureを引き起こす一般的な理由です。

なぜSPF Failureが発生するのか？

SPF Failureは、以下の理由により発生する可能性があります。

メールの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アドレスからの送信も許容することになるためです。

3. SPFの結果がsoftfailの場合

neutralと同様に、softfailは~allメカニズムによって識別されます。
これは、受信MTAがメールを受け入れて受信者の受信トレイに配信するものの、送信元のIPアドレスがDNS内のSPFレコードに記載されていない場合、メールがスパムとしてマークされる可能性があることを意味します。
これは、SPF認証が失敗する原因の一つになる可能性があります。

以下はSPF Softfailの例です。 


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

4. SPFの結果がhardfailの場合

hardfailは、受信MTAがSPFレコードに記載されていない送信元からのメールを拒否する状態を指します。
ドメインのなりすましやメールスプーフィングから保護したい場合は、SPFレコードにhardfail(-all)を設定することを推奨します。
以下はSPF hardfailの例です。 


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

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

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

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

後で再試行すると、SPF Passの結果が得られる場合があります。

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

ドメインで発生するもう一つの一般的なエラーが、SPF Permerror（永続的エラー）です。
これは、受信MTAによってSPFレコードが無効と判断された場合に発生する、修正が必要なエラーです。
DNSルックアップの実行中にMTAがSPFを無効と判断する理由は多数あります。

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

SPF Failを修正する方法

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

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

RFCで指定されたDNSルックアップ回数を超過する場合は、この回数を制限内に収めるようにしてください。
PowerDMARCは、顧客がSPFレコードを最適化し、この厳格な制限内に収めるのを支援します。
これはマクロを使用することで実現され、SPFフラッタニングよりも数倍効果的であることが多いです。

ただし、SPFフラッタニングを使用する場合、SPFフラッタニングツールを利用するとプロセスを簡素化できますが、メールサービスプロバイダーがインフラを変更するたびに手動で更新する必要があります。
SPF DNSレコードにマクロを使用することで、DNSのルックアップたVoidルックアップ制限を常に超えないようにすることができます。

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

SPFレコードを手動で実装すると構文エラーが発生しやすく、それが原因で失敗することがあります。
SPFの正しい構文を使用するために、自動SPFレコード生成ツールを使用してレコードを作成してください。
DNSでSPFを設定する際は、必ずリソースタイプとして「TXT」を使用してください。

「CNAME」や「SPF」などの誤ったリソースタイプを設定すると、設定エラーが発生し、SPFが失敗する原因となります。

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

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

承認済みの送信元を記載し忘れると、不必要なSPFの失敗を引き起こすことがあります。

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

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

SPFのベストプラクティス

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

メール認証の失敗は、ドメインの評判や信頼性に悪影響を与えます。
配信の確実性を維持するために、SPFの失敗を防ぐ対策を今すぐ講じる必要があります。
ドメインのSPF設定が正しく構成されているかをテストしたいですか？

ぜひ、当社の無料SPFチェッカーツールをお試しください！