センダー・ポリシー・フレームワーク SPFから企業の電子メールを保護するには、SPFだけでは不十分である。フィッシングやスパム攻撃から企業の電子メールを保護するには十分ではありません。SPFによるDNSルックアップの最大回数の制限や、Fromアドレスとドメインの不一致により、実装エラーが発生し、メール配信に問題が発生します。このブログでは、これらの問題と、DMARCがこれらのSPFの制限をどのように克服するかについて説明します。

主なポイント

SPFには10回のルックアップ制限があり、これを超えるとメールの検証に失敗し、配信に問題が生じる可能性がある。
Return-PathドメインはSPFがチェックするものであり、Fromアドレスを偽装したフィッシング攻撃を許してしまう可能性がある。
SPFレコードに不要なメカニズムを使うと、管理が複雑になり、ルックアップの上限を超えることになる。
DMARCは、SPFチェックで使用されるFromアドレスと認証ドメインの間の整合を強制することにより、電子メールのセキュリティを強化します。
SPFレコードのフラット化は、ネストしたドメインをIPアドレスに置き換えることで、ルックアップ回数を減らし、メール認証の成功を助けます。

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

SPFには2つの大きな制限があり、実装と維持が少し厄介です。

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

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

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

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

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

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

15日間のトライアルデモを予約する

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

SPFの2つ目の制限は、SPFレコードが特定のReturn-Pathドメインに適用され、Fromアドレスには適用されないことです。一般に、受信者はReturn-Pathアドレスにあまり注意を払わず、メールを開くときにFromアドレスにのみ注目します。ハッカーはこの抜け穴を利用して、Fromアドレスを偽造し、フィッシング攻撃を試みます。

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レコードの制限内に収まるように、この方法を提案しています。しかし、平坦化すると、レコードにエラーが発生しやすくなり、定期的な更新が必要になるため、推奨されません。

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

DMARCは、人間が読めるFromフィールドとSPFによって認証されたサーバーとの間の一致または整合を要求することによって、人間が読めるFromアドレスのSPFの制限に対処している。

そのため、あるメールがSPFチェックに合格しても、ドメインがFromアドレスと同じでない場合、DMARCはその認証を無効にします。つまり、そのメールは認証テストに不合格となる。

SPFレコードのフラット化は、10回のDNSルックアップ制限をどのように克服するのでしょうか。

SPFレコードの平坦化は、SPF（Sender Policy Framework）レコードを最適化し、SPFの10DNSルックアップ制限を克服するために使用される技術です。10 DNSルックアップ制限は、多くのDNSリゾルバが課す制限であり、ドメインのSPFレコードを検証する際に実行できるDNSクエリの数を制限しています。

電子メールを受信すると、受信者のメールサーバーは送信者のドメインのDNSにSPFレコードを問い合わせ、送信者がそのドメインからメールを送信することを許可されているかどうかを検証します。しかし、SPFレコードが多くのネストしたインクルードを含む場合、DNSルックアップの上限である10件をすぐに超えてしまい、SPF検証の失敗やスパムの誤検知につながる可能性があります。

この制限を克服するために、SPFレコードの平坦化が使用されます。SPFレコードのフラット化とは、SPFレコード内のすべてのネストされたinclude文を、対応するIPアドレスまたはCIDR範囲に置き換える技術です。これにより、含まれる各ドメインに個別に問い合わせる必要がなくなるため、SPFレコードを検証するために必要なDNSクエリーの回数が減ります。

SPFレコードを平坦化することで、SPFレコードの検証に必要なDNSクエリーの回数を大幅に削減し、元のレコードのDNSルックアップ回数が10回以上であっても、メールメッセージのSPF検証をパスすることが可能になります。また、DNSクエリーのタイムアウトやDNSサーバーの一時的な問題によるSPFレコードの検証失敗のリスクも軽減されます。

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

SPFでは、DoS攻撃を防ぐために、ルックアップを10回以下に制限することを余儀なくされています。 DoS攻撃やDDoS攻撃.残念ながら、これらのルックアップは、特に大企業では、非常に速く追加される可能性があります。以前は、企業は独自のメールサーバーを運用していましたが、現在ではサードパーティの送信者を利用しています。これは、それぞれが3、4台のサーバーを使用することができ、非常に迅速に限界に達するという問題が発生します。