Google Workspace 邮件认证：SPF、DKIM 与 DMARC 配置指南

Google Workspace 解决了投递，但三大认证协议仍要自己在 DNS 里配。缺了它们，域名就过不了 Gmail、Yahoo 与 Outlook 对批量发件人的要求：进箱率下滑、营销邮件成批进垃圾箱，而问题往往要到客户投诉时才被发现。更麻烦的是顺序——先上强制策略再补记录，拦下的第一批邮件就是自家的。

本指南按不出事故的顺序，给出 Workspace 域名确切的控制台路径与记录值，每一步都附带验证方法。协议入门见邮件认证总览。

准备工作

• admin.google.com 的管理权限（超级管理员或被委派 Gmail 管理角色）。
• 域名 DNS 写权限。DNS 在 Cloudflare 的读者先看Cloudflare DNS 邮件认证指南。
• 一份"除 Gmail 外谁在用你的域名发信"的清单：CRM、营销平台、工单、账单、网站表单。Workspace 的记录只覆盖经 Gmail 发出的邮件，清单上漏掉一个服务，这个服务发出的邮件在 DMARC 下就是失败项。

第一步：发布 SPF 记录

在域名根（主机名 @ 或留空）创建一条 TXT：

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

还有其他发件源，就合并进同一条记录：

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 ~all

两个硬约束：一个域名只能有一条 SPF，第二条 v=spf1 TXT 会让整条记录永久失败，接收方视同没有 SPF；_spf.google.com 本身还会展开三层嵌套 include，约占掉 RFC 7208 允许的 10 次查询中的 4 次，剩下的额度要留给其他发件源，加之前先数一遍。DMARC 报告确认覆盖完整前保持 ~all，之后再考虑收紧为 -all——每加一个来源就收紧一次，是最容易出事故的做法。用 SPF 检测验证，或用 SPF 生成器构建。

第二步：在管理后台启用 DKIM

1. 在 admin.google.com 进入 Apps > Google Workspace > Gmail > Authenticate email。
2. 选择域名，点 Generate new record，密钥长度选 2048 位——Google 的官方推荐，1024 位已属弱密钥。
3. 把 TXT 记录发布到 google._domainkey.yourdomain.com（默认 selector 为 google）。
4. 回后台点击 Start authentication。

只有状态显示"Successfully authenticated"，Gmail 才真正开始签名——生成记录却不打开这个开关，是最典型的空操作：DNS 里躺着一把没人用的公钥，外发邮件依然没有签名。DNS 传播一般几分钟到几小时，后台会周期复查。可用 DKIM 检测、selector 填 google 自行确认。用户会用到的每个别名域名都要重复一遍，DKIM 不会自动延伸；漏掉别名，等于每封用别名发出的邮件都在 DMARC 下失分。

第三步：自行发布 DMARC

Google 不替你管理 DMARC。在 _dmarc.yourdomain.com 加一条 TXT：

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1

p=none 不拦截任何邮件，只收集每日聚合报告——列出所有以你域名发信的来源及其 SPF、DKIM 与对齐结果。报告通常 24–48 小时后开始到达，用 DMARC 报告分析器阅读，把失败的正常发件源逐个修好；这个阶段最重要的是耐心，至少观察两到四周，覆盖月度账单、季度通知这类低频邮件。然后才逐步升级：先 p=quarantine 配 25% 的 pct，观察一周无异常再提高，最后才是 p=reject。监控期绝不能跳过。记录用 DMARC 生成器生成。

验证整套配置

从 Workspace 向 Gmail 地址发测试信，打开显示原始邮件，确认：

SPF:    PASS with IP 203.0.113.10
DKIM:   'PASS' with domain yourdomain.com
DMARC:  'PASS'

DKIM 那行必须显示你的域名——Gmail 以 d=yourdomain.com 签名，这正是对齐的要求。若 SPF 与 DKIM 都是 PASS、DMARC 却 FAIL，说明通过的域名和 From 域名对不上，通常是第三方代发在用自己的域名签名。整域检查用 邮件健康检查或 邮件投递测试；原始邮件头交给邮件头分析器解读。

常见错误

• 发布两条 SPF。注册商收得下，接收方不认。所有 include 合并成一条。
• 主机名重复拼接后缀。在会自动补域名的面板里填 google._domainkey.yourdomain.com，会生成以 .yourdomain.com.yourdomain.com 结尾的名称，DKIM 静默失败。用 TXT 查询核实。
• 生成了记录却没启动认证。DNS 里有密钥，Gmail 发出的仍是无签名邮件。
• 以为第三方发件源被覆盖。CRM 用 yourdomain.com 发信，既不在 Google include 的授权内，也不会被签名——DMARC 报告里它们会成片失败。常见两类见 SendGrid 与 Mailgun 指南。
• 别名域名未签名。用于 From 的每个别名都要有自己的 DKIM 与 SPF。这一步最容易在收购、品牌更名后遗漏：旧域名继续收发，记录却没人维护，直到有人在垃圾箱里发现合同邮件。

常见问题

别名域名要单独配吗？

要。每个别名域名都要单独启用 DKIM、发布 SPF；DMARC 按域名评估，主域名再完美，未签名的别名照样全部失败。

什么时候把 ~all 改成 -all？

等几周 DMARC 报告确认所有正常发件源都通过 SPF 之后。过早使用 -all，任何被遗忘的服务都会被硬失败。

2048 位记录为什么拆成两段？

长密钥超过部分服务商单条 TXT 字符串 255 字符的上限，拆成两段由接收方自动拼接。照后台原文发布即可，不要手工改动，也别把两段分开成两条记录。

要等多久才算"配好了"？

SPF 与 DKIM 发布后几分钟到几小时即可生效，DMARC 报告则要一到两天才开始到达。建议把"配好"定义为：连续两周的聚合报告里，没有任何正常业务来源失败，且每个来源都对得上号。做到这一步再收紧策略，风险最低。