Gmail SPF 记录：2026 年分步指南

您通过 Gmail 发送客户更新、招聘邮件或销售序列。文案很扎实。列表很干净。但回复速度却慢如蜗牛，或者更糟糕的是，有人告诉您邮件进入了垃圾邮件文件夹。

在小型团队中，这通常会让人们首先检查主题行、模板和发送量。这很合理。但最常见的原因之一位于 Gmail 之外，即您的 DNS 设置中。您的 SPF 记录决定了接收邮件服务器是否将 Gmail 视为您域名的批准发件人。

如果您正在研究基于 Gmail 的外联工具，这一点就更加重要。请对听起来通用的产品名称保持谨慎，尤其是 Mail Merge for Gmail。该短语既描述了一个类别，也描述了一个特定的产品，因此很容易将针对其他邮件合并工具的设置建议应用到错误的系统中。

为什么您的 Gmail SPF 记录很重要

将 SPF 视为您域名的访客名单是一个有用的思路。当您的电子邮件到达另一台邮件服务器时，该服务器会检查发件人是否在名单上。如果 Gmail 在名单上，您的邮件被视为合法邮件的机会就会大得多。如果 Gmail 不在名单上，接收方在收件人阅读主题行之前就有理由不信任该邮件。

这种信任问题出现在普通的商业环境中。创始人发送入职邮件。人力资源经理发送面试邀请。学校向家长发送活动更新。在 Gmail 内部一切看起来都很正常，但接收服务器看不到对您域名的明确授权，并开始更谨慎地处理这些邮件。

一名沮丧的女性看着电脑屏幕，上面显示着邮件投递失败的通知。

SPF 的保护内容

SPF 同时执行两项工作：

投递保护： 它帮助接收服务器识别 Google 被允许代表您的域名发送邮件。
品牌保护： 它使其他人更难在出站电子邮件中伪造您的域名。

SPF 告诉外界哪些发送系统代表您的域名发言，哪些不代表。

如果您正在尝试提高电子邮件营销的成功率，这是最值得做的首要技术检查之一。更好的文案无法弥补未经正确验证的域名。

为什么小错误会导致巨大的痛苦

令人沮丧的是，SPF 问题看起来往往不像 SPF 问题。邮件可能仍然可以发送。一些收件人可能仍然能收到它们。其他人可能会看到垃圾邮件位置、警告或静默过滤。这种不一致性让人们感到困惑。

如果您的电子邮件已经漂移到垃圾文件夹中，那么将此设置指南与关于如何防止电子邮件进入垃圾邮件的实用演练结合起来是值得的。SPF 并不是送达率的全部，但它是少数几个直接在域名级别提高信任度，而不是仅仅调整内容并祈祷好运的修复方法之一。

创建您的核心 Gmail SPF 记录

如果您的域名仅通过 Gmail 或 Google Workspace 发送电子邮件，设置非常简单。Google 的官方 SPF 记录是在 Google Workspace 管理员帮助中记录的确切字符串：

v=spf1 include:_spf.google.com ~all

一个五步信息图，展示了如何在 DNS 设置中设置 Gmail SPF 记录。

该值必须作为单个 TXT 记录发布在您的域名根目录下。在大多数 DNS 面板中，主机名为 @。根据同一份 Google Workspace 文档，Google 还建议 TTL 为 3600 秒（1 小时），并且根据您的提供商，DNS 更改可能需要长达 48 小时才能完全传播。

在 DNS 中输入什么

无论您的 DNS 是在 GoDaddy、Cloudflare、Namecheap 还是其他提供商中管理，字段通常如下映射：

类型： TXT
主机或名称： @
值或内容： 上面的 SPF 字符串
TTL： 如果您的提供商允许您手动设置，则为 3600

这里最常见的错误是过度考虑记录类型。许多 DNS 面板不再提供单独的 SPF 记录类型。这是正常的。您需要的是 TXT 记录。

如果您是第一次编辑 DNS，快速的视觉演练可能会有所帮助：

什么有效，什么无效

