
SPFマクロを実装した際のVoid Lookupに関する注意
SPFマクロの適切な使い分けを
Sender Policy Framework (SPF) レコードは、電子メールの送信元を検証するためのDNSレコードの一種であり、フィッシング攻撃などから受信者を守る重要な役割を果たします。
SPFレコードは、ドメイン所有者が指定した送信元IPアドレスのリストを提供し、受信サーバーがメールの送信元を検証するために使用します。
最近では、MTAのIPリストの隠蔽化のために、SPFレコード内でのSPFマクロの使用が話題となっています。
この技術を導入する事で、動的にメール送信元の検証が行われる一方で、Void Lookupが発生し、SPFのPerm Errorが発生して、メールが届かなくなることがあります。
例えば、以下のように、自社のSPFのTXTレコードに、3つのSPFマクロを記載したとしましょう。
- 1つめのSPFマクロ exists: %{i}.spf.maildeliverservice.com
- 2つめのSPFマクロ exists: %{i}.spf.marketingautomation.com
- 3つめのSPFマクロ exists: %{i}.spf.transactionmail.com
この設定により、受信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形式でのSPFレコード提供を依頼する
- SPFマクロを利用している事業者から配信されるメールについては、サブドメインを用いた送信元アドレスへ変更する
- 別のサービスプロバイダへの移行も検討する
サービス提供者は、SPFマクロの使用がユーザ企業のlookup数制限を超過するリスクを伴うことを十分に理解し、include形式での提供を検討することが望ましいです。
また、サービス提供者側でIPアドレスが分散している場合は、AS番号の取得やIPレンジの集約によって効率化を図ることも重要です。
ユーザ企業も、このリスクを認識したうえで、適切な対策を講じる必要があります。