dmarcexpert
All posts

Why your DMARC reports are not arriving, and how to check

A reporting service only gets your DMARC reports if it has authorized your domain in DNS. Without it, reports vanish silently. How to check, and how to fix it.

By dmarc.expert

If your DMARC record sends reports to a different domain, such as a monitoring service, that domain has to publish a DNS record saying it accepts reports for you. If that record is missing, receivers quietly throw your reports away. Nothing bounces, nothing warns you, and your own DMARC record still looks perfect. The fix takes a minute once you know to look, and you can check it for free with Inspect My DNS.

The symptom: a valid record and an empty dashboard

You publish a DMARC record with a rua= tag pointing at your reporting service, something like this:

v=DMARC1; p=none; rua=mailto:reports@dmarc-service.example

A DMARC checker says the record is valid. A week later your dashboard is still empty, or it shows a handful of small receivers but nothing from Google or Microsoft. It is tempting to assume the service is broken, or that your domain does not send enough mail to be worth reporting on. Often the real cause is one missing TXT record on the service’s side.

Why receivers need permission to send you reports

The rua= tag (and its sibling ruf=, for failure reports) can name any email address on the internet. Without a safeguard, anyone could publish a DMARC record that points at someone else’s mailbox and have Google and Microsoft flood it with reports. DMARC closes that hole with a step called external destination verification. It was in the original specification, RFC 7489, and carries over into DMARCbis aggregate reporting, RFC 9990.

The rule is simple. When the report address is on a different organisational domain from the domain the record covers, the receiver checks before it sends. It looks up a TXT record built from both names:

yourdomain.com._report._dmarc.dmarc-service.example

If that name returns a record starting with v=DMARC1, the reporting domain has said “yes, send me reports for yourdomain.com”, and the receiver goes ahead. If it returns nothing, the receiver drops the report for that address. It does not tell you, because there is nobody to tell: the only contact it has is the address it has just decided not to trust.

If the report address is on the same organisational domain, for example rua=mailto:dmarc@yourdomain.com in the record for yourdomain.com or one of its subdomains, no check is needed and none is made.

How services publish the authorization

Reporting services handle this in one of two ways, and it is worth knowing which yours uses.

  • A wildcard record. The service publishes *._report._dmarc.dmarc-service.example with the value v=DMARC1, which authorizes reports for every domain at once. These rarely break, because there is nothing per customer to forget.
  • A record per customer domain. The service publishes a specific record for each domain you add in its dashboard. This is tidier, but the record only appears once the domain is set up on their side, and it disappears if you remove the domain or cancel.

The second approach is where most silent failures come from.

The common ways it goes wrong

  • You updated DNS before adding the domain to the service. The rua= points at the service, but the service has not published your authorization yet, so the first days or weeks of reports are lost.
  • You moved services and left the old address behind. Your record still names the old provider, which has deleted your authorization since you canceled. Reports go nowhere, and the new service never sees them.
  • One of several addresses is not authorized. A rua= can list more than one address, separated by commas. Each destination is checked on its own, so one unauthorized address loses its copy even while the others work.
  • A typo in the reporting domain. dmarc-servce.example is a perfectly valid address as far as your DMARC record is concerned. It just has no authorization record, and never will.
  • Reports go to another domain you own. Sending reports for yourcompany.co.uk to a mailbox at yourcompany.com counts as external. You need to publish yourcompany.co.uk._report._dmarc.yourcompany.com yourself.

How to check it with Inspect My DNS

Inspect My DNS runs a full DNS and email health report on any domain, and one of its checks is exactly this one. Enter your domain and look for DMARC report authorization in the mail authentication section. It reads the reporting addresses in your DMARC record, looks up the authorization record at each destination, and tells you whether each one has agreed to accept your reports.

For dmarc.expert itself, the check reads:

reports.dmarcloop.net has authorized the DMARC reports sent to it.

That one line is the difference between reports that arrive and reports that disappear. It is worth checking whenever you set up DMARC, change reporting provider, or add a new address to rua=, and it is a quick sanity check if your reports suddenly dry up. The same report also covers your DMARC policy, SPF lookup count, DKIM keys and MTA-STS, so you see the reporting problem in context rather than in isolation. You can open the dmarc.expert report to see what a passing result looks like.

How to check it by hand

If you prefer the command line, build the name yourself and ask for its TXT record:

dig +short TXT yourdomain.com._report._dmarc.dmarc-service.example

Replace yourdomain.com with the domain the DMARC record is for, and dmarc-service.example with the domain after the @ in your rua= address. An answer containing v=DMARC1 means you are authorized. An empty answer means receivers will discard reports sent to that address. Repeat it for every address in rua= and ruf=.

How to fix it

If the authorization is missing, the fix depends on who owns the reporting domain.

  • A reporting service. Make sure the domain is added and verified in the service’s dashboard, then check again. If it is set up and the record is still missing, raise it with their support; it is their DNS to change, not yours.
  • Your own second domain. Publish a TXT record at yourdomain.com._report._dmarc.yourotherdomain.com with the value v=DMARC1.
  • An old provider. Take their address out of your rua= tag. A dead address costs you nothing in delivery, but it hides the fact that the reports you think you are collecting are going nowhere.

Once it is fixed, give it a day or two. Aggregate reports are usually sent once a day, covering the previous day, so the first ones arrive 24 to 48 hours after the record is in place.

Other reasons reports might not arrive

If the authorization checks out and reports are still thin, a few other things are worth ruling out:

  • There is no rua= tag at all. A record of just v=DMARC1; p=none is valid, but it asks for no reports, so you get none.
  • Your volume is low. Receivers only report on mail they actually saw. A domain that sends a few dozen messages a week may only hear from one or two providers.
  • Your own mailbox is filtering them. If reports go to an address you host yourself, check spam filtering and attachment size limits. Reports arrive as compressed XML attachments, which some filters treat with suspicion.
  • You are waiting on failure reports. Many large receivers do not send ruf= failure reports at all, for privacy reasons. Aggregate reports are the ones to rely on.

Reports are the whole point of the p=none stage, as we explain in start with p=none. A rollout running on missing reports is a rollout running blind, and it is one of the quieter reasons DMARC projects stall at p=none. One DNS lookup is a small price for knowing the data is actually arriving.