在新域名上配置邮件：20 分钟搞定 SPF、DKIM 和 DMARC 的清单（2026）

发布于 2026-07-08

数据截至 2026-06-29 · 方法论 v7。 基于 261 百万个已评分域名的汇总普查数据。参见我们如何评分。

一个新域名在发出第一封邮件之前需要四样东西：一次基线扫描、一条写明你真实服务商的 SPF 记录、自定义域名的 DKIM 签名，以及一条从第一天就开启报告的 DMARC 记录。大多数域名从未走到这一步——根据 Defaults.Exposed 普查（截至 2026-06-29），46.4%（261,086,232 个已评分域名中的 121,145,609 个）根本没有 SPF。

把所有记录发布完大约需要 20 分钟：扫描拿基线、添加一条 SPF 记录、开启服务商的自定义域名 DKIM、发布带报告地址的 DMARC p=none、可选加上 MTA-STS，然后重新扫描并保存报告。更花时间的是任何清单都无法催促的两件事——DNS 传播和发送信誉——本指南对这两点都实话实说。

20 分钟真的够吗？

对于发布记录，够——下面每一步都只是一条 DNS 记录加上服务商管理控制台里的几次点击。有两件事更花时间，假装不是这样，正是新域名落进垃圾箱的原因：

传播。 新记录通常几分钟内就能解析，但解析器会按 TTL 缓存，一个刚完成委托的域名可能要几小时才能稳定应答。用 dig 验证；别在缓存追赶期间慌张地反复改。
预热。 新域名的发送信誉为零，而认证是信誉的前提条件，不是替代品。从低的、人类尺度的发送量开始，用数周时间逐步爬升。

诚实的说法是：20 分钟买到的是正确发布的认证。之后几周的理性发送买到的才是送达率。

20 分钟清单

先在 defaults.exposed 运行免费扫描。 在动 DNS 之前扫描新域名。“一切未配置”的评分基线几秒钟就能记录下来，并让之后的报告有意义——你会需要这对前后对比（第 6 步）。
为你实际使用的服务商发布一条 SPF 记录。 恰好一条以 v=spf1 开头、包含你服务商 include 的 TXT 记录——例如 Google Workspace 用 v=spf1 include:_spf.google.com ~all，Microsoft 365 用 include:spf.protection.outlook.com；如果你的 DNS 托管在注册商面板，GoDaddy 教程覆盖了界面上的怪癖。只能有一条：两条 v=spf1 记录是永久性错误，会让 SPF 完全作废——1,013,416 个域名正卡在这个状态里，约占尝试配置 SPF 的域名的 138 分之一（普查截至 2026-06-29），通常是迁移残留。不要“以防万一”地乱加 include：SPF 把 DNS 查询上限定为 10 次，至少已有 797,263 个域名因为爆掉这个上限而让记录作废。还要清楚 SPF 实际检查的是什么：接收方是拿 Return-Path（RFC5321.MailFrom）域名——退信地址——来评估它的，不是收件人看到的 From 标头。
开启自定义域名的 DKIM 签名。 你的服务商反正都会给邮件签名；问题在于签名写的是哪个域名。在你完成这一步之前，Google Workspace 用它的 gappssmtp.com 默认名义签名，Microsoft 365 用 onmicrosoft.com——这些签名 DKIM 能通过，却不与你的域名对齐，DMARC 照样失败。在管理控制台生成密钥并发布服务商给你的内容：Google 是一条 2048 位的 TXT 记录，Microsoft 365 是两条 CNAME（selector1/selector2）。如果记录塞不进你的 DNS 面板，见修复 DKIM——长密钥被界面弄坏是经典问题。
从第一天起发布 DMARC——带报告地址的 p=none。 在 _dmarc.yourdomain.com 添加一条 TXT 记录：v=DMARC1; p=none; rua=mailto:[email protected]。要清楚这条记录做什么：p=none 目前什么都不保护——它是监控模式。但它零成本，而且汇总报告从此覆盖你域名从第一封邮件起的全部发送历史。老域名要花数周的报告时间才能挖出被遗忘的发件方；你从第零天起就免费买到了这份可见性。记录的结构详见修复 DMARC。
可选但在新域名上很便宜：MTA-STS 和 TLS-RPT。 MTA-STS 告诉发送服务器你的域名要求入站邮件使用 TLS（一条 DNS 记录加一个小的托管策略文件）；TLS-RPT 报告投递加密失败。在老域名上这两项需要小心；在只有一家邮件服务商的新域名上没有什么可弄坏的，mode: testing 基本零风险。现在配上或者跳过——但要做决定，别放任漂移。
重新扫描并保存报告。 再次运行扫描——SPF、DKIM 和 DMARC 应该都显示绿色。保存这份评分报告：域名上线时状态的带日期凭证，也正是保险公司或客户问卷会要的东西。

