摘要：独立站的通知信、营销信进了 Gmail 垃圾箱，或直接被拒收时，先核对本域有没有正确的 SPF、DKIM 和 DMARC 记录。依据 Google《电子邮件发件人指南》和 Cloudflare DNS 文档，整理所有发件人与每日超过 5000 封时的不同要求、三条记录怎么查、以及常见配错。查询日期 2026-11-12。只放官网普通链接（affiliate_later）。

依据：Google《电子邮件发件人指南》、Google《帮助防止仿冒和垃圾邮件（DMARC）》、Google《设置 SPF》、Google《设置 DKIM》、Cloudflare《Set up email records》、RFC 7208（SPF）、RFC 7489（DMARC）。查询日期：2026-11-12（北京时间）。只放官网普通链接（affiliate_later: 1）。具体主机名、选择子和 IP 以你的邮箱服务商提供的值为准，本文不编某块面板里的默认记录。不构成运维或合规建议，改 DNS 前先记下当前记录，改完以实际解析到的 TXT 为准。

独立站发出去的注册验证、重置密码或活动通知，收件人说进了 Gmail 垃圾箱，或者你自己的测试地址直接退信。这种情况不一定是文案写得像推销，更常见的是：发出去的信在 DNS 里无法证明「这个域名允许这台服务器发信」。Cloudflare 的邮件记录文档写过，没有认证记录时，任何人都可以发出看起来像来自你域名的邮件。三条和这件事直接相关的 TXT 记录是 SPF、DKIM 和 DMARC。域名上的 A、CNAME、MX、TTL 怎么读，见域名解析入门。如果你还在选邮件服务商、看免费额度和退订，见独立站邮件营销入门。本文只核对这三条认证记录，以及 Gmail 对发件人的门槛。

功能名称、后台菜单位置会随域名注册商和邮箱服务商变化。下面步骤以 2026-11-12 打开的 Google 中文帮助和 Cloudflare 英文文档为准；和你控制台里的用词不一致时，以服务商当时给你的记录值为准。

1. 先分清 Gmail 对「所有发件人」和「每天超过 5000 封」的要求

Google《电子邮件发件人指南》针对的是发到个人 Gmail 账号（以 @gmail.com 或 @googlemail.com 结尾）的邮件。自 2024 年 2 月 1 日起，所有这类发件人都要满足一组基础要求；如果你每天向 Gmail 账号发送超过 5000 封，还要再满足更严的一组。指南更新表里还单独加过一条：使用 TLS 连接传输电子邮件（添加于 2023 年 12 月）。

所有发件人都要核对这些项：

  1. 为发件人网域设置 SPF 或 DKIM。
  2. 发件人网域或 IP 具有有效的正向和反向 DNS 记录（PTR）。发件人 IP 必须能解析到指针记录里的主机名，主机名再用 A（IPv4）或 AAAA（IPv6）解析回同一个 IP。
  3. 使用 TLS 发送。
  4. 把 Postmaster Tools 中报告的垃圾邮件比例保持在 0.3% 以下。同一页后面也建议尽量保持在 0.10% 以下，避免升到 0.30% 或更高。
  5. 按 RFC 5322 设置邮件格式；From: 标头只放一个地址，并且不要冒用 Gmail 的 From:。

每天发送 5000 封或更多时，在上面这些之外还要：

  1. 同时设置 SPF 和 DKIM，不能只做其中一项。
  2. 为发件人网域设置 DMARC。强制执行政策可以先设为 none（不采取强制措施）。
  3. 直接发送的邮件里，From: 标头中的域名必须与 SPF 域名或 DKIM 域名一致，这样才能通过 DMARC 对齐检查。
  4. 营销邮件和订阅邮件必须支持一键退订，并在正文里提供清晰的退订链接。对应标头是 List-Unsubscribe-Post 和 List-Unsubscribe，细节见指南引用的 RFC 2369 和 RFC 8058。

未通过这些认证方法的邮件，可能被标为垃圾邮件，或被拒收并显示 5.7.26 错误。指南还写明：即便你用的是第三方发信服务，也要确认对方是否用 SPF 和 DKIM 为你的网域做了认证，并且你的 SPF 记录里要包含所有实际发件人。缺了哪一家，那一家发出去的信更容易进垃圾箱。

2. SPF：先看这域允许谁发信

SPF（Sender Policy Framework）是一条发布在你网域上的 TXT 记录，列出哪些主机或服务有权用这个域名发信。Google 的 SPF 说明写到，它用来减少垃圾邮件发送者发出「看起来来自你的网域、实际上未被授权」的邮件。Cloudflare 的说法是：SPF 列出获授权代表你的域名发信的 IP 和域名。

