A DMARC record with no policy tag

A TXT record at _dmarc. plus your domain starts v=DMARC1 but carries no p= tag. Under RFC 9989 §4.10.1 the outcome splits on one other tag. With a valid rua, a receiver acts as if the record said p=none. Without one, no DMARC processing is applied at all — the same practical position as publishing nothing, while your DNS still shows a record. This page covers which case you are in and the tag that settles it.

Measured 2026-09-09: 1 of 429 audited domains (0.2%) published a v=DMARC1 record with no p= tag, against 93 of 429 (21.7%) with no DMARC record at all. That single record carried no rua either, so it falls in the arm that receives no DMARC processing. Rare, and silent when it happens. These are domains someone had a reason to check, so this is an upper bound and not an internet-wide rate.

What was observed

A TXT record exists at _dmarc. plus your domain and begins v=DMARC1, but it carries no p= tag. The record is syntactically valid. It simply states no assessment policy.

This is the failure mode that looks fixed. A monitoring check that asks only “is there a DMARC record?” answers yes.

The outcome splits on one tag

RFC 9989 §4.10.1 gives two different results for the same missing p, and which one you get depends on whether a valid rua is present:

With a valid rua — a Mail Receiver acts as if the record contained p=none and continues processing. You get monitoring, and reports, and no enforcement.
Without one — no DMARC processing is applied to the message at all. That is the same practical position as publishing no record, while your DNS still shows a DMARC record to anyone checking.

The second case is the one worth finding. It is indistinguishable from the first at a glance and it is not distinguishable at all from a check that only asks whether the record exists.

How to verify it yourself

Read the record
```
dig +short TXT _dmarc.example.com
```
Confirm a policy tag is present — no output means no policy stated
```
dig +short TXT _dmarc.example.com | grep -o 'p=[a-z]*'
```
Then check for a reporting address, which decides which of the two outcomes applies
```
dig +short TXT _dmarc.example.com | grep -o 'rua=[^;]*'
```

Check this domain Reads the live record and reports the policy it publishes, or that it publishes none.

The exact record to publish

Add the policy tag explicitly. Even where the standard would infer p=none for you, writing it removes the ambiguity for every tool and every person who reads the zone afterwards:

Before — no policy tag, no rua: outside DMARC processing entirely

v=DMARC1; adkim=s

After — states the policy, and asks for the reports

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

What can break: nothing, if you add p=none. It asks for no handling change. Going straight to p=quarantine or p=reject from a record that was never processed is the risk: you move from no DMARC evaluation at all to an enforcing policy in one edit, without ever having read a report, and any legitimate sender that is not aligned is affected from that moment.

Examples

No policy, no rua — no DMARC processing applied

v=DMARC1; adkim=s; aspf=s

No policy, valid rua — treated as p=none

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

No policy, no rua — a percentage with no policy to apply it to

v=DMARC1; pct=100

Explicit — the minimum record that states its own policy

v=DMARC1; p=none

Explicit — monitoring with reports

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

What the standard says

RFC 9989 §4.10.1: “If a retrieved DMARC Policy Record does not contain a valid ‘p’ tag … If a ‘rua’ tag is present and contains at least one syntactically valid reporting URI, the Mail Receiver MUST act as if a record containing ‘p=none’ was retrieved and continue processing. … Otherwise, the Mail Receiver applies no DMARC processing to this message.”

§4.7 states the tag's status directly: p is “RECOMMENDED for DMARC Policy Records”. This changed. RFC 7489 §6.3, which 9989 obsoletes, made p REQUIRED and said a policy record must carry v and p. A checker written against 7489 will call a p-less record invalid; under the current standard it is valid and its effect depends on rua.

What happens to a DMARC record with no p= tag?

Under RFC 9989 §4.10.1 it depends entirely on whether a valid rua tag is present. With one, a Mail Receiver acts as if the record said p=none and continues. Without one, it applies no DMARC processing to the message at all.

So is a record with no p= tag broken or not?

Neither, exactly, and that is why it is worth its own page. It is a syntactically valid record that states no assessment policy. With rua it degrades to monitoring; without rua it takes your domain out of DMARC evaluation entirely, which is the same practical position as publishing nothing.

Is this the same as p=none?

With a valid rua tag present the effect is the same, because the standard says to act as if p=none was retrieved. Without rua it is not the same at all: p=none still gets DMARC processing, and a record with neither p nor rua gets none.

Did this change from RFC 7489?

Yes, and it is the reason to check which RFC you are reading. RFC 7489 §6.3 made p REQUIRED and said a policy record must carry v and p. RFC 9989 §4.7 makes p RECOMMENDED and defines the fallback. A tool written against 7489 may still report a p-less record as invalid.

Why would a record have no p= tag?

Most often it was truncated or hand-edited down to a fragment, or built by pasting only the alignment or reporting tags. A record like v=DMARC1; adkim=s has real tags in it, which is why it survives a glance.

How do I fix it?

Add the p tag. If you are not ready to ask for a handling change, p=none is the explicit form of what the standard already infers when rua is present, and it removes the ambiguity for anyone reading your DNS.

Does the tag order matter?

The v tag must be first: RFC 9989 §4.7 says if it is not first, is absent, or is not DMARC1, the entire record MUST be ignored. Beyond that, order is not constrained the way 7489 constrained it.

How common is this?

Rare. In our own audited corpus it was 1 domain in 429 on 2026-09-09, against 93 with no record at all. It is worth documenting because it is silent, not because it is frequent.

What we do not claim

We report what your DNS publishes and what RFC 9989 says a conforming evaluator does with it. We do not state what any particular mailbox provider will do: those decisions are theirs, they are not published, and we cannot measure them from here.

Reviewed by Venkat Nookala, last reviewed 2026-09-09.