DMARC at p=none: what it does, and what it doesn't

What p=none actually does#

A DMARC record tells receivers two things: what to do with mail that fails authentication for your domain, and where to send reports about it. At p=none the first answer is “nothing special”: failing mail is handled as if no policy existed. The second answer still holds. If the record names a report address, receivers send you aggregate reports: which servers sent mail as your domain, how much, and whether it passed.

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

That makes p=none genuinely useful, and it is also what Gmail, Yahoo and Outlook.com require as a minimum of bulk senders (Google, Microsoft). Pages that call it “the same as no record” are wrong about the reports and wrong about the requirement.

p=none gets you visibility. It does not stop anyone sending mail as you.

Where it goes wrong#

1. Staying at p=none for good

Monitoring is meant to be a phase. A domain that stays at p=none indefinitely has told every receiver that spoofed mail claiming to be from it should be delivered like anything else. The reports will show the spoofing. Nothing will stop it.

2. A record with no report address

p=none without an rua tag is a policy that does nothing and a monitor that tells no one. It satisfies a checkbox and produces no information.

3. Reports sent somewhere that cannot receive them

If your report address is on another domain, a reporting provider’s for example, that domain has to publish a record saying it accepts reports for you. Without it, conforming receivers do not send the reports (RFC 9990, section 4). The record looks fine; nothing ever arrives.

example.com._report._dmarc.reports.example.net.  TXT  "v=DMARC1"

4. Reports nobody reads

Aggregate reports arrive as compressed XML, daily, from every large receiver. Unread, they are the same as no reports. Read raw, they are thousands of rows that are mostly forwarding and mailing lists. The work is in separating your own services from forwarders from impostors, and that is the part that usually gets skipped.

5. Moving to reject before the data says you can

The failure people fear is real. A domain that publishes p=reject while one of its own services is not authenticating correctly will have that service’s mail rejected: the invoicing platform nobody remembered, the CRM a sales team signed up for. It is why domains stall at p=none, and the fix is evidence, not courage.

6. Relying on SPF alone

SPF breaks whenever a message is forwarded, because the forwarder becomes the sending server. DKIM survives forwarding. The DMARC standard is explicit: a domain that publishes p=reject must not rely solely on SPF and must DKIM-sign its mail (RFC 9989, section 7.4).

7. Forgetting what reject does to mailing lists

This one is new in the standard. Mailing lists often modify messages in ways that break DKIM, so a strict policy can get your users’ posts rejected, and list software may then unsubscribe the recipients who bounced them. RFC 9989 now says that domains whose users post to internet mailing lists should not publish p=reject, and that any that do should first run p=none for at least a month, then p=quarantine for as long again, and compare the results (RFC 9989, section 7.4; RFC 7960).

For a domain that sends only its own transactional and marketing mail, reject remains the right end state. For a domain full of people who join discussion lists, quarantine may be where it should stay.

How to tell when a stricter policy is safe#

1. Collect reports for long enough to see every sending cycle: weekly batches, month-end invoicing, the quarterly newsletter. A month is a sensible minimum.
2. Account for every source that passes or fails. Each of your services should pass, aligned, on its own. Failures should be forwarding, lists, or impostors you can name as such.
3. Check that your own mail passes on DKIM, not on SPF alone, so it survives forwarding.
4. Move to p=quarantine first, watch the reports for as long again, and only then consider p=reject, bearing in mind the mailing-list advice above.
5. Cover your subdomains. sp sets the policy for existing subdomains, and the new np tag sets it for subdomains that do not exist, which are a favourite of spoofers.

The previous version of DMARC let you apply a policy to a percentage of mail with pct. That tag is gone. Its replacement, t=y, asks receivers to apply your policy one level lower while you test: reject is treated as quarantine, and quarantine as none (RFC 9989).

• Scan your domain to see your current policy, whether your report address can receive, and which services are authorised to send.
• Check a real message to see whether it aligns, and on which mechanism.