常见形态以 Google Workspace 文档中的例子为起点：如果你只用 Google 发信，官方给出的记录是 v=spf1 include:_spf.google.com ~all。你实际该写什么，取决于发信服务商。用了 Brevo、Mailchimp 或其他平台，就要按对方文档把对应的 include: 加进来。Google 明确写过：第三方发件人不在 SPF 记录里，这些发件人的邮件更可能被标为垃圾邮件。

核对时在 DNS 控制台找到根域（@ 或你的主域名）的 TXT 记录，确认有且通常只有一条以 v=spf1 开头的记录。RFC 7208 第 4.6.4 节规定，会触发 DNS 查询的机制和修饰符合计不得超过 10 次，其中包括 include、a、mx、ptr、exists 以及 redirect。一条记录里叠很多 include，看起来都写上了，接收方评估时却可能直接判为永久错误（permerror）。不要靠再发布第二条 v=spf1 来「补充」名单，应把授权来源合并进同一条。

记录末尾的 ~all 和 -all 含义不同。~all 是软失败， -all 是硬失败。改成硬失败之前，先用后面说的 DMARC 报告看有没有遗漏的发信源。指南没有要求你必须立刻用哪一种结尾，先保证名单完整，再收紧。

在命令行可以查已生效的记录，例如：

dig +short TXT example.com

把 example.com 换成你的根域。输出里找到 v=spf1 那一条，核对 include 和 IP 是否覆盖你正在使用的发信平台。Google 也提供管理员工具箱里的 Dig 工具，用来检查 PTR 等记录。

3. DKIM：再看这封信有没有被改过、是不是这个域签的

DKIM（DomainKeys Identified Mail）给发出去的邮件做加密签名。接收方用你发布在 DNS 里的公钥验签，确认这封信确实由该域名的所有者发出，并且运输途中正文和相关头字段没有被改掉。Cloudflare 对 DKIM 的归纳也是这两点：认证发件人域名，并验证内容在传输中未被更改。

公钥通常发布在一个选择子（selector）对应的主机名上，形状类似 selector._domainkey.example.com，记录类型是 TXT，内容以 v=DKIM1; 开头。选择子的名字由邮箱服务商给出，不要自己编一个。启用步骤在 Google Workspace 上是打开 DKIM、生成记录再写回 DNS；如果你不用 Google 发信，官方建议向域名或邮箱提供商索取密钥，或按对方文档生成。

Google 对发到个人 Gmail 账号的邮件提出了密钥长度要求：至少 1024 位；如果提供商支持，建议使用 2048 位。服务商后台如果还停留在更短的密钥，先按官方文档轮换，再删掉旧选择子，避免验签失败。

核对时不要只看控制台里「已启用」的开关。用 dig +short TXT selector._domainkey.example.com 确认公网已经解析到新公钥，再发一封测试信，在收件详情里查看 DKIM-Signature 和认证结果。选择子还没生效就发大批量邮件，等于还在用未发布的密钥签名。

4. DMARC：告诉接收方，SPF 或 DKIM 失败时怎么处理

DMARC（Domain-based Message Authentication, Reporting and Conformance）告诉接收方，当邮件没有通过 SPF 或 DKIM，或者通过了但和 From: 里的域名对不齐时，该怎么处理，并可以给你发汇总报告。Google 写明：要通过 DMARC 认证，邮件必须通过 SPF 和/或 DKIM，而且用于认证的域名必须与 From: 标头中显示的域名相同。这就是前面说的对齐（alignment）。每天超过 5000 封时，Gmail 要求你必须发布 DMARC；政策可以先是 none。

记录发布在 _dmarc.example.com 的 TXT 上，以 v=DMARC1; 开头。RFC 7489 把政策 p 写成三种：none（不改变处理方式，主要用来观察）、quarantine（按垃圾邮件或类似隔离处理）、reject（直接拒收）。常见起步写法是先观察，例如：

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

其中 rua 是汇总报告的收件地址，换成你能收到信、并且有权限管理的邮箱。Google 建议设置 DMARC 报告，用来查看从你的网域发出、或看起来像从你网域发出的邮件，并找出可能在冒充你的发件人。不要在还没看过报告、还没把所有正规发信源写进 SPF/DKIM 之前，直接把 p 改成 reject，否则合法的通知信也可能被拒。

命令行核对：

dig +short TXT _dmarc.example.com