这是实用版本。

有效： 在域名根目录下添加一个 TXT 记录，其中包含确切的 Gmail SPF 值。
无效： 添加多余的空格、将值拆分为单独的 SPF 记录，或者在错误的主机（例如子域名）下发布它，而您的邮件是从主域名发送的。

实用规则： 准确复制 SPF 值，发布一次，并在以后添加其他发件人时抵制创建第二个 SPF 记录的冲动。

如果您处于简单的仅 Gmail 环境中，这通常足以正确完成您的基础 SPF 记录 Gmail 设置。保存记录，等待传播，并在更改任何其他内容之前进行验证。

处理多个电子邮件发件人和邮件合并

常见的小型企业设置如下所示。员工通过 Google Workspace 发送常规邮件，营销部门通过邮件合并工具开展活动，CRM 或帮助台通过同一域名发送自动消息。SPF 必须覆盖所有这些系统，否则其中一个系统就会开始验证失败。

这就是许多 Gmail SPF 设置崩溃的地方。基础 Google 记录很容易。当每个新工具要求您添加另一个 include: 条目，且没有人检查这些添加对完整记录的影响时，复杂性就开始了。

最重要的两条规则

规则一：为域名发布一个 SPF TXT 记录。

规则二：将完整的 SPF 评估保持在 10 次 DNS 查询以内。该限制包括每个 include: 中的嵌套查询。一条记录在您的 DNS 面板中看起来可能很短，但仍然会失败，因为一个供应商的 SPF 记录会扩展为更多的检查。来自 DMARC Report 的这份分析解释了为什么查询计数在 Gmail SPF 配置中很重要。

多发件人环境达到该限制的速度比人们预期的要快。Google Workspace 加上邮件合并发件人、CRM 和支持平台，即使每个供应商的说明在技术上都是正确的，也可能让您陷入困境。错误在于将每个发件人视为一个单独的 DNS 项目，而不是一个统一的授权策略。

正确的合并是什么样的

如果 Gmail 和另一个批准的服务都为您的域名发送邮件，请将两个发件人添加到同一个 SPF 记录中。

场景	正确的合并 SPF 记录
仅 Gmail	`v=spf1 include:_spf.google.com ~all`
Gmail 加一个第三方发件人	`v=spf1 include:_spf.google.com include:spf.thirdparty.com ~all`
Gmail 加多个发件人	`v=spf1 include:_spf.google.com include:spf.vendorone.com include:spf.vendortwo.com ~all`

这些示例展示了结构。您实际的第三方值必须来自每个提供商的文档。实用点没有改变。一个域名对应一个 SPF 记录。

现实生活中通常会出什么问题

我通常看到三种失败模式。

发布了第二个 SPF 记录。 有人添加了一个以 v=spf1 开头的新 TXT 条目，而不是编辑现有的条目。
旧服务被永久授权。 企业停止使用某个工具，但其 include: 仍然保留在 DNS 中并继续消耗查询次数。
邮件合并被视为“仅仅是 Gmail”。 一些工具通过 Google 的基础设施发送，而另一些工具通过它们自己的服务器或连接的提供商发送。这种差异改变了 SPF 是否需要另一个 include。

第三点经常被忽略。如果您的团队使用基于 Sheets 的工作流程，请在接触 DNS 之前确认该工具如何发送邮件。关于从 Google Sheets 进行邮件合并的指南可以帮助您映射工作流程，但 SPF 仍然取决于该工作流程背后的发送基础设施。

如何保持在 10 次查询限制内

从发件人清单开始。列出所有被允许以您的域名发送邮件的系统。包括营销平台、CRM、支持工具、发票应用程序、网站表单和任何邮件合并产品。

然后进行精简。

删除您不再使用的发件人。检查两个工具是否通过同一个提供商发送，这可能会使一个 include 变得多余。如果供应商提供多个 SPF 选项，请选择他们为您的情况记录的选项，而不是粘贴您能找到的每一条记录。

