メール認証におけるSPFの制限を理解する

センダー・ポリシー・フレームワーク SPFから企業の電子メールを保護するには、SPFだけでは不十分である。 フィッシングやスパム攻撃から企業の電子メールを守るには不十分です。SPFはメール認証プロトコルであり、送信元IPアドレスがドメインのDNSレコードで認証されているかどうかをチェックすることで、なりすましメールからメール受信者を保護する。しかし、SPFによるDNSの最大参照回数の制限や、Fromアドレスとドメインの不一致により、実装エラーが発生し、メール配信に支障をきたしていました。DMARCは、SPF（およびDKIM）の上に構築され、強化されたセキュリティとレポートを提供します。このブログでは、これらのSPFの問題と、DMARCがこれらのSPFの制限をどのように克服するかについて説明します。

SPFレコードの制限事項とは何ですか？

SPFには3つの大きな制限があり、そのために実装と維持が少々厄介になっている。

1.SPF10-Lookupの制限について

ユーザーがDNSサーバーに問い合わせると、バンド幅、時間、CPU、メモリなどの バリデータのリソースが使用される。バリデータの負荷を回避するため、SPFの追加検索回数は10回に制限されています。ただし、SPFポリシーレコード自体のDNSクエリーは、この制限にカウントされません。

以下の通り RFC7208セクション4.6.4にあるように、受信者のメールサーバは10ルックアップの制限に達すると、それ以上の処理を行うべきではない。このような場合、メールはPermerrorエラーでSPF検証を拒否する。SPF Permerrorは、SPFの実装プロセスでよく現れるメッセージの一つである。1つのドメインに複数のSPFレコードが存在する場合、構文エラーがポップアップした場合、SPFレコードの上限を超えた場合などに発生します。この制限を超えると、SPF実装が無効とみなされ、メールのSPF失敗となり、メール配信率に悪影響を及ぼす可能性があります。

無料の SPFレコードチェッカーを使用すると、このエラーを排除し、安全な電子メールの会話を確保することができます。

さらに、RFCによると、ホスト名のDNSクエリは MXレコードで見つかったホスト名のDNSクエリは AレコードまたはAAAAレコードを生成してはならない。DNS PTRクエリが10個以上の結果を生成した場合、最初の10個の結果のみが表示され、使用されます。

2.人間が読み取れるFromアドレス

2つ目のSPFの制限は、SPFレコードが特定のReturn-Pathドメイン（エンベロープ送信者またはMFromとも呼ばれる）に適用され、受信者がメールクライアントで見るFromアドレス（ヘッダー送信者またはFromアドレス）には適用されないことです。一般的に、受信者は非表示のReturn-Pathアドレスにはあまり注意を払わず、メールを開いたときに表示されるFromアドレスにのみ注目します。ハッカーはこの抜け穴を利用し、Return Pathアドレスに偽ドメインを使用し（SPFを通過する）、Fromアドレスを正規のものまたは正規に見えるものに偽造することで、フィッシング攻撃を試みます。ほとんどの人はReturn Pathアドレスに気づいておらず、それをチェックすることもないため、このトリックを使えば、攻撃者は簡単にSPF保護を回避することができる。

3.メール転送の問題

SPFにはもうひとつ、メール配信に悪影響を及ぼす重大な障害ポイントがあります。あなたのドメインにSPFを実装している場合、誰かがあなたのメールを転送すると、転送されたメールがSPFポリシーのために拒否されることがあります。これは、転送処理によって送信サーバー（およびそのIPアドレス）は変更されますが、元の送信者のFromアドレスはそのままであることが多いためです。受信サーバーには元のFromアドレスが表示されるが、元の送信者のSPFレコードと照合して、転送サーバーのIPアドレスをチェックする。通常、転送サーバーのIPアドレスは元の送信者のSPFレコードに含まれていないため、チェックに失敗し、転送されたメールが拒否されたり、スパムとしてマークされたりする可能性があります。

PowerDMARCでセキュリティを簡素化！

