DMARC RUA 在 DMARC 记录中指定汇总报告地址，参与的接收方可向这里发送信息。没有它，就少了一项了解认证和未知来源的重要反馈；即使有报告，覆盖仍不完整。域名邮件基础可先参考小企业邮箱指南。
配置错误的 CRM、被遗忘的 WordPress 插件，或转发后的 SPF 失败，都可能使诊断更困难。RUA 让部分流量变得可见，帮助你根据数据调查，而不是猜测。
本指南介绍 RUA 标签、DNS 发布方式、XML 报告含义，以及修复问题的检查顺序。
什么是 DMARC RUA？
RUA 指定汇总认证报告的接收地址。报告按一个时间段汇总 SPF、DKIM、对齐、发送 IP 和 DMARC 处理，通常按天发送，但只覆盖参与接收方观察到的邮件。
在 DMARC 记录中，rua=mailto:... 请求把汇总报告发送到此处。根据 RFC 7489，rua 指定反馈目标。报告包含认证结果、对齐、域名、邮件数量和实际处理等数据。
执行限制需要可靠依据。选择 p=none、p=quarantine 或 p=reject 时，应结合报告、发送系统清单和真实测试。RUA 本身不能证明流量已经完全准备好。
RUA 报告实际显示什么
RUA 提供汇总信息，不是单封邮件副本。它显示观察到的来源、原始 SPF 与 DKIM 验证结果，以及 DMARC 所需的域名对齐。auth_results 包含原始检查，policy_evaluated 则反映结合对齐后的 DMARC 评估。
可以把它作为定期运维数据。报告不含邮件正文，但可能提供服务配置错误、伪造和对齐问题的线索。
| 标签 | 作用 | 内容 | 用途 |
|---|---|---|---|
rua | 请求汇总报告 | 按源 IP 和认证结果汇总的 XML | 定期监测与策略推进 |
ruf | 请求失败报告 | 接收方支持时提供单封错误详情 | 针对性的补充排错 |
通常应先使用 RUA，只有明确需要时才考虑 ruf。失败报告支持有限，详细信息也涉及更多隐私问题。
例如，域名通过 Google Workspace、账单应用和客服系统发送。报告可能呈现这些来源，前提是参与接收方观察到了相应邮件。客服对齐失败需要核查，但未知来源或不同国家位置本身并不能证明伪造。
如何发布 RUA 地址
在 _dmarc.yourdomain.com 创建 TXT，加入有效的 rua=mailto: 地址。发送源尚未验证时，可先监测，而不是立即请求严格处理。
下例使用可选的严格对齐，并不适合作为所有域名的默认选择：
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s"不使用严格对齐的简化替代方案如下。不要同时发布这两种记录：
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"使用专用报告邮箱或解析服务，避免压缩 XML 附件影响正常客服工作。
TrekMail 的必需 DNS 记录介绍相关配置。内置 SPF、DKIM 和 DMARC 检查可能发现 DNS 错误，但不能代替所有发送源的真实邮件测试。
如何验证 RUA 记录
直接查询 DNS，然后检查报告是否到达。记录错误可能使报告地址无法使用，但报告缺失也可能因为接收方不参与或缺少授权。
可使用 dig 或 nslookup：
dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.com响应应包含已发布的 DMARC TXT。RFC 7489 介绍了以下有效格式：
"v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com"报告通常按天发送，但时间表和参与程度各不相同。等待期间没有数据，不能证明 DNS 正确，也不能证明没有流量。
按顺序阅读 RUA 报告
在 XML 中找到来源，检查 SPF 与 DKIM，再看对齐和处理。至少一种机制必须同时验证成功并对齐，DMARC 才会通过。
可按以下顺序：
- 检查源 IP 和反向 DNS，与自己的系统对照。PTR 名称本身不能证实身份。
- 比较邮件量：2 封和 20,000 封规模不同，但低流量来源也可能对业务至关重要。
- 检查 SPF、DKIM 与对齐。没有对齐的成功结果仍不足够，除非另有成功且对齐的路径。
- 查看处理：
none不证明具体投递或仅监测；quarantine不保证固定文件夹；reject不保证无例外地阻止。 - 把来源判断为合法、配置错误、可疑或尚未确认。
Google 对发往个人 Gmail 的普通直接发送源要求 SPF 或 DKIM。批量发件人则需要两者和 DMARC，并通过至少一个成功路径对齐到 From: 域名。RUA 有助于发现真实对齐问题，但不保证进入收件箱。
三类重要的 RUA 问题
常见调查方向是合法发送源缺少认证、转发引起的 SPF 失败，以及可能的伪造。采取措施前，应结合其他信息判断。
1. 合法发送源，配置有误
已知服务为域名发送，但缺少所需 SPF 或对齐 DKIM。DMARC 只需成功且对齐的 SPF 或 DKIM；不过缺少 DKIM 仍可能影响转发。应先修复来源，而不是更改策略。
自备发送服务时，应按实际发送路径配置 DNS。参考自备 SMTP。适用付费套餐的托管 TrekMail SMTP则说明托管发送和签名设置。
2. 转发导致 SPF 失败
新的发送 IP 可能使 SPF 失败，但邮件不一定是伪造。已签名数据在规范化规则下保持不变时，DKIM 可能保留。成功且对齐的 DKIM 可以让 DMARC 通过。应测试具体路径，不要一概忽略 SPF 失败。
可参考邮件转发配置和把域名邮件转发到 Gmail。SPF 失败与 DMARC 失败是不同结果。
3. 未知来源，可能存在伪造
未知 IP 可能来自未登记服务、共享中继、转发或滥用。未经检查不要加入 SPF 或允许名单。确认合法来源配置后，再考虑执行更严格的策略。
是否应该把 RUA 指向第三方服务？
外部服务可以简化 XML 解析，但应核查 DNS 要求及数据处理方式。外部目标需要授权，部分接收方会在发送报告前检查。
RFC 7489 说明，rua 地址位于组织域名之外时，需要在目标域名 DNS 发布确认记录，例如：
example.com._report._dmarc.thirdparty.example.net. IN TXT "v=DMARC1"没有确认记录时，报告生成方可能忽略外部地址。因此，应遵循解析服务的具体设置，并核查目标端授权。
何时从 p=none 转为 quarantine 或 reject
更改策略前，应结合报告、系统清单和测试。未解释的失败不一定是伪造，应在充分检查合法流程后再请求严格处理。
可采用以下步骤：
- 发布带
p=none的 RUA。 - 例如观察 1 到 2 周，并另外测试低频发送周期。
- 确保每个合法来源有成功且对齐的 SPF 或 DKIM。
- 验证后再考虑
p=quarantine。 - 确认关键邮件并调查剩余失败后，再考虑
p=reject。
如果省略观察和测试，可能由客户先发现漏配的发送源。应主动检查，并规划合法邮件失败时的响应。
用统一流程管理 RUA 运维
XML 仍需人工分析，或由解析服务处理。标准化 DNS 和统一面板可能简化域名、邮箱、迁移和发送管理，但不是自动报告分析。
| 分散管理 | TrekMail 的统一流程 |
|---|---|
| 每个域名有不同 SPF、DKIM 和 DMARC 配置习惯 | 在同一面板跟踪域名 DNS 与邮箱操作 |
| 无法确定哪个来源破坏了对齐 | DNS 设置流程和排错文档 |
| 转发问题全部归因于 SPF | 结合 DMARC、DKIM 与真实转发路径检查 |
| 按用户收费增加多域名预算难度 | 套餐参考价每月 $3.50 起，采用共享存储而非逐用户收费 |
TrekMail 不是 DMARC 解析器。它按套餐提供自有域名、IMAP 邮箱、Catch-all、转发、IMAP 迁移和自备或托管 SMTP。这可能减少基础设施管理工作，但不能代替报告解读。
付费套餐参考价为每月 $3.50 起。Nano 作为无需信用卡的免费方案提供。付费套餐可能提供 14 天试用并要求信用卡。请核实当前价格、功能和条件。
结论：RUA 提供运维反馈
RUA 可能呈现发送源失败、转发影响及伪造线索。它是有价值的补充信息，但不能完整证明域名已准备好执行各种限制。
无论管理一个、五十个还是五百个域名，定期分析和更新发送清单都很重要。设置 RUA、阅读数据，并在更改策略前测试合法来源。
TrekMail 根据所选套餐提供多域名托管、共享存储、邀请式邮箱创建和 IMAP 迁移，并采用固定套餐模式。开始使用及当前条件可在 trekmail.net 查看。
