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

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

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

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

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

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

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

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

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

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

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

受信者がSPFレコードの上限を超えた場合、SPFチェックに失敗し、Permerrorが発生します。このエラーは、DMARCモニタリングで確認することができます。受信者は、Permerrorが発生したメールをどのように処理するかを選択することができます。受信者は、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台のサーバーを使用することができ、非常に迅速に限界に達するという問題が発生します。