2026 年 GoDaddy SPF 记录设置指南

您已经在 GoDaddy 中添加了记录，上一次营销活动也已经发出，但 Gmail 仍然将您一半的邮件视为来自陌生人。随后，有人添加了 CRM、时事通讯工具和交易平台，整个设置开始变得像一堆杂乱的电线。这通常就是 GoDaddy SPF 记录不再仅仅是一个复选框，而成为维持您邮件送达率的关键所在。

令人痛苦的是，SPF 失败很少会明确地提示您。添加了一个发件人，DNS 被编辑了一次，几周后团队就发现邮件进入了垃圾箱、出现了身份验证错误，或者一个平台正常工作而另一个平台却从列表中消失了。如果这听起来很熟悉，那么您处理的不仅仅是“电子邮件问题”，而是 DNS 所有权、记录结构和 10 次查询上限的问题。

为什么您的 GoDaddy SPF 记录比您想象的更重要

SPF 的概念很简单，但实践起来却很残酷。接收服务器会检查 DNS 中发布的域名策略，然后询问该发送服务器是否被允许代表该域名发送邮件。如果答案不匹配，即使发件人是合法的，邮件也可能被视为未经授权。

这就是为什么损坏的 GoDaddy SPF 记录造成的伤害比许多人意识到的要大。Microsoft 365 和 Google Workspace 都依赖于邮箱提供商在后台评估的身份验证信号，因此缺失或格式错误的 SPF 记录可能会在任何人注意到明显的失败之前就影响收件箱的送达。硬失败 (hardfail) 和 软失败 (softfail) 之间的区别在这里很重要，因为结尾的限定符告诉接收者，未经授权的邮件是应该被直接拒绝还是被视为可疑。

大多数团队忽略的部分

SPF 不仅仅是说“这个域名是你的吗”。它说的是“这个发件人是否在 DNS 中发布的批准列表中”。这也是 SPF 对齐 (SPF alignment) 开始变得重要的地方，因为 DMARC 随后会检查可见的“发件人 (From)”域名是否与经过身份验证的源对齐。

实用规则： 如果在原始 SPF 记录构建后将发件人添加到堆栈中，除非 DNS 记录也进行了修订，否则该发件人很可能已经成为问题所在。

GoDaddy 自己的指南反映了现代方法，即 SPF 作为 TXT 记录而不是单独的 SPF 类型记录发布，并且工作流程集中在域名组合内的 DNS 编辑上。这种设置听起来很普通，但这正是 SPF 经常损坏的原因。该记录很容易添加一次，而在批准下一个工具后却很容易被遗忘。

在 GoDaddy DNS 中添加您的第一个 SPF 记录

从 域名组合 (Domain Portfolio) 开始，打开 DNS，并将记录添加为 TXT。GoDaddy 自己的帮助文档展示了此 SPF 设置路径，将 SPF 策略输入到 值 (Value) 字段中，当策略应用于整个域名时，主机设置为根目录，而在相关邮件记录的记录示例中，TTL 保持为 默认 (Default) GoDaddy 的 SPF 记录帮助 GoDaddy 用于电子邮件身份验证的 DNS 记录字段。

来自 https://dns.godaddy.com 的截图

重要的字段

类型 (Type) 应为 TXT，而不是 SPF。GoDaddy 的文档使用 TXT，因为这是现代 DNS 中 SPF 的标准发布格式，这种选择避免了验证器之间的歧义。

名称 (Name) 对于根域名策略通常应为 @。这告诉 GoDaddy 该记录属于域名顶部，而不是子域名。值 (Value) 是 SPF 字符串所在的位置，因此您可以在此处粘贴策略本身。

如果您遵循 GoDaddy 的记录设置，特别是当您不在进行故障排除时，TTL 可以保持在 默认 (Default)。确切的字段名称很容易被忽略，但它们决定了记录是位于域名根目录还是位于某个无用的位置。

一个简单的 GoDaddy 管理的邮件示例如 v=spf1 include:secureserver.net -all，这是 GoDaddy 为托管电子邮件显示的格式。如果您只授权一个发件人源，这就是您想要的形状：一条记录，一个策略，一个位置。

对于 Gmail 特定的变体，这篇 Gmail 用户 SPF 指南展示了相同的“TXT 优先”逻辑在实践中的应用。

如果您将记录类型键入为 TXT 以外的内容，或者当策略需要位于根目录时将主机留空，则该记录可能在 UI 中存在，但在 DNS 层仍然会失败。

在流程的后期，GoDaddy 自己的界面变得不如权威 DNS 区域重要，但第一个胜利是将记录输入到正确的字段中，使用正确的类型，并位于正确的主机上。

您所使用的发件人的 SPF 语法

