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

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.

1. Your reporting address never agreed to receive them

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.

Consent is a DNS record, published by the receiving domain:

<your-domain>._report._dmarc.<their-domain>.  TXT  "v=DMARC1"

Enter fullscreen mode Exit fullscreen mode

So if example.com sends reports to [email protected], then vendor.com has to publish:

example.com._report._dmarc.reports.vendor.com.  TXT  "v=DMARC1"

Enter fullscreen mode Exit fullscreen mode

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:

paypal.com._report._dmarc.rua.agari.com.  TXT  "v=DMARC1;"

Enter fullscreen mode Exit fullscreen mode

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.

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 [email protected] is fine.

2. There’s no mail server behind the address

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:[email protected]"```

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](https://www.rfc-editor.org/rfc/rfc5321#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.

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.

## Checking both in about thirty seconds



```bash
# 1. What does your record actually say?
dig +short TXT _dmarc.example.com

# 2. If rua points off-domain, is it authorised?
dig +short TXT example.com._report._dmarc.THEIR-DOMAIN.com
#    Expect "v=DMARC1". Anything else means reports are refused.

# 3. If rua points at your own domain, can it receive mail?
dig +short MX example.com
#    Empty means every report bounces.

Enter fullscreen mode Exit fullscreen mode

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.

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.

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.