SPFレコードのサイズがメール配信に与える影響について

受信者がSPFレコードの上限を超えると、SPFチェックに失敗してPermerrorが発生する。このエラーはDMARCモニタリングで確認できます。受信者は、Permerrorが発生したメールをどのように処理するかを選択できます。受信者は、メールをバウンスバックさせるエントリーを拒否することができます。SPFが使用されていないかのように）「中立」のSPF結果を表示するように設定する受信者もいる。また、「fail」や「softfail」を選択することもでき、これはSPF認証チェックに失敗したメールが拒否されずに迷惑メールフォルダに入ることを意味します。 

この結果は、DMARC、DKIM、スパム評価の結果も考慮して決定されます。SPFの上限を超えると は、意図した受信者の主受信箱にメールが着信する確率を低下させることにより、メールの配信性に影響を与えます。

バリデータはSPFポリシーを左から右へ評価し、送信者IPアドレスに一致するものが見つかれば、処理を停止する。現在、送信者によっては、SPFポリシーが完全に評価するために10回以上の検索を要求しても、バリデータは必ずしも検索制限に達しない場合があります。これにより、SPFレコードの制限に関連するメール配信の問題を特定することが困難になります。 

必要なルックアップの数を減らすには？

メール交換の習慣が2006年（RFC4408が実装された当時）とは大きく変化しているため、一部のドメイン所有者にとって、SPFルックアップの上限を10回に抑えることは難しい。現在、企業は1つのドメインで複数のクラウドベースのプログラムやサービスを利用している。そこで、この一般的なSPFの制限を克服する方法をいくつか紹介しよう。

• 未使用のサービスを削除する

SFレコードを評価し、未使用または未要求のサービスがあるかどうかを確認します。をチェックし、'include' など、使われなくなったサービスのドメインが表示される仕組みがないか確認します。

• SPFのデフォルト値を削除する

デフォルトのSPFポリシーは、通常、'v=spf1 a mx' に設定されています。. ほとんどの A レコードおよび AAAA レコードはメールを送信しないウェブサーバに使用されるため、'aと'mx'の仕組みは必要ありません。

• の使用は避けてください。 ptr機構を使わないでください。

は ptr 機構は、セキュリティが弱く信頼性が低いため、非常に推奨されない。この機構は、より多くのルックアップを必要とするため、SPFの制限問題を引き起こします。したがって、可能な限り避けるべきです。

• を使用しないようにします。 mx機構

は mxのメカニズムはメールを受信するために使われるもので、必ずしも送信するために使われるわけではありません。そのため、ルックアップ時に設定されるSPFレコードの制限内に収まるように、使用を控えることができます。クラウドベースのメールサービス利用者であれば、'include' を使用してください。の仕組みを代わりに使用してください。

• IPv6 または IPv4 を使用する 

IPv4とIPv6は、追加の検索を必要としないので、SPFの10回以内の検索という制限を超えないようにすることができます。ただし、この2つのメカニズムは再調整しないとエラーが発生しやすくなるため、定期的に更新して維持する必要があります。

• SPFレコードのフラット化を検討する

SPFポリシーが平坦であればあるほど（あるいは短ければ短いほど）、ドメインの評判は良くなると主張するリソースもある。彼らは、ルックアップに設定されたSPFレコードの制限内にとどまるために、この方法を提案しています。平坦化には、「include」のようなメカニズムを実際の解決先IPアドレスに置き換えることが含まれ、検証時に必要なDNSルックアップの数を直接的に減らします。しかし、フラット化には慎重な管理が必要です。インクルードされたサービスの背後にあるIPアドレスが変更された場合、フラット化されたレコードは古くなり、正当なメールがSPFチェックに失敗するのを防ぐために手動で更新する必要があります。自動SPFフラット化ツールは、このプロセスの管理に役立ちます。

SPFの制限を克服するためのDMARCの役割

