SPFレコードの役割
SPF（Sender Policy Framework）は、エンベロープFromアドレスにあなたのドメインを使ってメールを送ることを許可されたサーバーを列挙する、ドメイン上のTXTレコードです。GmailやOutlookはメッセージを受け取ると、このレコードを参照して接続元IPが含まれているかを確認します。通過すればDMARCに反映され、失敗やレコードの不在は、コールドメールが迷惑メールに入る最も一般的な理由のひとつです。
レコードは v=spf1 で始まる1行で、メカニズム（ip4、ip6、include、a、mx）が続き、all に付く修飾子で終わります。順序が重要で、メカニズムは左から右へ評価され、最初に一致したものが勝ちます。
v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -allDNSルックアップ10回の上限
RFC 7208 はSPFのDNSルックアップを10回までに制限しています。include、a、mx、ptr、exists、redirect のすべてがカウントされ、includeはそのレコードが参照するものまで引き込みます。Google Workspace だけでも複数のネストしたルックアップに展開されるため、Workspace に3つのSaaSツールを加えたドメインは、誰も気づかないうちに上限に達することがあります。10回を超えると受信側は permerror を返し、SPFは事実上どこでも失敗します。
- 今もメールを送信しているサービスだけを列挙しましょう。古いESPや試用したツールが元凶になりがちです。
- プロバイダーが安定したIPを公開している場合は、includeよりip4レンジを選びましょう。ip4はルックアップを消費しません。
- マーケティングやトランザクションの送信元は専用サブドメインに対応していることが多く、ルートのレコードを小さく保てます。
- 公開後はSPFチェッカーを使い、完全に展開した実際の回数を確認しましょう。
-all、~all、?all のどれを選ぶか
末尾の all メカニズムは、列挙しなかった送信元をどう扱うかを受信側に伝えます。-all（ハードフェイル）は拒否を指示します。~all（ソフトフェイル）は受け入れつつ疑わしいものとして扱うよう指示します。?all（中立）は何も言わないため、レコードがほぼ無意味になります。すべての送信元を自分で管理するコールドメール用ドメインでは -all が正解であり、DMARCに明確なSPFの結果を与えられます。
~all から始めるのは、引き継いだドメインで何が送信しているか分からない場合だけにしてください。DMARCの集約レポートを2週間ほど確認し、正当な送信元を追加してから -all に切り替えます。
レコードを正しく公開する
ドメインのルート（DNSプロバイダーによってホストは @ または空欄）にTXTレコードを1件作成します。すでに v=spf1 レコードがある場合は、追加ではなく編集してください。SPFレコードが2件あると恒久的なエラーになります。255文字を超えるレコードは複数の引用符付き文字列に分割する必要がありますが、たいていのDNS管理画面が自動的に処理します。
送信用のサブドメインには独自のSPFレコードが必要で、親ドメインのものを継承しません。反映は通常すぐですが、古いレコードのTTL分だけかかることがあります。InboxOne経由で送信用ドメインを購入した場合は、払い出し時にDKIMおよびDMARCとともにSPFも公開されます。
