The DMARC records sitting at p=none that never asked for a report

You’ve been asked to show that DMARC is doing something for your domain, and you have nothing to show because no reports have arrived. The likeliest reason is in the record itself. rua= is the tag inside a DMARC record that names the mailbox a receiving mail server sends its daily aggregate report to. A record with no rua= tag asks for nothing, so the receivers send nothing, and that’s why your inbox is empty.

What the tag asks for

DMARC has two halves. The policy tag, p=, tells a receiver what to do with a message that fails authentication: leave it alone (none), treat it with suspicion (quarantine) or refuse it (reject). The reporting tags tell the receiver where to send what it saw. rua= takes a mailto: address and asks for aggregate reports, which are XML files summarising, per sending IP address, how many messages claimed your domain over the day and whether they passed SPF and DKIM. ruf= asks for a copy of each individual failure, and few receivers still send those. The full tag set is on the DMARC pillar.

Receivers work through the tags they find. If rua= isn’t there, there’s no address to deliver to, and the receiver’s DMARC processing for your domain ends with the policy decision. Nothing gets queued or logged on either side, so nothing on your systems will tell you it happened, which is why the silence you’ve been asked to explain traces straight back to the record you published.

How the published records split

The September 2026 census read a DMARC record on 81,048,716 domains (basis: domains with a DMARC record, dmarc_present). Of those, 41,888,985 sit at p=none, which is 51.68% of the domains with a record. p=quarantine accounts for 21,650,300 and p=reject for 17,465,796. The census then looked inside each record for a rua=mailto: address.

Across the three policies together, 33,403,141 domains carry an rua= address, 41.21% of the domains with a DMARC record. ruf= appears on 7,624,883, 9.41% of the same set.

Read the right-hand column downwards and the pattern runs the wrong way. The policy that does nothing without reports is the one least likely to ask for them. Domains at quarantine ask most often, which fits how people get there: they read reports, fixed what the reports showed, tightened the policy and kept the tag. Domains at reject ask less than half the time, and some of that will be deliberate, since an operator who has finished the job may stop collecting, a reason that doesn’t apply at none because nothing has been finished yet.

The band that does no work

p=none is a monitoring policy. It changes nothing about what a receiver does with a failing message: the mail is delivered, filtered or dropped on whatever other grounds the receiver already had, and the DMARC result is written down and, if asked, reported. So the reports are the only thing you get out of p=none.

That makes the 33,651,068 domains at p=none with no rua= address, 80.33% of the p=none domains in the September 2026 census, the band to look at. All of those records resolve and show up as “DMARC: present” in a scanner that stops at existence, while blocking nothing and reporting nothing about what would have been blocked. If your record is one of them, the answer to “is DMARC working” is that it hasn’t started, and the fix is one tag.

While it sits there, anyone can send as you and the receiver will deliver or drop on the strength of its own filters, which is the situation described at can someone spoof my domain, except that without reports you wouldn’t find out it was happening.

Reading a record tag by tag

Your DMARC record lives in a TXT record at the name _dmarc.yourdomain.example, one label below the apex. A working monitoring record looks like this:

v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1

v=DMARC1 has to come first and has to be spelt exactly that way; receivers stop reading at anything else. p=none is the policy. rua=mailto:[email protected] names the reporting mailbox: the mailto: scheme is part of the value, and a bare address without it is a malformed URI that receivers ignore. You can list more than one address separated by commas, and you can cap the report size a receiver will send with a suffix such as !10m. ruf= names where failure copies go, if you want them. fo=1 asks for a failure copy when either SPF or DKIM fails, where the default of fo=0 only fires when both do.

You don’t need sp=, adkim=, aspf= or pct= for monitoring. Their defaults (subdomains inherit the policy, relaxed alignment, apply to 100% of mail) are what you want while you’re reading.

If your reports go to a processing service on a different domain, say collector.example, the receiver is entitled to check that collector.example agreed to accept reports about you before it sends anything there. It does that by looking up the TXT record at yourdomain.example._report._dmarc.collector.example and expecting to find v=DMARC1 in it. Report processors publish that record on your behalf, often as a wildcard, but if it’s missing the receiver may drop the report and, again, tell nobody.

Now check what your own record says. The scan reads the published record back tag by tag and reports whether an rua= address is present and well formed.

If the rua line comes back blank, that’s the finding, and everything below the table on this page applies to you.

When the tag is there and reports still don’t come

A present rua= narrows the search. The remaining causes are ordinary, and you can work through them in an afternoon.

Receivers report on mail they saw. If no message claiming your domain reached a given receiver during its 24-hour window, that receiver has nothing to say and sends nothing, so a domain that hardly sends gets hardly any reports. Send a message from your domain to a mailbox at a large consumer provider, then give it 48 hours, because reports are generated after the window closes and queued like any other mail.

Check the address for the kind of mistake a human reads past. A missing mailto:, a semicolon inside the URI, a space after the comma in a multi-address list, or a typo in the mailbox name will each cause the tag to be discarded, and a strict parser may discard the record with it. Copy your record into a text editor and compare it character by character against the example above.

Then look at whether the mailbox is refusing what arrives. Aggregate reports come as gzipped XML attachments, and a filter that strips compressed attachments, or a quota that’s already full, will bounce them silently from your point of view. Give reports a mailbox of their own, or use a processing service that receives them for you.

Where the record sits matters too. A DMARC record placed on the apex instead of _dmarc, a second DMARC record at the same name (receivers must treat two as none), or a subdomain record with its own rua= overriding yours will each break delivery in a way that a simple “is there a record” check won’t show.

Some receivers don’t send reports at all. The large mailbox providers do, and they carry most of the mail that matters. Many corporate gateways don’t, so a domain that only ever mails a handful of business partners can publish a perfect record and still see very little.

The order that gets you off none

Publish rua= today and leave the policy at none. Read a fortnight of reports. For each sending IP, decide whether it’s yours (the mail platform, the CRM, the invoicing tool, the helpdesk, the marketing sender) or somebody else’s. Add the ones that are yours to SPF and get DKIM signing switched on for them, one source at a time. Watch the pass rate for the sources you recognise climb towards 100%. When your own sources pass and the failures left are ones you don’t recognise, move to p=quarantine, read another fortnight, and then move to p=reject.

Skipping the reporting step is how a domain ends up parked at none for years. Without reports, moving to quarantine is a guess about which of your own systems will start failing, and nobody signs off a guess that might stop the invoices going out. So the domain stays at none because none is the only setting that can’t break anything, and it stays there because nothing ever arrives to change the picture. Add the tag and you have a fortnight of reading instead, with a date you can put in the write-up.

What to hand over

The proof you were asked for is the reports. After a fortnight you can show which sources are sending as your domain and how much of that mail passes authentication, and you can put a date on the move to quarantine. That’s what “DMARC is working” looks like at p=none, and it’s more than a record at reject with no rua= can show, because that record can’t say what it’s blocking.

If the record is at none and has no rua=, then the first line of your write-up is that no data exists yet, and the second line is the tag you’re adding to change that. The same reports feed anything you do later with BIMI, which needs an enforcing policy, and the only safe way to reach an enforcing policy is to read them first.

Figures as of 5 September 2026, from the September 2026 edition of the defaults.exposed census. Census numbers move every month; the current values are on the census data page.