SPFルックアップは、受信メールサーバーが、あなたのドメインとしてメールを送信することを許可したサーバーを把握するために実行するDNSクエリです。着信するすべてのメッセージで発生するので、同じルックアップを自分で実行する方法を知ることが、受信者が見ているものを確認する最速の方法です。このルックアップをSPFレコードチェッカーと組み合わせて、見つけたレコードを検証しましょう。
SPFルックアップの仕組み
あなたのSPFレコードは、ドメインの頂点（例：_spf.example.comではなくexample.com）にDNS TXTレコードとして公開されます。メッセージが届くと、受信者はエンベロープ送信者のドメインを読み取り、そのドメインのTXTレコードに問い合わせ、v=spf1で始まるものを見つけ、接続してきたサーバーのIPアドレスに照らして評価します。IPが許可されていればSPFは合格し、そうでなければレコードの修飾子が次に何が起きるかを決めます。
生のSPFレコードを読む
ルックアップは次のような1行を返します。
v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.0/24 -all
各トークンはメカニズムです。include:は別のプロバイダーの許可された送信者を取り込み、ip4:はアドレスまたは範囲を直接許可し、末尾の-allは一致しなかった相手を拒否するよう受信者に伝えます。a、mx、ip4、includeに関する当社のガイドが、それぞれを解説しています。ただし、生の文字列は全体像の半分にすぎません。本当の作業は、これらのincludeが何を含んでいるかを展開することです。
再帰的なincludeの展開とルックアップ数計測
すべてのinclude:は、それ自体が独自のSPFレコードを持つドメインであり、さらにincludeを含むことがあります。このツールはそのチェーンを最後まで追うので、3つのincludeに見えるレコードが、実際には十数個のDNSルックアップに解決されることがあります。それが重要なのは、RFC 7208が評価を10のDNS問い合わせメカニズム（加えて2つのvoidルックアップの上限）に制限しているからです。いずれかを超えると受信者はPermErrorを返します。展開したレコードが10を超えている場合、AutoSPFがincludeをコンパクトなレコードにフラット化し、最新の状態に保ちます。DNSルックアップが多すぎるをご覧ください。
SPFレコードを手動でルックアップする
基礎となるクエリは、ターミナルから自分で実行できます。macOSまたはLinuxの場合：
dig TXT example.com +short
Windowsの場合：
nslookup -type=TXT example.com
どちらもSPF行を含む生のTXTレコードを返しますが、ネストしたincludeを展開したり合計ルックアップを数えたりはしません。だからこそ、簡単な確認を超える作業には、専用のルックアップツールの方が速いのです。
ルックアップが何も返さない（または失敗する）とき
- レコードが見つからない。 ドメインが
v=spf1TXTレコードを公開していないため、受信者は送信者を照合する対象がありません。 - レコードが2つ見つかる。 RFC 7208は1つしか許可していません。2つ目はPermErrorを生じさせ、両方が無視されます。単一のエントリにSPFレコードを統合して修正します。
- サブドメインにレコードがない。 サブドメインは親のSPFレコードを継承しません。メールを送信する各サブドメインには独自のレコードが必要です。
- カウントでのPermError。 構文は有効ですが、展開したルックアップが10を超えています。
ルックアップの後：検証し、修正し、DKIMとDMARCをカバーする
レコードを手に入れたら、SPFバリデーターにかけてすべてのRFCルールに照らしてチェックするか、SPFレコードジェネレーターでクリーンに再構築します。そして、SPFは送信サーバーしかカバーしないので、無料のDMARCチェッカーとDKIMルックアップと組み合わせましょう。DMARCこそが、SPFとDKIMをあなたの可視のFromアドレスに結び付けるものです。送信者を追加したとき、プロバイダーを移行したとき、メールが迷惑メールに振り分けられているのを見たときは、いつでもレコードをルックアップしてください。