Why your DMARC reports never arrive (and why Gmail can’t be your rua address)

为什么你的 DMARC 报告从未送达（以及为什么 Gmail 不能作为你的 rua 地址）

You published a DMARC record months ago. Every checker says it’s valid. No reports have ever arrived, and at some point you stopped thinking about it and quietly concluded nobody’s forging your domain. You don’t know that. You just can’t see. Two causes account for almost all of it, and both leave the DMARC record itself looking perfect. 几个月前你发布了一条 DMARC 记录。所有的检查工具都显示它有效。但报告从未送达，久而久之你不再关注它，并默默地认为没有人伪造你的域名。你并不知道真相，你只是看不见。几乎所有此类问题都由两个原因导致，且这两个原因都不会影响 DMARC 记录本身的“完美”外观。

1. Your reporting address never agreed to receive them

1. 你的报告接收地址从未同意接收报告

This is in the spec and almost nobody knows about it. If your rua= address is on a different organisational domain from the domain publishing the record, RFC 7489 section 7.1 requires the destination to explicitly consent. The reason is obvious once you see it: otherwise anyone could point rua= at your mailbox and use the world’s mail infrastructure as a free DDoS. 这是规范中的要求，但几乎没人知道。如果你的 rua= 地址与发布记录的域名属于不同的组织域名，RFC 7489 第 7.1 节要求目标地址必须明确同意。原因显而易见：否则任何人都可以将 rua= 指向你的邮箱，并将全球邮件基础设施用作免费的 DDoS 工具。

Consent is a DNS record, published by the receiving domain: 同意是通过接收域名发布的一条 DNS 记录来实现的： <your-domain>._report._dmarc.<their-domain>. TXT "v=DMARC1"

So if example.com sends reports to dmarc@reports.vendor.com, then vendor.com has to publish: 因此，如果 example.com 向 dmarc@reports.vendor.com 发送报告，那么 vendor.com 必须发布： example.com._report._dmarc.reports.vendor.com. TXT "v=DMARC1"

Without it, conforming reporters send nothing at all. That includes Google, which is most of your report volume. You can watch this working in production. PayPal sends aggregate reports to a third party, and the authorisation record exists: 如果没有这条记录，合规的报告发送方将不会发送任何内容。这包括占据你报告总量大部分的 Google。你可以在生产环境中观察到这一点。PayPal 将聚合报告发送给第三方，且授权记录确实存在： paypal.com._report._dmarc.rua.agari.com. TXT "v=DMARC1;"

The practical consequence: not a Gmail address. You cannot put a Gmail address in rua=. Google is not going to publish yourdomain.com._report._dmarc.gmail.com on your behalf, and you can’t create records in their zone. Same for Outlook, Yahoo, or any address at a domain you don’t control. This is a common first move — publish DMARC, point reports at your personal inbox, wait. Nothing arrives, and nothing is wrong with the record. 实际后果是：不能使用 Gmail 地址。你不能在 rua= 中填入 Gmail 地址。Google 不会为你发布 yourdomain.com._report._dmarc.gmail.com，你也无法在他们的区域中创建记录。Outlook、Yahoo 或任何你无法控制的域名下的地址也是如此。这是常见的初次尝试——发布 DMARC，将报告指向个人收件箱，然后等待。结果什么都没收到，而记录本身却没有任何问题。

If you use a commercial DMARC service they normally publish these records during onboarding, often via a wildcard. If reports never start after you sign up, check this before anything else. When it doesn’t apply: reporting to your own organisational domain needs no authorisation. example.com sending to dmarc@mail.example.com is fine. 如果你使用商业 DMARC 服务，他们通常会在入驻期间发布这些记录，通常使用通配符。如果你注册后报告一直没有开始，请首先检查这一点。例外情况：向你自己的组织域名发送报告无需授权。例如，example.com 发送到 dmarc@mail.example.com 是没问题的。

2. There’s no mail server behind the address

2. 地址背后没有邮件服务器

Subtler, and easy to create by accident on a domain that only serves a website. You publish: 这更隐蔽，且容易在仅用于托管网站的域名上意外发生。你发布了： _dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

