创建 DMARC 记录并验证

人们往往在发现冒用邮件、Gmail 警告或收到服务商的 DNS 修改要求后，才决定创建 DMARC 记录。不同邮件的 SPF 和 DKIM 结果不一致，也可能是原因。若还在搭建整体架构，可以先阅读商务邮箱指南，协调域名、邮箱和 DNS。

记录存在不等于配置有效。主机名错误、策略不合适、报告地址失效和缺少对齐，都可能暂时不被发现。发布记录不会自动解决域名冒用或正常邮件的投递问题。

下面介绍关键标签、在 _dmarc.yourdomain.com 的发布方法，以及经过验证后从观察转向限制请求的流程。

创建 DMARC 记录时发布什么

在 _dmarc.yourdomain.com 发布 TXT，以 v=DMARC1 开头，包含有效策略，例如 p=none、p=quarantine 或 p=reject。当 SPF 和 DKIM 都没有提供同时通过认证且与 From 对齐的结果时，DMARC 向接收方提出处理请求。

最简有效示例如下：

Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none;

它不请求 DMARC 限制处理，但没有报告地址，也不会请求报告。接收方的本地过滤仍可能生效。

带聚合报告的示例：

Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r; pct=100

以下是验证发信后才应考虑的替代策略，不要与上面的记录同时发布：

Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r; pct=100

RFC 7489 要求 v 为首个标签，且必须包含 p。无效记录可能让策略无法正常解析。协议细节见 RFC 7489。

在 DNS 的什么位置创建 DMARC

不要发布在域名根部，而应使用主机名 _dmarc。对于 example.com，完整查询名称是 _dmarc.example.com。发布在其他位置，接收方就无法通过这一查询找到所需策略。

常见错误是使用 @，或将 _dmarc.example.com 完整填入只接受相对主机名的面板。若面板要求 _dmarc，应按其规则填写。短名称还是完整名称取决于 DNS 服务商。

发布后应从面板以外查询：

dig txt _dmarc.example.com +short
nslookup -q=txt _dmarc.example.com

应找到一条以 v=DMARC1 开头的有效 DMARC 策略记录。同一 TXT 记录中的多个字符串不等于多条策略记录，其他 TXT 内容也应分别判断。

使用 TrekMail 时，可以添加域名、复制必需值并检查 DNS 查询结果。相关资料有添加域名、必需的 DNS 记录和检查 DNS 状态。实际发信渠道仍需额外邮件测试。

创建记录时需要的标签

先配置必需的 v、p，并通过 rua 指定适合的报告地址。其他对齐和报告参数应有明确用途，而不是单纯增加配置复杂度。

标签	必需	作用	实际建议
`v`	是	版本标识	`DMARC1` 必须位于首位
`p`	是	DMARC 失败时的处理请求	先用 `none` 观察，验证后考虑 `quarantine`，再按需要采用 `reject`
`rua`	否	聚合报告目标	使用可接收、有人管理且限制访问的地址
`ruf`	否	失败报告目标	可选，支持有限，内容可能敏感
`adkim`	否	DKIM 对齐方式	`r` 是默认方式，仍应核对发信需求
`aspf`	否	SPF 对齐方式	`r`，或有明确理由并测试后的 `s`
`pct`	否	请求限制处理的失败邮件比例	`100`，除非计划逐步实施；接收方行为可能不同
`sp`	否	子域名继承策略	子域名需不同处理时核对，同时考虑其自身适用记录

有效记录只有 p=none 而没有 rua 时，不会请求聚合报告。其他日志可以提供线索，但不自动替代这一反馈渠道。

如何选择合适策略

发信渠道尚未验证时，可以先采用 p=none。分析报告、核对发信清单并测试邮件后，再考虑 p=quarantine。p=reject 应以关键及低频正常发信的验证为前提；未知 IP 本身不证明未经授权的发送。

策略	对接收方的请求	可能用途	主要风险
`p=none`	不请求 DMARC 限制	部署初期观察	这条策略不增加限制处理
`p=quarantine`	将失败邮件按可疑邮件处理	验证发信后	正常特殊邮件可能受影响，不保证可恢复
`p=reject`	请求拒收失败邮件	已验证的配置	配置错误的正常邮件可能被拒收