到底有多少域名完成了这份清单？

非常少——而且大多数倒在第一道坎上。在 Defaults.Exposed 普查评分的 261,086,232 个域名中（截至 2026-06-29）：

清单里程碑	普查现实（261,086,232 个已评分域名，截至 2026-06-29）
第 2 步——发布任意 SPF 记录	46.4% 从未做过：121,145,609 个域名完全没有 SPF
第 4 步及以后——DMARC 达到强制执行策略	10.59%（27,640,987 个域名）；89.41% 没有强制执行的策略
完整三件套——SPF + DKIM + 强制执行的 DMARC	3.87%（10,092,481 个域名）

本页描述的这 20 分钟，能让一个全新域名在完整三件套上领先互联网上大约 96% 的域名。SPF 采用成熟度模型拆解了这架梯子的每一级。

新域名多快能达到 p=reject？

数周，而不是数月——这正是从零开始的真正优势。让 DMARC 强制执行在老域名上进展缓慢的是历史包袱：被遗忘的 CRM 连接器、某人在 2019 年接上的开票工具、没人记录在案的邮件通讯平台。每一个都得先在报告里被找出来并修好，策略才能收紧——所以标准的推进周期长达数月。

新域名没有历史发件方：每一个发送来源都是你自己本周亲手配置的，第 4 步的报告会印证这一点。用两到四周的真实发送跑 p=none，核对报告覆盖了你实际使用的一切（邮箱、发票、回执、网站的联系表单），然后升到 p=quarantine，报告干净后再升到 p=reject。分阶段的操作细节——pct 爬坡、子域名策略、要盯什么——都在从 p=none 到 p=reject里；在新域名上你会快速走完这些阶段，抵达只有 10.59% 已评分域名到达过的地方。

你正在替换的那个旧域名怎么办？

如果这个新域名是品牌重塑的一部分，你留下的那个旧域名现在就是你最大的邮件风险：仍然归你所有，仍被合作方信任，却不再有人盯着。别弃之不管——明确地把它锁死。那是另一件小活：你改名后留下的旧域名，是一扇没关的门。

常见问题

还没选好邮件服务商，能先发布这些记录吗？ DMARC 可以——带 rua 的 p=none 与服务商无关，注册当天就发布。SPF 需要你服务商的 include；在选定之前，先发布 v=spf1 -all（不授权任何人发送），第 2 步时再替换。这严格好于 121,145,609 个域名所处的无记录状态（占 261,086,232 个已评分域名的 46.4%，截至 2026-06-29）。

SPF 已经通过了，还需要 DKIM 吗？ 需要。SPF 在转发场景下按设计就会失效，而且它验证的是 Return-Path 域名——对很多工具来说那不是你的域名——对齐的 DKIM 才是两种情况都扛得住的那条腿。只有 3.87% 的已评分域名完成了 SPF+DKIM+强制执行 DMARC 的完整三件套（普查截至 2026-06-29）；DKIM 是半途而废者最常跳过的一步。如果扫描标出了它，从修复 DKIM开始。

新域名该用 ~all 还是 -all？ 在老域名上，~all 是排查被遗忘发件方期间的稳妥选择。新域名没有可找的发件方：一旦服务商的 include 已就位、DKIM 已在签名，-all 早得多就是安全的。想再上一道保险？先用两周干净的 DMARC 报告确认。

三条记录都通过了——为什么我的邮件还是进垃圾箱？ 因为认证和信誉是两码事：记录通过意味着接收方能验证邮件确实出自你手，不代表他们已经信任你。新域名靠持续发送对方想要的、低量的邮件并逐步爬升来赢得信任。如果邮件是没通过检查而不只是落进垃圾箱，从修复 SPF开始，顺着扫描结果逐项处理。

把报告发给老板

如果你是在替客户配置这个域名，用证据收尾。第 6 步之后重新运行免费扫描，把评分报告转发给企业负责人：SPF、DKIM 和 DMARC 全部通过，直白语言，上线当天的日期。这正是他们在网络保险续保和下一份供应商安全问卷时需要的凭证——它也证明这个域名从出生起就做到了互联网上 96% 的域名从未做到的事。

检查你的域名 → · 从 p=none 到 p=reject 而不丢失正常邮件 → · 仅使用汇总数据。数据在欧盟境内存储和处理。