若没有任何记录，对 Gmail 的群发场景来说，这就是还没迈过「必须设置 DMARC」那条线。若已有记录，核对 p= 和 rua= 是否仍是你想维持的值，以及报告邮箱能否正常收信。

5. 核对时按这个顺序走，避免改错一条把邮件打得更死

  1. 先到 DNS 控制台和公网解析里，分别列出 SPF、DKIM、DMARC 三条 TXT 的现值，保存一份备份。
  2. 对照邮箱服务商文档，确认 SPF 的 include 或 IP 覆盖了所有实际在发信的平台；有几家平台就核对几家，不要只写主机服务商那一条。
  3. 确认只有一条 v=spf1，并且 include 等查询次数没有顶到 RFC 7208 的 10 次上限。
  4. 向服务商要到 DKIM 选择子，确认 selector._domainkey 已解析，密钥不少于 1024 位。
  5. 发布或核对 _dmarc 记录。群发还没把握时，先用 p=none 收报告，不要一步改到 reject。
  6. 发一封到你自己的 Gmail 个人邮箱，打开原始邮件，看 SPF、DKIM、DMARC 的认证结果，以及 From: 是否与签名域对齐。
  7. 若你走营销或订阅邮件、且量可能超过每天 5000 封，再核对一键退订标头和正文链接。退订和名单合规的操作面，见邮件营销入门。
  8. 用 Google Postmaster Tools 看垃圾邮件比例、认证是否通过、网域和 IP 声誉。比例不要用猜的，以工具里的报告为准。

反向解析（PTR）通常不能在域名的普通 DNS 面板里改，而要在发信 IP 的托管商那边设置。自己架 SMTP 时，这一项经常被漏掉。Cloudflare 还提醒：默认不会代理 25 端口的 SMTP 流量；邮件相关的主机记录通常应保持「仅 DNS」，不要当成普通网站那样去橙色云代理。文档里的示例把 mail 的 A 记录写成 DNS only，并把 MX 指向这个子域。具体主机名和优先级仍以邮箱服务商为准。

6. 常见卡点和不要和别的问题混在一起

  1. SPF 写了两条。 接收方可能不知道该用哪一条，评估失败。合并成一条再查 dig。
  2. 只认证了根域，实际用子域发信。 例如信是 From: notify@mail.example.com，却只在 example.com 上做了对齐检查需要的记录。按实际 From: 域名补齐 SPF、DKIM 和对应的 DMARC 策略（含子域策略时以你发布的记录为准）。
  3. DKIM 开关已开，DNS 还没有新公钥。 先等解析生效再批量发信。
  4. 营销平台和事务邮件不在同一条 SPF 里。 注册验证能进收件箱、活动信进垃圾箱，优先查是不是活动平台的 include 漏了。
  5. 把退信都当成「认证失败」。 421/4.7.0、550/5.7.1 这类错误，Google 指南里还列过 IP 不在允许名单、共享 IP 声誉差、IPv6 PTR 不合规等情况。先读退信里的 SMTP 代码，再决定是改 TXT 还是改 IP 和发信节奏。
  6. 突然把日发送量翻倍。 指南要求逐步提高发送量，并用 Postmaster Tools 盯错误率和垃圾邮件比例。认证记录正确，也不等于可以无限制突增。

网站打不开、证书报错或 502，和发信进垃圾箱不是同一类问题。前者先看网站 404 / 502 排查清单。本文不处理内容质量评分、也不是某家服务商的开户教程。

核对清单（可勾）

  1. □ 已分清自己大致属于「所有发件人」还是「每天向 Gmail 超过 5000 封」；后者需要 SPF、DKIM 和 DMARC 同时具备
  2. □ 根域只有一条 v=spf1，且已覆盖全部实际发信平台；include 等查询未超过 10 次
  3. □ DKIM 选择子已在公网解析，密钥不少于 1024 位，测试信里能看到验签通过
  4. □ _dmarc 记录已发布；政策与报告邮箱是你有意设置的；尚未看报告前没有直接改成 reject
  5. □ 测试信的 From: 与 SPF 或 DKIM 认证域对齐
  6. □ 营销或订阅类邮件如达到指南门槛，已具备一键退订标头和正文链接
  7. □ 发信 IP 的 PTR 与正向解析一致；Cloudflare 上邮件主机记录没有被误开代理
  8. □ 没有把退信代码一律当成 TXT 记错，也没有编某面板里未核过的「推荐记录」

相关阅读

官网入口（普通链接，无返利）：Google 电子邮件发件人指南、设置 SPF、设置 DKIM、设置 DMARC、Cloudflare：Set up email records、RFC 7208、RFC 7489。