Google 所说明的批量发件人要求包括 SPF、DKIM，以及通过至少一项成功认证满足 From 对齐。请在 Google 发件人常见问题核对当前适用要求，不要将未来变化当作现有规则。

启用认证不等于满足 DMARC。CRM 使用你的 From，却采用自身签名域名和退信域名时，若没有其他通过且对齐的结果，DMARC 仍可能失败。

分步骤创建 DMARC 记录

先整理发信来源，再发布观察策略，分析报告、日志和实际测试。报告安静不代表低频重要邮件已经覆盖。

列出所有服务，包括 Google Workspace、Microsoft 365、客服、CRM、表单、账单和通讯平台。
验证实际发信系统的 SPF 和 DKIM。DMARC 不替代它们。SPF 的限制计算需要 DNS 查询的机制和修饰符，包括嵌套求值，不是所有查询。
创建有人管理的 dmarc@yourdomain.com 等地址，或使用报告服务。评估隐私并核对外部目标所需的 DNS 授权。
发信尚未完全验证时，先采用 p=none。
将可用报告与系统清单、日志和测试相互核对。
修复通过认证的域名与 From 的对齐。
验证后考虑 p=quarantine。
排查剩余问题并测试低频流程后，考虑 p=reject。

以下是 2026 年的观察策略参考示例，需要按实际环境调整：

Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r; pct=100

使用转发时，可参考将域名邮件转发到 Gmail。SPF 可能在新服务器上失败；若签名覆盖的数据在规范化规则下保持有效，对齐的 DKIM 可以让 DMARC 通过。ARC 可以帮助接收方作出本地例外决定，但不会将 DMARC 失败变为真正的验证成功。

创建 DMARC 的常见错误

错误主机名、重复策略、失效报告地址和未经验证的 SPF、DKIM 都是常见原因。应从外部检查发布结果，并测试实际邮件。

尤其注意以下错误：

1. 发布在根部，而不是 _dmarc。
在 @ 创建的记录不在所需查询位置。

2. 发布多条 DMARC 策略记录。
RFC 7489 说明，多条策略会使处理停止。这与同一 TXT 记录中的多个字符串不同。

3. 直接使用 p=reject。
被遗漏的服务可能导致密码重置、账单或客服回复遭到接收方拒收。

4. rua 指向不可接收的地址。
报告无法到达该地址。但即使地址有效，没有报告也不证明所有接收方都曾发送报告。

5. 期待 DMARC 修复转发。
DMARC 需要成功且对齐的 SPF 或 DKIM。转发可能使 SPF 失败，DKIM 只有在签名仍然有效且对齐时才有帮助。

订单确认、客服和营销使用不同 SMTP 服务。你在验证所有系统之前发布 p=reject，部分邮件通过，其他邮件可能被拒收。未完成的发信验证就会影响客户。

创建自有域名邮箱介绍了整体 DNS 和邮箱流程，包含 SPF、DKIM 和 DMARC 的配合。

为大量域名管理 DMARC

表格、不同注册商登录和旧工单中的 TXT 值，会让一致管理变得困难。统一界面和可核查的 DNS 配置可以帮助管理，但仍需考虑实际 DNS 服务商和发信渠道。

分散管理	TrekMail 可提供的方式
在不同注册商界面核对 DNS 值	统一管理多域名邮箱
手动比较 TXT 并估计缓存更新	检查实时 DNS 查询和已发现冲突，不保证传播时长
用不同工具管理 SPF、DKIM 和 DMARC	集中处理 DNS 配置
多个小规模域名分别按用户计费	考虑每月 $3.50 起的固定费用套餐，仍受套餐限制

TrekMail 可按套餐集中提供多域名、共享存储、IMAP 邮箱、迁移、catch-all、转发，以及自备或托管 SMTP。Nano 有支持最多 10 个域名和自备 SMTP 的免费选项。付费套餐价格参考为每月 $3.50 起。当前条件见 TrekMail 价格。

统一界面可以减少在五家服务商和二十个浏览器标签间切换，但不替代所有发信渠道的验证或 MX、应用切换计划。IMAP 导入只复制现有邮件。