如果记录仍然太大，答案不是第二个 SPF 记录。答案是减少授权发送路径的数量，或者在某些情况下使用子域名进行单独的邮件流，以便主域名 SPF 记录保持可管理。

如果您添加了新发件人，请将其视为 DNS 更改审查。在保存之前，确认该发件人仍然需要，更新单个 SPF 记录，并检查查询计数。

如何验证您的 SPF 记录是否有效

保存记录后，不要以为就完成了。验证是您发现隐蔽错误的地方，特别是如果您的 DNS 面板接受了条目，但语法或查询计数仍然错误。

首先使用验证器

从公共 SPF 检查器（例如 MxToolbox 或 dmarcian SPF Surveyor）开始。这些工具很有用，因为它们不仅确认 TXT 记录是否存在。它们还会检查结构，并且在更高级的查询情况下，帮助您查看您的 includes 是否创建了过多的 DNS 查询。

输入您的域名并仔细查看结果。您需要寻找三件事：

找到记录： 工具可以在公共 DNS 中看到您的 SPF TXT 记录。
语法有效： 没有格式错误的机制、多余的空格或重复的 SPF 条目。
链条可管理： includes 不会扩展为损坏的结果。

好的结果是什么样的

健康的检查通常看起来很无聊，而这正是您想要的。工具找到一个 SPF 记录，干净地解析它，并且不会标记永久错误。

失败的结果通常属于以下几类之一：

未找到 SPF 记录： 记录尚未传播、保存在错误的主机下或从未发布。
找到多个 SPF 记录： 您添加了第二个 v=spf1 TXT 记录，而不是编辑现有的记录。
查询次数过多： 您的合并发件人列表太大或嵌套太多。

也检查一封实时邮件

验证器对结构很有用。真实的邮件可以确认行为。

发送一封测试邮件到您可以访问的 Gmail 收件箱。打开邮件，使用 Gmail 查看原始邮件来源的选项，并检查身份验证结果。如果 SPF 通过，这是一个强烈的信号，表明您的公共 DNS 和您的实际发送路径是一致的。

验证工具告诉您 DNS 记录是否可发布。实时测试告诉您您的实际邮件流是否符合 DNS 策略。

如果验证器通过但实时邮件仍然表现异常，问题可能出在您的身份验证堆栈的其他地方，而不仅仅是 SPF。

故障排除常见的 SPF 记录错误

SPF 问题通常在更改后立即变得明显。一家小型企业开始从 Google Workspace 发送提案，添加了一个邮件合并工具，然后注意到回复变慢或邮件进入垃圾邮件。实际上，问题通常是一个 DNS 错误，而不是复杂的邮件问题。

一张信息图，详细说明了常见的 SPF 记录错误及其针对电子邮件身份验证配置的相应解决方案。

找到多个 SPF 记录

症状： 您的验证器报告多个 SPF 记录，或者接收服务器返回永久的 SPF 错误。

原因： 您的域名有多个以 v=spf1 开头的 TXT 记录。我在企业添加第二个发件人（如 CRM 或外联平台）后看到了这一点，并且严格遵循了新供应商的设置指南。SPF 不会合并这些记录。接收方看到冲突并将其视为无效。

解决方案： 为域名保留一个 SPF 记录，并将每个批准的发件人折叠到该单个 TXT 条目中。如果您已经有了单独的记录，请选择一个作为主记录，合并所需的机制，然后删除多余的记录。

DNS 查询过多

症状： 记录看起来很完整，但 SPF 仍然因查询限制或 permerror 结果而失败。

原因： SPF 检查只能跟踪有限数量的 DNS 查询。这是基础 Gmail SPF 指南经常跳过的错误。它出现在 Google Workspace 只是多个发件人之一的真实环境中，特别是如果您还使用邮件合并软件、帮助台、计费系统和来自同一域名的营销平台。每个 include: 都会在它下面引入更多的 includes，因此看起来很短的记录仍然可能超过限制。

