Google 在 2026 年初悄然从其 _spf.google.com 引用中移除了 _netblocks3.google.com，没有发布任何官方公告。对于大多数 Google Workspace 用户来说，一切照常运作。但对于手动硬编码了 Google 内部 SPF 结构的域名所有者或 IT 团队，现在必须审计他们的记录，以免配置混乱引发投递问题。
Google 实际改变了什么
当你查看 Google 的 _spf.google.com 引用时，它指向包含 Google 发送邮件 IP 段的内部子记录。之前，该链包含三个这样的子记录。Google 现在悄然从该链中移除了 _netblocks3.google.com，这意味着该子记录不再包含活跃的发送地址。简单来说，Google 清理了其 SPF 结构。
Google 没有大张旗鼓地宣布这一点，因为对大多数域名而言，不会产生问题。只有当你手动复制了 Google 的内部结构时才会出现问题，这可能导致你的 SPF 记录无效或指向不必要的引用。虽然不会立即破坏邮件投递，但会让你的 SPF 设置更难维护。
谁真正处于风险中
大多数 Google Workspace 用户无需担心这一变化。他们依赖标准的 include:_spf.google.com 条目，Google 在后台管理所有内容。采用这种格式的记录将继续正常工作。
使用 Google 推荐的 include 方式的用户不会遇到任何问题。但手动复制了 Google 内部结构的域名所有者可能会遇到麻烦。这通常发生在技术团队触及 10 次 DNS 查询限制，试图通过硬编码单个网段引用而不是使用 SPF 扁平化工具来解决问题时。
该查询限制并非小问题。根据 RFC 7208，SPF 评估限制为每次检查最多 10 次 DNS 机制查询和 2 次空查询。超过任一限制都会产生 PermError，导致来自该域名的每条消息都无法通过身份验证。而且这种失败是无声的：你的邮件不会退回，只是落入垃圾箱或被拒绝，发送方看不到任何明确的错误信息。
DNS 查询预算问题
这次更新还突出了使用多个发送工具的企业面临的更广泛问题。Google 的 include:_spf.google.com 单独就消耗了你 10 次可用查询中的 4 次，只剩 6 次供其他发送方使用。如果你还使用消耗 5 次查询的 SendGrid，总数将达到 9 次，再添加任何一个发送方就会触及上限。
同时包含 Google、Microsoft、SendGrid 和 Mailchimp 的域名会产生 12 次查询。RFC 7208 限制评估不超过 10 次。接收邮件服务器返回 PermError，来自该域名的每条消息都无法通过 SPF 身份验证，无论它实际来自哪个发送方。
对于通过营销平台运行活动的同时还从第三方服务发送交易邮件的增长团队来说，这是一个真实且常见的陷阱。
检查你的 SPF 记录
如果你在记录中看到 _netblocks.google.com、_netblocks2.google.com 或 _netblocks3.google.com 这样的单个网段条目，请删除它们。将所有这些条目替换为指向 _spf.google.com 的单个 include，这样可以保持配置简洁且由 Google 自动更新。
如果你仅使用 Google Workspace 发送邮件，正确的记录应该是：v=spf1 include:_spf.google.com ~all
每几个月检查一次你的 SPF 设置以发现过时条目、重复引用或损坏的 include，有助于防止对齐问题和投递问题。
为什么这对邮件营销 ROI 很重要
SPF 不仅是技术卫生任务。它是你发送者声誉的基础。如果 Google Workspace SPF 记录配置不当，你的邮件可能会被无法验证你的域名的接收服务器标记为垃圾邮件。你的域名或 IP 地址可能被加入黑名单，使投递恢复比首次正确设置身份验证要困难得多。随着垃圾邮件投诉不断增加，你的域名声誉会持续受损。
Google 在 2023 年 10 月宣布、从 2024 年 2 月开始执行的批量发送者要求规定，任何每天向 Gmail 地址发送 5000 封或更多邮件的域名必须使用 SPF 和 DKIM 进行身份验证，发布至少 p=none 的 DMARC 记录，将垃圾邮件投诉率控制在 0.3% 以下，并在营销邮件上包含一键取消订阅标题。这些规则适用于 From 标题中的每个域名，Google 现在会拒绝或将来自不符合要求的批量发送者的任何消息路由到垃圾邮件。
处理不当会直接降低你的可投递范围，进而导致打开率、点击率和每次活动的投资回报率下降。
现在要采取的三个步骤
仅凭 SPF 还不够。将其与 DKIM 和 DMARC 结合使用可以让接收服务器能够正确验证邮件并阻止使用你的域名的钓鱼企图。SPF 查询检查器、DMARC 分析器或邮件安全仪表板等工具可帮助你监控变化并尽早发现配置问题。
要对此更新采取行动：
- 使用 MXToolbox 或 Google 的管理工具箱 等工具查询你当前的 SPF 记录。
- 如果你的记录仅包含
include:_spf.google.com，无需进行任何更改。Google 会为你管理更新。 - 如果你看到任何单个
_netblocks条目，请整合它们并验证你的总查询数保持在 10 以下。
Google 对其 SPF 链的悄然清理提醒我们，邮件身份验证基础设施会在没有预警的情况下发生变化。依赖手动构建记录的域名将继续遇到这个问题。使用官方 include 引用并定期审查你的设置是保持安全的简单方法。
