Nearly One Third of p=none DMARC Records Contain Only Two Tags

We were poking through public DNS observations collected by CipherCue when one very small DMARC record kept showing up:

v=DMARC1; p=none;

The dataset contained 23,986 DMARC records. Of the 12,078 using p=none, 3,919 contained those two tags and nothing else. That is 32.45%.

v=DMARC1 says “this is a DMARC record”. p=none asks receivers to make no DMARC-specific change to their handling of failing mail. There is no rua address asking them to send aggregate reports back.

There is nothing invalid about that record. But calling it “monitoring mode” is a bit generous when you have not asked anyone to send you the monitoring data.

p=none does not automatically mean you are monitoring anything

The usual reason to start with p=none is to see what is using your domain before you tell receivers to quarantine or reject failures. That only works if the reports have somewhere to go.

RFC 9989's definition of Monitoring Mode includes both p=none and the domain owner receiving aggregate reports. It also says that when rua is missing, receivers must not generate those reports for the domain.

We found 5,476 p=none records without rua, or 45.34% of the group. Maybe their operators use other logs or another monitoring system. We cannot see that in DNS. What we can see is that the DMARC record itself asks for no aggregate feedback.

The p=quarantine row is stranger. We found 1,545 records, 26.02% of that group, asking receivers to treat failing mail as suspicious while asking for no aggregate reports about it.

Again, there may be another source of evidence. If there is not, how does the operator spot an authorised sender that suddenly starts failing DMARC?

Aggregate-report requests were more common with enforcement policies than with p=none.

Are people copying the same record?

My first thought was copy-and-paste. We lowercased the 5,476 p=none records without rua, removed whitespace and ignored a final semicolon. In 3,919 cases, 71.57% of the group, all that remained was v=DMARC1 and p=none.

The exact string v=DMARC1; p=none; appeared 2,277 times. Another 1,305 records were the same apart from the final semicolon. Only 80 of the 5,476 records asked for message-specific failure reports using ruf. The other 5,396 asked for neither kind of report.

That certainly looks like something a shared example, a setup tool or repeated copy-and-paste could produce. But DNS has no provenance field. It cannot tell us who typed the record, where they got it or whether they understood what it did.

We also checked whether these were mostly parked domains with a token DMARC record. They were not, at least by the DNS evidence available to us. Of the 3,919 minimal records, 3,751, or 95.71%, also had both MX and SPF. That still does not prove they were sending mail, but they did have the usual DNS pieces of a mail setup.

There is actually a good reason to publish the minimum

Then I checked the sender rules from the big mailbox providers. They give organisations a practical reason to stop at the two-tag record.

The two-tag record does not make a sender compliant on its own. SPF, DKIM and alignment still have to meet the rest of each provider's rules. But it can satisfy the DMARC-record part without setting up an address to receive reports.

That does not prove why any of the 3,919 domains published it. It does explain why the minimum is useful: it can satisfy the DMARC part of a sender rule even if nobody has built the reporting side yet.

A DMARC record is not the same thing as doing DMARC

The RFC's reason for starting at p=none is fairly practical. Aggregate reports help you find a forgotten server, a third-party sender or an authentication mistake before you turn on enforcement.

The aggregate report format includes the source IP, message count, SPF and DKIM results, alignment and the receiver's disposition. That tells you what receivers are actually seeing. It does not tell you whether a source is legitimate; somebody still has to match it to the organisation's approved senders.

SenderLedger starts with those reports. It turns the observed sources into a sender inventory and lets operators classify traffic as authorised, unknown, unauthorised or forwarding-related. The point is to work out what needs fixing before moving to enforcement.

If your record is currently v=DMARC1; p=none;, there is nothing inherently wrong with it. I would just ask one more question: what are you planning to learn from it?

Method: We used public DNS observations already stored by CipherCue for 42,822 tracked domains. The period runs from 00:00 UTC on 18 August to 23:59 UTC on 24 August 2026. Where an entity and domain had more than one observation, we used the latest one. That left 23,986 DMARC records. We parsed p, rua and the other tags from the raw TXT, allowing whitespace around the equals sign. The policy table leaves out 25 records where p was missing or not recognised.

Limits: For the two-tag count, we lowercased each record, removed whitespace and ignored a final semicolon. We did not discard any other tag or value. MX and SPF came from the same stored observation. We counted rua when the tag was present, but did not check whether the destination was valid, authorised or reachable. This is a tracked set, not a random sample or an internet census, and we did not run a new DNS scan for the article. DNS shows what was published. It does not show whether the record was copied, generated or written deliberately; whether reports arrived or were read; whether another monitoring system exists; or whether the domain sent mail during the period.