SPFレコードが実際に行うこと
SPF（Sender Policy Framework）は、エンベロープ送信者としてあなたのドメインを使ってメールを送ることを許可されたサーバーを列挙する、ドメインルートのTXTレコードです。GmailやMicrosoftはメッセージを受け取ると、このレコードを参照し、接続元IPを各メカニズムと順番に照合して、最初に一致した時点で評価を止めます。
結果は pass、fail、softfail、neutral のいずれかです。SPF単体でメールがブロックされることはまれですが、DMARCはSPFかDKIMのいずれかが通過し、Fromドメインとアラインしていることを必要とします。コールドメールにおいてSPFレコードが壊れているということは、DMARCがDKIM単独に頼ることを意味し、そちらも設定を誤っていればキャンペーンは迷惑メールに入ります。
v=spf1 include:_spf.google.com ~allDNSルックアップ10回の上限と、レコードが壊れる仕組み
RFC 7208 は、ネストしたincludeも含めたレコード全体で、DNSを照会する項の数を最大10回に制限しています。カウントされる項は include、a、mx、ptr、exists、redirect です。カウントされないのは ip4、ip6、all です。上限を超えると受信側は permerror を返し、ほとんどはこれをハードフェイルとして扱います。
厄介なのは、includeが自身のルックアップを隠し持っている点です。大手プロバイダーのinclude1つだけで4〜5回を消費することもあります。CRM、ヘルプデスク、マーケティングプラットフォーム、そして2つの送信ツールを継ぎ足していく代理店は、気づかないうちに12回や13回に達しがちです。
- このドメインから送信しなくなったツールのincludeは削除しましょう。
- マーケティングメールやトランザクションメールには別のサブドメインを使い、各SPFレコードを小さく保ちましょう。
- プロバイダーの静的includeをip4レンジに置き換えるのは、自分で保守し続ける覚悟がある場合だけにしましょう。
- v=spf1 レコードを2つ公開しては絶対にいけません。ひとつに統合してください。
コールドメールでは ~all と -all のどちらを選ぶべきか
末尾の all 項は、記載のないサーバーに対するポリシーを決めます。-all はハードフェイル、~all はソフトフェイルです。どちらもGmailとMicrosoftに受け入れられ、どちらもDMARCが機能する余地を残します。はるかに重要なのは、正当な送信元がすべて all 項の前に列挙されていること、そして +all と ?all を完全に避けることです。
Google Workspace や Microsoft 365 経由で送るアウトリーチ用ドメインでは、ツールを追加している最中は ~all が安全な初期設定です。送信元の一覧が固まったら -all へ移行してください。InboxOneはメールボックスの払い出し時に、適切なincludeを含む正しいSPFレコードを自動で公開するため、新しいドメインはきれいな状態から始まります。
このチェッカーが検出する、よくあるSPFのミス
SPFの失敗のほとんどは特殊なものではありません。コピー＆ペーストのミス、残ったままのinclude、プロバイダー移行後に更新されていないレコードから生じます。チェッカーはこれらを個別に指摘し、具体的な修正方法を示します。
- v=spf1 レコードの重複。即座に permerror を引き起こします。
- all より後ろに置かれた項。黙って無視されます。
- 非推奨の ptr メカニズム。一部の受信側は完全にスキップします。
- includeがSPFレコードのないドメインを指す、無効なルックアップ。
- 255文字を超えるTXT文字列や、切り詰めのリスクがあるレコード全長。
- includes: や ip4= のようなタイプミスによる不明なトークン（正しくは ip4:）。