许多组织不只运行一个发件人。他们运行主邮箱、营销平台、CRM 和交易系统。SPF 记录是授权所有这些发件人的单一声明，因此实际工作是选择正确的机制，并保持列表足够短，以便在 GoDaddy DNS 开始对您产生负面影响之前进行验证。

适用于常见发件人堆栈的即用型 SPF 字符串

发件人设置	SPF 值	已使用的查询
Google Workspace	`v=spf1 include:_spf.google.com -all`	一个 include，然后是最终策略检查
Microsoft 365	`v=spf1 include:spf.protection.outlook.com -all`	一个 include，然后是最终策略检查
Google Workspace 加营销工具	`v=spf1 include:_spf.google.com include:servers.mcsv.net -all`	两个 include，加上包含记录内的任何嵌套查询
Microsoft 365 加交易发件人	`v=spf1 include:spf.protection.outlook.com include:amazonses.com -all`	两个 include，加上包含记录内的任何嵌套查询

这些字符串很有用，因为它们展示了模式：一条记录，一个策略，一个控制位置。如果您的堆栈以 Google Workspace 或 Microsoft 365 开头，然后发展到营销和交易邮件，那么记录通常不再是关于语法，而是关于每个提供商在后台花费多少 DNS 查询。

机制的作用

include 表示检查另一个域名的 SPF 策略并继承其授权。这是 Google Workspace、 Microsoft 365、Mailchimp、SendGrid 和类似平台的主力。

ip4 用于固定的发送地址，当您控制源 IP 且不想依赖其他提供商的策略链时，这很有帮助。末尾的 all 设置了未授权内容的规则，限定符决定了失败的严格程度。

实用规则： 当您的发件人列表稳定时使用更严格的结尾，仅在您仍在清理堆栈时使用较宽松的结尾。

关于发件人规划的一个有用的外部视角是针对小型企业电子邮件活动的建议，因为活动团队经常在不检查其对 DNS 影响的情况下添加工具。

在实际的 GoDaddy 设置中，容易出错的部分是查询预算。每一个额外的 include 都会消耗该预算，记录看起来可能很干净，但由于链条太深，仍然会失败。围绕您运行的堆栈构建语法，而不是您希望运行的堆栈。

在不达到查询限制的情况下合并多个发件人

GoDaddy SPF 记录的主要失败模式不是语法，而是累积。一个域名从一个发件人开始，然后营销部门添加另一个，销售部门添加一个 CRM，运营部门添加一个交易平台，没有人注意到 SPF 现在试图验证的系统比标准允许的要多。

这条规则很生硬，而且不会变通。永远不要在同一个名称下发布超过一个 SPF 记录。 如果同一个域名存在两个 SPF TXT 记录，接收者可能会将结果视为无效或模棱两可，这意味着您认为有帮助的记录可能正是破坏身份验证的原因。

合并过程是如何工作的

首先列出每个合法的发件人。然后将它们折叠成一个 TXT 策略，在提供商管理其自身发送基础设施的地方使用 include 语句。如果您已经在 GoDaddy 中有了记录，请编辑该记录，而不是创建第二个副本。

第二个陷阱是嵌套。单个 include 可以在提供商自己的 SPF 策略中隐藏更多查询，这就是为什么域名耗尽预算的速度比团队预期的要快。以 GoDaddy 为重点的指南警告用户要保持在 10 次 DNS 机制查询的限制之下，并且该限制适用于评估期间，而不是事后 GoDaddy 域名的 SPF 设置最佳实践 2026 年 GoDaddy 域名的 SPF 指南。

更简洁的操作模型

首先审计每个发件人： 删除不再发送邮件的旧工具，因为陈旧的 include 仍然会消耗预算。
合并为一个策略： 将所有授权保留在正确名称下的单个 TXT 记录中。
保存前验证查询计数： 如果嵌套的 include 将其推过上限，看起来整洁的记录仍然会失败。

Mail Merge for Gmail 非常符合这一逻辑。它通过 Google 经过身份验证的基础设施发送，因此它不需要自己单独的 include，并且当您已经授权 Google Workspace 时，它不会增加 SPF 预算。

一张三步信息图，展示了合并和管理电子邮件身份验证 SPF 记录的战略指南。

这之所以如此重要，原因很简单。团队可以在几个月内保持在限制之内，然后一个新的供应商将记录推过边缘，SPF 开始失败，而 GoDaddy UI 中没有任何明显的 DNS 错误。

验证您的记录是否真正有效

在 GoDaddy 中保存记录并不能证明什么。它只意味着更改已输入，并不意味着权威区域正在提供它，不意味着缓存已更新，也不意味着策略解析得很干净。

三次检查，三个不同的答案

