メール認証におけるSPFの制限を理解する
SPF制限をDMARCで解決
2024年5月20日
著者: Ahona Rudra
翻訳: 岩瀨 彩江
この記事はPowerDMARCのブログ記事 Understanding the Limitations of SPF in Email Authentication の翻訳です。
Spelldataは、PowerDMARCの日本代理店です。
この記事は、PowerDMARCの許可を得て、翻訳しています。
Sender Policy Framework（SPF）は、フィッシングやスパム攻撃から企業のメールを保護するには十分ではありません。
SPFは、送信元IPアドレスがドメインのDNSレコードで承認されているかを確認することで、メール受信者をなりすましメールから保護するメール認証プロトコルです。
しかし、DNSルックアップの最大数に関するSPFの制限や、Fromアドレスとドメインの不一致によって、実装エラーが発生し、メールの到達性に問題を引き起こします。
DMARCはSPF（およびDKIM）を基盤として、強化されたセキュリティとレポート機能を提供します。
このブログでは、これらのSPFの問題と、DMARCがどのようにしてSPFの制限をどのように解決するのかを解説します。
重要なポイント
- SPFには10回の検索制限があり、それを超えると検証失敗（Permerror）や配信問題を引き起こす可能性があります。
- SPFは目に見えるFromアドレスではなく、Return-Pathドメインを確認するため、攻撃者が送信者をなりすますことが可能です。
- SPF認証はメール転送時に失敗することがあり、これは転送サーバのIPアドレスが元の送信者のレコードに登録されていないことが多いためです。
- DMARCは、Fromアドレスと認証済みドメインの整合性を強制することで、さらにメールチャネルの可視性を高めるレポートを提供することで、SPFの制限を補います。
- SPFレコードの最適化として、未使用のメカニズムを削除したり、SPFフラッテンを利用することで検索制限に対応することができます。
SPFレコードにはどのような制限がありますか？
SPFには大きく三つの制限があり、そのため実装と運用がやや難しくなっています。
1. SPFの10回までのルックアップ制限
ユーザがDNSサーバに問い合わせを行うと、そのバリデータのリソース（帯域幅、時間、プロセッサ、メモリ）が消費されます。
バリデータへの過負荷を防ぐため、SPFには10回までの追加DNSルックアップという制限があります。
ただし、SPFポリシーレコード自体のDNSクエリはこの制限には含まれません。
RFC7208のセクション4.6.4によると、受信側のメールサーバは10回の検索制限に達した時点で処理を続行してはいけません。
この場合、メールはSPF検証を「Permerror」というエラーで拒否します。
このSPF Permerrorは、SPFの実装過程で頻繁に発生するエラーのひとつであり、メールが配信されなくなる原因となります。
これは、1つのドメインに複数のSPFレコードが存在する場合、構文エラーがある場合、またはSPFレコードの制限を超えた場合に発生します。
この制限を超えるとSPF実装は無効と見なされ、SPF検証に失敗し、メールの配信率に悪影響を及ぼします。
このエラーを回避し、安全なメール通信を保証するためには、SPFレコードチェッカーを利用することができます。
さらにRFCによると、MXレコードに含まれるホスト名に対するDNSクエリでは、AレコードまたはAAAAレコードが10件を超えてはならないとされています。 また、PTRレコードに対するDNSクエリで10件を超える結果が得られた場合、最初の10件のみが表示され利用されます。
2. 人間が読むことのできる送信元アドレス
SPFの2つ目の制限は、SPFレコードが対象とするReturn-Pathドメイン（エンベロープ送信者、MFromとも呼ばれる）であり、受信者がメールクライアントで目にするFromアドレス（ヘッダー送信者）には適用されないという点です。
一般的に、受信者は非表示のReturn-Pathアドレスには注意を払わず、メールを開いた際に表示されるFromアドレスだけに注目します。
攻撃者はこの欠点を悪用し、偽のドメインをReturn-Pathに設定してSPF認証をすり抜け、Fromアドレスを正規または正規に見えるアドレスに偽装することで、フィッシング攻撃を仕掛けます。
多くの人がReturn-Pathアドレスの存在を知らず、確認もしないため、攻撃者にとってはSPF保護を簡単に回避できる手口となっています。
3. メール転送における問題
SPFには、メールの到達性に影響を与える重大な弱点がもうひとつあります。
それは、ドメインにSPFを導入している場合でも、誰かがあなたのメールを転送すると、その転送メールがSPFポリシーによって拒否される可能性がある点です。
これは、転送の過程でメッセージを送信するサーバ（およびそのIPアドレス）が変わる一方で、送信者のFromアドレスは元のまま残ることが多いために起こります。
受信サーバは送信者のFromアドレスを確認しつつ、実際には転送サーバのIPアドレスを元の送信者のSPFレコードと照合します。
しかし、転送サーバのIPアドレスは通常、元の送信者のSPFレコードには含まれていないため、検証が失敗します。
その結果、転送されたメールが拒否されたり、スパムとして扱われたりする可能性があります。
SPFレコードのサイズがメール配信に与える影響
受信者がSPFレコードの制限を超えると、SPF検証に失敗し、「Permerror」というエラーが発生します。
このエラーは、DMARC監視を利用している場合に確認できることがあります。
受信者側は、Permerrorを起こしたメールをどのように処理するかを選択できます。
拒否を選んだ場合、そのメールは送信元にリターンされます。
一部の受信者は、SPF結果を「neutral（中立）」として扱うように設定することがあり、これはSPFが存在しない場合と同様に処理されます。
また、「fail」や「softfail」を選択することも可能で、その場合はSPF認証に失敗したメールが拒否されるのではなく、迷惑メールフォルダに振り分けられます。
これらの結果は、DMARC、DKIM、スパム評価の結果と併せて判断されます。
SPFの制限超過は、受信者のメイン受信トレイにメールが届く可能性を下げることで、メールの配信性に悪影響を及ぼします。
バリデータはSPFポリシーを左から右へ順に評価し、送信元IPアドレスに一致が見つかるとその時点で処理を終了します。
そのため、送信元によっては、ポリシーが完全に評価されるには10回以上のDNSルックアップを必要とする場合でも、必ずしも制限に達しないことがあります。
これにより、SPFレコードの制限に起因するメール配信の問題を特定することが難しくなるケースがあります。
必要な検索回数を減らすには？
一部のドメイン所有者にとって、SPFの10回検索制限内に収めるのは容易ではありません。
これは、2006年にRFC4408が実装されて以来、メールのやり取りの形態が大きく変化したためです。
現在では、多くの企業が1つのドメインで複数のクラウドベースのプログラムやサービスを利用しています。
そこで、この一般的なSPF制限を回避するためのいくつかの方法を以下に示します。
- 使用していないサービスを削除する
-
SPFレコードを確認し、不要または利用していないサービスが含まれていないかを確認してください。
include オプションやその他のメカニズムに、すでに利用していないサービスのドメインが指定されていないかをチェックすることが重要です。 - デフォルトのSPF値を削除する
-
SPFポリシーのデフォルトは、一般的に
v=spf1 a mxに設定されています。
しかし、多くのAレコードやAAAAレコードはWebサーバ用に使われており、必ずしもメール送信に利用されるわけではありません。
そのため、aやmxの値は不要である場合が多いのです。 - ptrメカニズムの使用を避ける
-
ptrメカニズムは、セキュリティが低く信頼性にも欠けるため強く推奨されていません。
このメカニズムは多くのDNS検索を必要とするため、SPFの検索回数制限の問題を引き起こします。
したがって、可能な限り使用を避けるべきです。 - mxメカニズムの使用を避ける
-
mxメカニズムはメールの受信に利用されるものであり、必ずしも送信に使われるわけではありません。
そのため、SPFの検索制限内に収めるためには、このメカニズムの使用を避けることができます。
クラウドベースのメールサービスを利用している場合は、代わりに include メカニズムを使用するようにしてください。 - IPv6 または IPv4 を使用する
-
IPv4やIPv6は追加の検証を必要としないため、SPFの最大10回の検索制限を超えないようにするのに役立ちます。
ただし、これらのメカニズムは定期的なメンテナンスが必要です。
更新が行われないまま放置すると、誤りが発生しやすくなるため注意が必要です。 - SPFレコードのフラッテンを検討する
-
一部の情報源では、SPFポリシーをフラッテン（短縮）すればするほど、ドメインの評価が向上するとされています。
この方法は、SPF検索制限を回避する手段として推奨されることがあります。
フラッテンとは、include などのメカニズムを、それに関連付けられた実際のIPアドレスに置き換えることで、SPF検証時に必要なDNS検索の回数を直接削減する手法です。
ただし、フラッテンには注意が必要です。
含まれるサービスの背後にあるIPアドレスが変更された場合、フラッテンされたレコードは古くなり、手動で更新しなければ正当なメールがSPF検証に失敗する恐れがあります。
この課題を軽減するために、自動SPFフラッテンツールを利用することも可能です。
SPFの制限を克服するためのDMARCの役割
DMARCは、人間が読むことのできる送信元アドレスに関するSPFの制限に対応するために、人間が読むFromフィールドのドメインと、SPFによって認証されたドメイン（Return-Pathドメイン）の一致＝アライメントを要求します。
つまり、あるメールがSPF検証を通過したとしても（送信IPアドレスがReturn-Pathドメインで許可されている場合）、Return-PathドメインがFromドメインと一致しなければ、SPFにおけるDMARCアライメントは失敗します。
DMARCで受け入れられるためには、SPFのアライメントをパスするか、DKIMのアライメントをパスする必要があります。
これにより、Return-PathがSPFに合格している一方でFromアドレスになりすますという、フィッシングでよく使われる手口を防ぐことができます。 さらに、DMARCはレポート機能を導入し、自分のドメインから送信されたとされるメールについて、認証結果（SPF、DKIM、DMARC、アライメント）や送信元の情報をドメイン所有者にフィードバックします。 この可視性により、誤った設定、転送に伴う問題、悪意あるなりすましの試みを特定することが可能になります。
SPFレコードのフラッテンが10回のDNSルックアップ制限を解決する仕組み
SPFレコードのフラッテンとは、SPF（Sender Policy Framework）レコードを最適化し、SPFにおけるDNSルックアップの10回制限を回避するために使われる手法です。
SPFレコードにはしばしば include、a、mx、ptrといった仕組みが含まれており、これらはDNS検索を必要とします。
特に、includeが入れ子になっている場合（参照先のドメインのSPFレコードにもさらに include が含まれているケース）、簡単に10回の制限を超えてしまい、SPF検証の失敗（Permerror）やメール配信の問題を引き起こす可能性があります。
この制限を解決するために使われるのがSPFレコードのフラッテンです。
フラッテンでは、検索を伴うメカニズム（主に include、場合によっては a や mx）を、対応するIPアドレスやCIDRレンジに置き換えます。
これにより、受信サーバは追加のDNS検索を行う必要がなくなり、SPFレコード検証時に必要なクエリ数が大幅に削減されます。
その結果、元のSPFレコード構造では10回以上のDNSルックアップが必要な場合でも、フラッテンを行うことでSPF検証に合格できるようになります。
この手法は、Permerrorを防ぎ、DNS応答のタイムアウトや一時的なDNSサーバの障害によるSPF認証失敗のリスクを低減する効果があります。
ただし、フラッテンには注意が必要です。
背後にあるIPアドレスが変更されると、フラッテンされたレコードは古くなり、手動で更新しない限り正当なメールがSPF検証に失敗する可能性があります。
そのため、フラッテンを行う場合は、定期的な更新や自動フラッテンツールの利用が推奨されます。
大企業におけるSPF実装の課題
SPFでは、SPF検証中にDNSインフラへのDoSやDDoS攻撃を防ぐため、最大10回までのDNSルックアップ制限が設けられています。
しかし、大企業ではこのルックアップ回数が非常に早く積み重なってしまいます。
以前は企業が自社でメールサーバを運用することが一般的でしたが、現在ではマーケティングメール、トランザクションメール、CRM、サポートシステムなどに多くのサードパーティ送信サービスを利用するようになっています。
各サードパーティサービスは通常、SPFレコードに include メカニズムを追加する必要があり、これが1回のルックアップとしてカウントされます。
さらに、そのサービス自身のSPFレコード内にも追加のルックアップが含まれていることがあります。
このため、複数のサービスを追加するとすぐに10回の制限に達してしまい、前述の Permerror（SPF検証エラー）を引き起こす可能性があります。
結果として、大企業にとっては、数多くの送信元を管理しつつ、正規のメールをすべて認証対象に含めながら、10回制限を守ることが大きな課題となります。