グローバルSPF検証チェッカー
Sender Policy Framework (SPF) は、許可された送信元IPアドレスの暗号化ホワイトリストを公開することで、ドメインのなりすまし (Spoofing) を防ぐ重要なメール認証プロトコルです。SPFプロトコル自体は最新のメール到達率 (Deliverability) に不可欠ですが、専用のSPF DNSレコードタイプ (Type 99) は信じられないほど混乱した歴史を持ち、公式に廃止 (Deprecated) されています。
レコード Type 99 の興亡
SPFプロトコルが最初に構想されたとき (RFC 4408)、IETFはSPFペイロードを標準のTXTデータから明示的に分離するように設計された特定のDNSリソースレコード (Type 99) を設計しました。専用のレコードタイプを維持することで、リゾルバの解析 (Parsing) が高速化されるという理論でした。しかし、このロールアウトは大失敗に終わりました。レガシーなDNSサーバー、ファイアウォール、およびハードウェアロードバランサーは新しいType 99の構文を認識せず、頻繁にパケットを破棄して広範なメール障害を引き起こしました。このハードウェアの非互換性を認識したIETFはRFC 7208を発行し、Type 99レコードを正式に廃止しました。現在、すべてのSPF構成は標準のTXTレコードとして公開する必要があります。管理者が引き続きレガシーなType 99 SPFレコードをデプロイした場合、Microsoft ExchangeやGoogle Workspaceのような最新のプラットフォームはそれを完全に無視し、即座にDMARCの失敗を引き起こします。
機械的な10回のルックアップ制限
SPFを管理する開発者にとって最も顕著な技術的障害点は、厳格な10ルックアップのしきい値です。SPFレコードでは、管理者が include: ディレクティブ (例: include:_spf.salesforce.com) を使用して他のドメインポリシーをネストできるため、受信側のメールサーバーは再帰的なDNSクエリを実行してサードパーティのプロバイダーからIPを取得する必要があります。MTAを無限ルーティングループや標的型DDoS増幅攻撃から保護するため、プロトコルは実行を10回の再帰的DNSルックアップにハードキャップしています。企業がSaaSプロバイダーをチェーンしすぎて11回のルックアップに達した場合、実行は停止し、SPFの「PermError」が返されます。これにより、正当な送信メールが即座にハードバウンスするか、検疫 (Quarantine) に落とされます。
Flattening (フラット化) と診断
ルックアップの制限を回避するため、ネットワークエンジニアは「SPF Flattening」ツールを利用します。これらのスクリプトは1時間ごとに実行され、APIを介してすべての include: ディレクティブを展開し、ホスト名を取り除き、生のIPv4/IPv6ブロックを大規模な単一のフラットなTXTレコードにコンパイルします。グローバルな診断チェッカーを使用することで、構文が有効であること、ネストされたincludeが暗黙のうちにDNSのしきい値を超えていないこと、およびポリシーがなりすましペイロードを拒否するための制限的な -all (Fail) または ~all (Softfail) フラグで明示的に終了していることを確認できます。