解决方案： 在尝试任何巧妙的方法之前，先精简发件人列表。删除不再为您域名发送邮件的服务。询问每个供应商您的用例是否确实需要他们发布的所有 includes。如果您的堆栈仍然太大，请按子域名拆分邮件流。例如，将常规员工邮件保留在您的主域名上，并将外联或群发邮件移动到具有自己 SPF 策略的子域名。这种方法通常是多发件人设置中最干净的修复方法，因为它减少了查询压力，并防止了一个臃肿的记录破坏其他所有内容。

语法问题和记录丢失

症状： 记录存在于 DNS 中，但验证器标记了格式错误，或者根本找不到 SPF 记录。

原因： 这通常来自错误的粘贴、错误的主机值或在错误的字段中发布 SPF 字符串。在 cPanel、GoDaddy、Cloudflare 和 Google Domains 替代品中，标签的区别足以让首次管理员感到困惑。用于根域名的记录可能会被输入到 www 下，或者 TXT 值可能被错误地拆分。

解决方案： 将发布的 TXT 值与预期的记录逐字符进行比较。确认主机对于您正在验证的域名是正确的，并确保您创建的是 TXT 记录，而不是其他记录类型。如果语法没问题但邮件仍然失败，请查看更广泛的自定义域名的电子邮件身份验证设置，因为 SPF 记录可能是有效的，而另一个身份验证控制正在导致问题。

实用的故障排除顺序

当 SPF 损坏时，请使用此顺序：

检查是否有重复的 SPF 记录。 这是最快确认和修复的问题。
仔细审查记录文本。 查找拼写错误、缺失的空格、多余的引号或错误的主机。
映射每个发送服务。 包括 Google Workspace、邮件合并工具、CRM、支持平台以及任何其他以您的域名发送邮件的服务。
计算查询密集型的 includes。 如果列表很拥挤，请简化它或将一些发件人移动到子域名。

这个顺序可以节省时间，因为它与 SPF 在现场通常失败的方式相匹配。小型团队通常认为最新的工具导致了问题，但旧的 DNS 混乱同样常见。如果您在清理此内容时需要更广泛的操作清单，Simply Tech Today 的电子邮件安全指南是一个有用的参考。

超越 SPF：您的电子邮件身份验证后续步骤

小型企业可以发布正确的 SPF 记录，但一旦发票、外联和跟进开始从不同系统发出，仍然会看着邮件进入垃圾邮件。这通常发生在混合设置中，特别是当 Google Workspace 处理日常邮件，而另一个工具从同一域名发送活动或邮件合并时。

SPF 只涵盖了接收邮件服务器所做决定的一部分。它检查发送服务器是否被允许使用您的域名。这很重要，但它不能证明邮件已正确签名，也不能告诉接收服务器在身份验证失败时该怎么做。

这就是 DKIM 和 DMARC 的用武之地，它们在多发件人环境中更为重要。

DKIM 为邮件添加加密签名，以便接收服务器可以确认邮件是合法的，并且在离开您的系统后没有被篡改。DMARC 位于 SPF 和 DKIM 之上，并告诉邮箱提供商如何为您的域名评估这些检查。它还为您提供报告，这通常是您忘记正在使用您域名的发件人的第一个清晰视图。

这是许多基础 SPF 指南忽略的一点。如果您使用 Google Workspace、邮件合并工具、CRM 和支持平台，由于 10 次查询限制，SPF 可能会变得难以维护。DKIM 有助于减少您对 SPF 的单一依赖，而 DMARC 为您提供了一个策略层，这样您的域名就不会仅仅被一个拥挤的 TXT 记录所评判。

关于 SPF 之后的下一个技术步骤，请查看这份自定义域名的电子邮件身份验证指南。它为您提供了在 SPF 记录到位后设置 DKIM 和 DMARC 的实用路径。

如果您需要更广泛的操作清单，Simply Tech Today 的电子邮件安全指南是一本有用的配套读物。

实用的要点很简单。SPF 落实了权限。DKIM 证明了邮件完整性。DMARC 为您提供了控制权、可见性，以及管理从多个系统发送邮件的域名的更安全方式。