MailData

SPF Void Lookup

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

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マクロの使用がユーザ企業のlookup数制限を超過するリスクを伴うことを十分に理解し、include形式での提供を検討することが望ましいです。
また、サービス提供者側でIPアドレスが分散している場合は、AS番号の取得やIPレンジの集約によって効率化を図ることも重要です。
ユーザ企業も、このリスクを認識したうえで、適切な対策を講じる必要があります。