Googleは2026年初頭、公式な発表なしに_netblocks3.google.comをSPFレコードチェーンから静かに削除しました。ほとんどのGoogle Workspaceユーザーにとっては何も変わりません。しかし、Googleの内部SPF構造を手動でハードコーディングしたドメイン所有者やITチームにとっては、配信可能性の問題が生じる前に今すぐレコードを監査する信号です。
Googleが実際に変更したこと
_spf.google.comリファレンスの内部を見ると、メール送信用のGoogleのIPレンジを含む内部サブレコードをポイントしています。以前は、このチェーンに3つのこれらのサブレコードが含まれていました。Googleは現在、_netblocks3.google.comをそのチェーンから静かに削除しました。つまり、そのサブレコードはアクティブな送信アドレスを保持していません。簡潔に言えば、GoogleはSPF構造をクリーンアップしました。
Googleがこれについて大きく発表しなかったのは、ほとんどのドメインで何も壊れないからです。問題が表面化するのは、Googleの内部構造を手動でコピーした場合のみで、SPFレコードが無効になったり、不要なリファレンスをポイントしたりする可能性があります。メール配信が即座に失敗することはありませんが、SPF設定の保守が難しくなります。
実際にリスクにさらされているのは誰か
ほとんどのGoogle Workspaceユーザーはこの変更について心配する必要がありません。標準のinclude:_spf.google.comエントリに依存しており、Googleはバックグラウンドで全てを管理しています。この形式のレコードは期待通りに機能し続けます。
Googleが推奨するインクルードを使用している人は問題に直面しません。しかし、Googleの内部構造を手動でコピーしたドメイン所有者は問題が発生する可能性があります。これは通常、技術チームが10個のDNS参照上限に達し、SPFフラットニングツールを使用する代わりに個別のネットブロック参照をハードコーディングしようとした場合に起こります。
その参照上限は軽い問題ではありません。RFC 7208によると、SPF評価はチェックあたり10個のDNS機構参照と2個のボイド参照に制限されています。どちらかの上限を超えるとPermErrorが発生し、ドメインからのすべてのメッセージの認証に失敗します。そしてその失敗は無音です。メールはバウンスしませんが、スパムに入るか、送信者が見られるような明確なエラーなしに拒否されます。
DNS参照予算の問題
この更新は、複数の送信ツールを使用しているビジネスにとってより広い問題を浮き彫りにしています。Googleのinclude:_spf.google.comだけで利用可能な10個の参照のうち4個を使用し、他のすべての送信者に6個しか残しません。SendGridも使用していて、5個の参照を消費する場合、合計は9個に達し、1つ送信者を追加するだけで上限に達してしまいます。
Google、Microsoft、SendGrid、Mailchimpを一緒にインクルードするドメインは12個の参照に達します。RFC 7208は評価を10個に制限しています。受信メールサーバーはPermErrorを返し、ドメインからのすべてのメッセージがSPF認証に失敗します。実際にどの送信者から来たメッセージかに関わらずです。
マーケティングプラットフォームを通じてキャンペーンを実行し、同時に第3のサービスからトランザクションメールを送信している成長チームにとって、これは実在し、一般的な落とし穴です。
SPFレコードで確認すること
_netblocks.google.com、_netblocks2.google.com、_netblocks3.google.comのような個別のネットブロック エントリが記載されているのを見かけたら、それらをすべて削除してください。すべてを_spf.google.comをポイントする1つのインクルードで置き換えてください。これにより、設定がクリーンに保たれ、Googleによって自動的に更新されます。
Google Workspaceのみを使用してメールを送信している場合、正しいレコードは次のとおりです。v=spf1 include:_spf.google.com ~all
数ヶ月ごとにSPF設定を確認して、古いエントリ、重複したリファレンス、または壊れたインクルードを検出することで、アライメントの問題と配信可能性の問題を防ぐのに役立ちます。
メールマーケティングのROIにとって重要な理由
SPFは単なる技術的な衛生タスクではありません。送信者の評判の基礎に位置しています。適切に設定されたGoogle Workspace SPFレコードがないと、ドメインを検証できない受信サーバーでメールがスパムとしてフラグされる可能性があります。ドメインまたはIPアドレスがブロックリストに登録される可能性があり、配信可能性の復旧は最初から認証を正しく設定するよりもはるかに難しくなります。ドメイン評判は、スパムの苦情が時間とともに増加するにつれて累積ダメージを受けます。
2023年10月に発表され、2024年2月から実施されたGoogleのバルク送信者要件では、1日あたり5,000件以上のGmailアドレス宛のメッセージを送信するドメインは、SPFとDKIMの両方で認証し、最低でもp=noneのDMARCレコードを発行し、スパム苦情率を0.3%未満に保ち、マーケティングメールに1クリックで配信解除できるヘッダーを含める必要があります。これらのルールはFromヘッダーのすべてのドメインに適用され、Googleは現在、非準拠のバルク送信者からのメッセージを拒否またはスパムにルーティングします。
これを間違えると、配信可能な到達範囲が直接削減され、より低い開封率、より低いクリックスルー率、送信するすべてのキャンペーンからの低いリターンを意味します。
今すぐ実行する3つのステップ
SPF単独では十分ではありません。DKIMとDMARCと組み合わせることで、受信サーバーはメッセージを正しく検証し、ドメインを使用したフィッシング試行をブロックできます。SPFルックアップチェッカー、DMARC分析ツール、またはメールセキュリティダッシュボードのようなツールは、変更を監視し、設定の問題を早期に検出するのに役立ちます。
この更新に対応するには:
- MXToolboxまたはGoogleの管理ツールボックスのようなツールを使用して、現在のSPFレコードを検索してください。
- レコードに
include:_spf.google.comのみが含まれている場合、変更は不要です。Googleが更新を管理します。 - 個別の
_netblocksエントリが表示される場合、それらを統合し、合計参照数が10未満のままであることを確認してください。
GoogleのSPFチェーンの静かなクリーンアップは、メール認証インフラストラクチャが警告なしに変更されることを思い出させます。手動で構築されたレコードに依存するドメインは、この問題に継続的に遭遇します。公式なインクルード参照を使用し、定期的に設定を確認することが、保護されたままでいるための簡潔な方法です。
