Not receiving DMARC reports: the causes and the fix

v=DMARC1; p=none; rua=mailto:dmarc@example.com

3. The record is on the wrong host name

A DMARC record must be published on _dmarc.example.com, not on the root example.com. This is a frequent confusion: the value v=DMARC1; … gets pasted into a TXT record at the root, and receivers never find it, because they look specifically on the _dmarc sub-name. The TXT record's host is worth checking first. If it sits at the root, it needs republishing on _dmarc.

4. The record has a syntax error

An invalid record can be ignored entirely. Faults that break parsing: v=DMARC1 misspelled or not in first position, two separate DMARC records on _dmarc (there must be only one), missing semicolons, or stray quotes added inside the value. A single one of these defects and the receiver treats it as no usable DMARC policy — so no report.

5. The external destination isn't authorized

Here's the subtlest trap, and a very widespread silent cause. When rua points to an address on a domain different from the one being reported on (say an analytics service), that receiving domain must publish an authorization record, failing which receivers refuse to send the reports.

Concretely, for example.com to send its reports to dmarc@vendor.com, the vendor.com domain must publish:

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

If this record is missing, nothing arrives via that external address, even with perfect rua syntax. The full mechanism is detailed in configuring the rua address. The simplest test: rua pointed temporarily at an address on the domain itself, which requires no authorization. Reports that then arrive isolate the cause.

6. The domain receives too little mail

An aggregate report is only sent by a receiver that received mail claiming to come from the domain. A domain that sends very little — or whose name nobody is spoofing yet — simply gives receivers little to report. Small, low-volume domains naturally get fewer reports, sometimes only from a few large providers. It's not a bug: it reflects the real traffic. A test email sent from the domain to a Gmail or Outlook address should produce a report from that provider the next day. That's actually the best isolated test: it reliably generates observable traffic at a provider that reliably sends reports — and if nothing arrives after it, the problem lies in the configuration, not the volume.

7. Reports arrive… but in spam

A frequent irony: the reports do arrive, but the mail system files them as spam. The compressed XML files sent by automated servers look, to a spam filter, like suspicious mail. Before silence is declared, the junk folder of the rua address deserves a look. Reports found there call for a rule routing them to a dedicated folder — which recovers, in one go, all the history presumed lost.

8. Not all receivers send reports

Finally, sending aggregate reports isn't universal. The vast majority of large providers (Gmail, Yahoo, Outlook, and many others) send them, but some small mail servers don't emit any at all. So a report never arrives from every receiver of a domain's mail — only from those who participate. That's normal, and coverage from the major players is more than enough for a reliable view of the traffic. The analogy holds: a report from every mailbox on earth is no more necessary to gauge a domain's health than a pollster needs to question every single voter. A handful of high-volume providers observe the overwhelming majority of the mail, so their reports paint an accurate picture even when a long tail of small servers stays quiet. Chasing reports from every last receiver is effort spent for no added insight.

Prevention: a rua address built to last

Many report-silence cases are born the day the address is chosen. Pointing rua at a personal mailbox works — until that person leaves, the account is deactivated, and the reports bounce into the void without anyone noticing. A mailbox that quietly fills up produces the same symptom: receivers try to deliver, the message is refused, and from the outside it simply looks like silence. A dedicated service address is the safer choice, with access delegated to more than one person, kept out of aggressive auto-cleanup rules, and with enough quota headroom for a steady stream of attachments. It's a small decision at setup time that removes an entire family of future outages — the kind that surface months later, precisely when the history matters most.

Why this silence deserves a fast fix

A domain with no reports might look like it "works anyway" — after all, the policy is published. That's a dangerous illusion. Without reports, the operator is flying blind: nothing shows whether a legitimate source is failing alignment, or whether an attacker is already testing the name. Worse, hardening becomes unsafe, because the decision to move to quarantine then reject rests entirely on what the reports show. A domain stuck at p=none with no reporting combines the worst of both worlds: no protection, and no visibility to earn it.

That's why report silence isn't a cosmetic detail to handle "when we have time": it's a blocker on the critical path to enforcement. The diagnosis above deserves to be done in the first days after publishing, not months later, when the DMARC project has visibly stopped moving and nobody knows why.

A special case: reports that suddenly stop

The scenario differs when reports were arriving and then stopped. There, the "beginner" causes (wrong host, missing rua) are excluded, since it was working. The culprit is a recent change:

• A DMARC record rewritten by mistake during a DNS migration or a tooling change, which removed or mangled the rua tag.
• A rua address that no longer exists — the mailbox was deleted, or the forward to the analytics service broke.
• An expired or removed external authorization on the vendor side, where an external destination is in use.
• A spam filter that got more aggressive, and started capturing the reports that used to land in the inbox.

Comparing the current record with the one that worked closes the case fast: the cause of a sudden stop is almost always a dated change, and dated changes can be tracked down. Where a short changelog of DNS edits exists — even a note in a shared document — this diagnosis becomes a two-minute lookup rather than an investigation.

The diagnostic method, summarized

Facing report silence, the causes come in this order:

1. 48 hours of patience — reports are daily.
2. The presence and syntax of rua (mailto:, not ruf).
3. The host name — on _dmarc, not the root.
4. The overall syntax — one record only, v=DMARC1 first.
5. A test with an address on the domain itself, to rule out the external-authorization trap.
6. A test email to Gmail/Outlook, to generate traffic to report.
7. A look in the spam folder.

Nine times out of ten, the culprit is in the first five points — and most often, it's either impatience or the missing external authorization. This order isn't arbitrary: it puts the most common and least costly-to-rule-out causes first, so no one loses an hour on a rare case before eliminating the obvious one.

To settle quickly between "the configuration is broken" and "it just needs more time," the free DMARC analyzer returns an immediate verdict: whether the record is valid, whether rua is correctly formed and readable by receivers, and thus whether the problem is the configuration or simply the delay. It's the fastest way to know which side to look on — and it turns a vague "nothing's happening" into a concrete next step, actionable today.