SPFを導入・管理する際、「DNSルックアップが多すぎる」というエラーに遭遇することがある。インターネット上には悪い手引きがたくさんあるのだから仕方がない。この記事では、この問題を解決する方法を説明する。
SPFには、1セットのSPFレコードが含むことのできる「DNSクエリー機構」の数に制限が組み込まれている。その制限は10である。これらのメカニズムは、a、mx、ptr、exists、include、redirectである。
最も一般的なのは、多くのインクルードメカニズムを使用しているために「Too many DNS lookups（DNSルックアップが多すぎる）」というエラーに遭遇することです。例えば、あるドメインがGoogle Appsを使用している場合、Google独自のSPFレコードは、DNSクエリで許可されている10個のうち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サーベイヤーはSPFレコードのどの部分がアクティブに使用されているかを表示することができます。
それでも解決できない場合は、SPF 10のDNSルックアップ制限に対処するための一般的なソリューションに関するこちらの記事をご覧ください。また、お気軽にお問い合わせください。
私たちがお手伝いします
Brandkeeperでは、メールセキュリティの専門家チームによるDMARCの導入から運用サポート及びコンサルテーション行っています。一旦はDMARCの導入をやってみたが運用を断念したお客様、または、導入時点でいくつものハードルであきらめた企業様のサポートも行っています。
お気軽にご連絡ください