Self-referential, so no authorisation needed. Correct in every way. But if example.com has no MX record, senders fall back to its A record — the implicit MX rule in RFC 5321 section 5.1. On a web-only domain that A record points at a web server, which doesn’t speak SMTP. Every report bounces. The DMARC record is flawless. You just have no mailbox. 这是自引用的，因此无需授权。各方面都正确。但如果 example.com 没有 MX 记录，发送方会回退到其 A 记录——即 RFC 5321 第 5.1 节 中的隐式 MX 规则。在仅用于网页的域名上，该 A 记录指向的是 Web 服务器，它并不支持 SMTP 协议。每一份报告都会被退回。DMARC 记录完美无缺，只是你根本没有邮箱。

This bites hardest on marketing sites and defensive brand registrations — exactly the domains where you published DMARC as a hardening measure and are least likely to notice the silence. The fix doesn’t require running a mail server. A forwarding service will publish MX records for you and forward dmarc@ somewhere you actually read. 这种情况在营销网站和防御性品牌注册域名上最为严重——这些域名正是你为了加固安全而发布 DMARC 的地方，也是你最不容易察觉到“沉默”的地方。解决方法不需要运行邮件服务器。使用转发服务即可为你发布 MX 记录，并将 dmarc@ 的邮件转发到你真正会阅读的地方。

---

Checking both in about thirty seconds

在约 30 秒内检查这两个问题

# 1. What does your record actually say?
# 1. 你的记录内容是什么？
dig +short TXT _dmarc.example.com

# 2. If rua points off-domain, is it authorised?
# 2. 如果 rua 指向外部域名，是否已授权？
dig +short TXT example.com._report._dmarc.THEIR-DOMAIN.com
# Expect "v=DMARC1". Anything else means reports are refused.
# 预期结果为 "v=DMARC1"。其他任何结果都意味着报告被拒绝。

# 3. If rua points at your own domain, can it receive mail?
# 3. 如果 rua 指向你自己的域名，它能接收邮件吗？
dig +short MX example.com
# Empty means every report bounces.
# 为空意味着所有报告都会被退回。

A third possibility, but rule the others out first: Some providers only send aggregate reports once they see meaningful volume from a domain. A domain sending almost nothing may legitimately get few reports, particularly from smaller receivers. That’s a real explanation, but it’s also the comfortable one, so don’t reach for it early. The two DNS causes above are deterministic and fixable. Google will typically report on any domain with real traffic within a day or two. 第三种可能性（但请先排除上述原因）：一些服务商只有在看到域名有显著流量时才会发送聚合报告。几乎没有流量的域名确实可能收不到多少报告，尤其是来自小型接收方的报告。这虽然是一个合理的解释，但也是最容易让人“自我安慰”的借口，所以不要过早下结论。上述两个 DNS 原因是可以确定并修复的。Google 通常会在一两天内对任何有真实流量的域名发送报告。

Why this matters more than it sounds: The entire value of p=none is the reporting. That’s the whole point of the stage. If you’re sitting at p=none with broken reporting, you’ve done all the work of DMARC and got none of the benefit — no protection, because p=none blocks nothing, and no visibility either. You’re paying the setup cost and collecting nothing. Check it on the day you publish, not six months later when someone asks how the rollout is going. 为什么这比听起来更重要：p=none 的全部价值在于报告。这就是该阶段的全部意义所在。如果你处于 p=none 状态但报告功能损坏，你做了 DMARC 的所有工作却没得到任何好处——既没有保护（因为 p=none 不会拦截任何东西），也没有可见性。你付出了设置成本却一无所获。请在发布当天检查，而不是在六个月后当有人问起部署进展时才发现问题。

I maintain notspoofed, a free checker that tests both of these — whether an external rua= is actually authorised, and whether the reporting address can receive mail at all. It’s the failure mode I’ve seen most often and the one fewest tools look for. No signup, and checked domains aren’t logged. If you’ve had reports silently missing for months, I’d be curious which of the two it turned out to be. 我维护着一个名为 notspoofed 的免费检查工具，它可以测试上述两个问题——外部 rua= 是否已获得授权，以及报告地址是否确实能接收邮件。这是我见过最常见的故障模式，也是最少有工具会去检查的。无需注册，且不会记录检查过的域名。如果你几个月来一直没收到报告，我很想知道最终是哪种原因导致的。