第一次检查是针对实时区域的 DNS 查询。dig 或 nslookup 查询会告诉您权威名称服务器返回的内容，这很重要，因为 GoDaddy 界面可以在传播完成之前显示一个值，而且它不会告诉您是否有其他 DNS 主机拥有该区域。

第二次检查是 SPF 解析器，例如 MXToolbox 的 SPF 检查。这种工具很有用，因为它在读取语法的同时计算查询次数，这正是嵌套 include 和超限链出现的地方。

第三次检查是消息级证据。发送测试邮件到 Gmail，打开原始邮件，并检查标头。Authentication-Results 行通常会显示 SPF 对于发送域名是通过还是失败，这告诉您邮箱提供商是如何评估邮件的，而不仅仅是 DNS 的说法。

实用规则： 如果 DNS 看起来正确但标头仍然失败，问题通常出在验证层，而不是 GoDaddy UI。

团队在忽略传播现实时需要承担风险。GoDaddy 的 TTL 行为通常很快，但边缘情况下的 DNS 更改可能仍需要时间才能在解析器之间稳定下来。如果您要在提供商之间移动记录，请先确认权威名称服务器，然后针对实际区域进行验证，而不是您碰巧使用的控制面板。对于端到端跟踪邮件，这篇邮件跟踪指南是更简洁的配套文章。

从 SPF 通过到完全电子邮件身份验证

SPF 通过让人感到安心，但这并不能解决整个问题。SPF 仅授权发送源，它不对邮件进行签名，也不会阻止邮件在离开发件人后被篡改。这就是为什么 SPF 本身仍然可能留下转发边缘情况和冒充漏洞的原因。

DKIM 和 DMARC 的作用

DKIM 向邮件本身添加加密签名。在 GoDaddy 管理的 DNS 中，这通常意味着选择器主机下的 TXT 记录，Google Workspace 通常使用 google._domainkey 作为该设置的一部分。

DMARC 位于 SPF 和 DKIM 之上。它告诉接收系统在身份验证失败时该做什么以及发送报告的位置，通常通过域名上的 _dmarc TXT 记录。如果没有 DMARC，当 SPF 或 DKIM 不匹配时，邮箱提供商就没有共享策略可遵循。

关键在于 SPF 只是信任的一层。如果未设置 DKIM，伪造的邮件仍然可以利用弱对齐，即使 SPF 在源头是干净的，转发的邮件在表现上仍然可能与原始发送不同。

实际的堆栈很简单。SPF 授权发件人，DKIM 签署邮件，DMARC 告诉接收者在两者不一致时如何行动。关于验证的早期部分在这里很重要，因为在您知道每个合法发件人都已通过身份验证之前，您不想收紧策略。

如需深入了解整个堆栈，这篇电子邮件身份验证指南在一个工作流程中连接了 SPF、DKIM 和 DMARC。

一个数字屏幕，显示电子邮件身份验证报告，显示 SPF、DKIM 和 DMARC 协议的通过检查。

在实际的邮件合并活动中保持 SPF 清洁

邮件合并活动会迅速给 DNS 工作带来压力。销售、招聘或活动团队可以在一天内从 Gmail 发送干净的序列，然后在下周回复率下降时责怪内容，尽管更深层的问题是身份验证漂移。

Mail Merge for Gmail 通过 Google 经过身份验证的基础设施发送，因此它不会创建需要自己 SPF include 的单独发件人。更大的风险是周围的堆栈发生变化，域名所有者添加了另一个平台，而邮箱提供商开始评估看起来不再一致的邮件历史记录。

一个真正有帮助的活动前清单

确认发送 Google 帐户的 SPF 通过： 测试将发送活动的准确邮箱，而不是随机别名。
确认在 Google Workspace 管理员中启用了 DKIM： 对于转发或重新包装的邮件，仅靠 SPF 太脆弱了。
确认 DMARC 至少为 p=none 且已开启报告： 这让您在强化策略之前拥有可见性。

单独的绿色 SPF 结果并不意味着活动可以安全启动。它只意味着发件人在那一刻匹配了当前的 DNS 策略。

最好的习惯是将 SPF 记录视为管道。在活动之前检查它，在添加新发件人时检查它，并在平台更改其发送路径时再次检查它。这就是您如何防止 GoDaddy SPF 记录老化成为送达率问题的方法。

一个四步 SPF 电子邮件身份验证清单，具有域名安全、子域名、监控和更新的图标。

Mail Merge for Gmail 帮助团队从 Gmail 发送个性化活动，同时将发送路径与 Google Workspace 绑定，这使得当域名堆栈变得拥挤时，SPF 更容易理解。如果您在下一次外展活动之前清理 GoDaddy DNS 设置，请访问 Mail Merge for Gmail，并查看它如何适应已经依赖于 SPF、DKIM 和 DMARC 保持清洁的工作流程。