DMARCは、人間が読み取り可能なFromフィールドのドメインと、SPFによって認証されたドメイン（Return-Pathドメイン）との一致または整合を要求することで、人間が読み取り可能なFromアドレスのSPFの制限に対処している。

そのため、あるメールが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の10DNSルックアップ制限を克服するために使用される技術です。10 DNSルックアップ制限は、多くのDNSリゾルバが課す制限であり、ドメインのSPFレコードを検証する際に実行できるDNSクエリの数を制限しています。

メールを受信すると、受信者のメールサーバーは送信者のドメインのDNSにSPFレコードを問い合わせ、送信者がそのドメインからメールを送信することを許可されているかどうかを確認する。SPFレコードは多くの場合、DNSルックアップを必要とする "include"、"a"、"mx"、"ptr "といったメカニズムを使用している。SPFレコードにこのようなメカニズムが多く含まれている場合、特にネストされたインクルード（インクルードされたドメインのSPFレコードにもインクルードが含まれている場合）は、すぐに10回のDNSルックアップの制限を超えてしまい、SPF検証の失敗（Permerror）やメール配信の問題につながる可能性があります。

この制限を克服するために、SPFレコードのフラット化が使用される。SPFレコードのフラット化とは、SPFレコード内のルックアップの原因となるメカニズム（主に「include」だが、潜在的には「a」や「mx」も）を、対応するIPアドレスまたはCIDR範囲に置き換える技術である。これにより、さらなる検索を必要とする代わりにIPアドレスが直接リストされるため、SPFレコードを検証するために必要なDNSクエリの数が減少する。

SPFレコードを平坦化することで、SPFレコードの検証に必要なDNSクエリの回数が大幅に削減され、元のレコード構造では10回以上のDNSルックアップが必要であった場合でも、メールメッセージがSPF検証に合格できるようになります。このテクニックはSPFパーメラーを防ぎ、DNSクエリのタイムアウトや一時的なDNSサーバーの問題によるSPFレコード検証失敗のリスクを減らすのに役立つ。しかし、前述したように、フラット化されたレコードは、基礎となるIPアドレスが変更されたときに正確性を保つためにメンテナンスが必要です。

大企業におけるSPF導入の課題

SPFは、DoS攻撃やDDoS攻撃を防ぐために、ルックアップ回数を10回以下に制限している。 DoS攻撃やDDoS攻撃を防ぐために、10ルックアップ以下に制限している。残念なことに、これらのルックアップは、特に大企業では、あっという間に増えてしまう。以前の企業はしばしば独自のメールサーバーを運用していたが、現在ではマーケティング、トランザクションメール、CRM、サポートシステムなど、数多くのサードパーティーの送信者に大きく依存している。各サードパーティ・サービスは、SPFレコードに「インクルード」メカニズムを必要とすることが多く、これは1つのルックアップとしてカウントされ、独自のSPFレコードにはさらなるルックアップが含まれる可能性がある。このため、複数のサービスを追加すると、ドメインがすぐに10ルックアップの制限に達するか超えてしまい、前述のPermerrorの問題につながるという問題が発生します。これらの多数のソースを管理し、すべての正当なメールが認証されるようにしながら制限内にとどまることは、重要な課題となる。

• について
• 最新記事

Ahona Rudra

ドメインとメールセキュリティのエキスパートPowerDMARC

AhonaはPowerDMARCのマーケティングマネージャーで、サイバーセキュリティのトピックについて5年以上の執筆経験があり、ドメインと電子メールのセキュリティを専門としている。ジャーナリズムとコミュニケーションの卒業後学位を取得し、2019年からセキュリティ分野でキャリアを固めている。

最新記事 by Ahona Rudra(全て見る)

• 2025年、コールドメールはまだ有効か？アウトリーチとセキュリティのベストプラクティス- 2025年6月20日
• DMARC MSP ケーススタディ：PrimaryTechがPowerDMARCでクライアント・ドメイン・セキュリティを簡素化した方法- 2025年6月18日
• DMARCの誤検知：原因、対策、予防ガイド- 2025年6月13日