SPFの照会が多すぎませんか？

SPFの導入や管理を行う際、「DNSルックアップが多すぎる」というエラーに遭遇することがあります。インターネット上には誤った情報が溢れているため、事態はさらに複雑になっています。この記事では、この問題を解決する方法について説明します。

SPFには、一連のSPFレコードに含まれる「DNSクエリ発行メカニズム」の数に、組み込みの制限が設けられています。その制限は10です。これらのメカニズムは以下の通りです： a, mx, ptr, exists, include、および redirect.

最もよくあるケースとして、「DNS ルックアップが多すぎる」というエラーは、大量の include メカニズム。たとえば、あるドメインがGoogle Appsを利用している場合、Google独自のSPFレコードによって、許可されている10個のDNSクエリメカニズムのうち4つが自動的に占められてしまいます：

v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all

インターネット上の多くのサービスでは、メールドメインの所有者に対し、そのサービスをSPFレコードに追加するよう求めてきます。しかし残念ながら、SPFの仕組みに関する誤解があるため、こうしたサービスを追加しても通常は何の効果もありません。

問題は、SPFがメールのエンベロープドメインをチェックする一方で、ドメインのSPFレコードへの追加をリクエストするサービスが、そのドメインをエンベロープアドレスで使用していないケースがほとんどだということです。SPFの仕組みについて解説した短い動画を公開しました。

ただし、一つ注意点があります。たとえインターネットサービスが、あなたに代わって送信するメールの「差出人アドレス」にあなたのドメインを使用していたとしても、何らかの理由でメールの配信に失敗し、バウンス通知（例：「アドレスが不正です！」や「受信箱がいっぱいです！」など）を送信する必要が生じた場合、そのバウンス通知はインターネットサービス側ではなく、あなたのドメインのメールサーバーに送信されることになります。

バウンス通知を受け取れないのは問題です。そこで、インターネットサービスが他者の代わりに、より適切なメールを送信する方法について解説しました。

SPFレコードから削除できる不要なサービスを特定するため、dmarcianはドメインのDMARCフィードバックデータとSPFレコードを照合します。dmarcianアカウントにログインしており、DMARCフィードバックが存在する場合、SPF SurveyorはSPFレコードのどの部分が実際に使用されているかを表示します。

それでも解決しない場合は、SPF 10のDNSルックアップ制限に対処するための一般的な解決策について解説したこちらの記事をご覧ください。また、お気軽に当社までご連絡いただければ、確認させていただきます。