MailData

SPF Void Lookup

SPFマクロを実装した際のVoid Lookupに関する注意

SPFマクロの適切な使い分けを

Sender Policy Framework (SPF) レコードは、電子メールの送信元を検証するためのDNSレコードの一種であり、フィッシング攻撃などから受信者を守る重要な役割を果たします。
SPFレコードは、ドメイン所有者が指定した送信元IPアドレスのリストを提供し、受信サーバーがメールの送信元を検証するために使用します。

最近では、MTAのIPリストの隠蔽化のために、SPFレコード内でのSPFマクロの使用が話題となっています。
この技術を導入する事で、動的にメール送信元の検証が行われる一方で、Void Lookupが発生し、SPFのPerm Errorが発生して、メールが届かなくなることがあります。

例えば、以下のように、自社のSPFのTXTレコードに、3つのSPFマクロを記載したとしましょう。

この設定により、受信MTAは送信MTAのIPアドレスを1つ目のSPFマクロで検証し、IPが存在しない場合にはNXDOMAINまたはNODATAが返されます。
次に、2つ目のSPFマクロで検証し、同様に存在しない場合は再びNXDOMAINまたはNODATAが返されます。
この時点で2回のVoid Lookupが発生し、permerrorが返され、3つ目のSPFマクロは評価されません。

SPFの仕様を規定したRFC7208の4.6.4. DNS Lookup Limitsでは、以下のように記述されています。

セクション11.1の最後で述べられているように、DNSクエリが肯定的な応答（RCODE 0）と応答数0を返す、または「名前エラー」（RCODE 3）応答を返す「用語」の数を制限することが有用な場合があります。
これらは総称して「void lookup」と呼ばれることがあります。 SPFの実装では、「void lookup」を2つに制限すべきです（SHOULD）。
実装では、そのような制限を設定可能にすることを選択してもよいです（MAY）。
この場合、デフォルトは2つにすることが推奨されます（RECOMMENDED）。
制限を超えると、「permerror」結果が生成されます。

対処方法

SPFマクロを使用する事業者に対して、include形式でのレコード提供を依頼するか、別のサービスプロバイダへの変更が考えられます。
include形式を使用すれば、void lookupの問題を回避し、より確実にメール配信を行うことができます。

サービス提供者は、ユーザ企業にとってSPFマクロの使用がlookup数の制限を超えるリスクをもたらすことを理解し、include形式での提供を検討することが望ましいです。
ユーザ企業も、この問題の存在を認識し、適切な対策を講じることが重要です。