DMARC's p=none policy does nothing useful — here's what to do instead

DMARC (Domain-based Message Authentication, Reporting and Conformance) ties SPF and DKIM together and tells receiving mail servers what to do when authentication fails. It has three enforcement policies:

• p=none — collect reports, do nothing about failures
• p=quarantine — deliver failing messages to the spam folder
• p=reject — refuse to deliver failing messages at all

The vast majority of organisations that have a DMARC record are running p=none. This is correct when you first set up DMARC — you need the reports before you can safely enforce. But many organisations set it up and never progress. A DMARC record at p=none with no plan to move to enforcement is not a security control. It’s a reporting subscription.

What the reports actually tell you

When you set a rua= address in your DMARC record, receiving providers send aggregate reports to that address. Each report shows, for a given source IP sending as your domain:

• How many messages were sent
• Whether SPF passed or failed
• Whether DKIM passed or failed
• Whether DMARC alignment passed (the authenticated domain must match your From address domain)

Reading these reports shows you where authentication is failing before you enforce anything. Common findings:

• A cloud service sending as your domain without DKIM configured
• Marketing emails with a From address at your domain but signed by the ESP’s domain
• An old server nobody remembered was still sending
• Phishing attempts using your domain’s exact address

When to move to enforcement

Before moving to p=quarantine or p=reject, you need:

1. All legitimate sending sources covered by SPF
2. DKIM configured and aligning on all legitimate sending sources
3. DMARC aggregate reports showing consistent >95% pass rates from all legitimate sources

Once you’re there, move to p=quarantine first and monitor for a week. If legitimate mail is passing and there’s no increase in complaints, move to p=reject.

Relaxed and strict alignment

DMARC alignment has two modes, and the default is not the strict one. This catches people who assume a passing SPF or DKIM check must therefore align.

• Relaxed (the default) — the organisational domains must match. A DKIM signature from mail.yourdomain.com aligns with a From address at yourdomain.com, because they share an organisational domain.
• Strict — the domains must match exactly. mail.yourdomain.com does not align with yourdomain.com.

You set them independently with adkim for DKIM and aspf for SPF, each taking r for relaxed or s for strict:

v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:dmarc@yourdomain.com

Relaxed is the right default for almost everyone. Strict alignment breaks any sending path that uses a subdomain — which is most email service providers, most transactional mail platforms, and often your own internal systems. Turn it on only when you have a specific reason and have confirmed in the reports that every legitimate source still aligns.

The tags worth knowing

A DMARC record is a TXT record published at _dmarc.yourdomain.com. Most of the tags are optional and most people only ever use three of them.

• v=DMARC1 — mandatory, and it must be the first tag in the record.
• p= — the policy for the domain itself: none, quarantine or reject.
• sp= — the policy for subdomains. If it is absent, subdomains inherit p=, which is usually what you want. Set it explicitly if you need a subdomain treated differently from the root.
• pct= — the percentage of failing mail the policy is applied to. This is the ramp control that makes enforcement safe, and it applies only to quarantine and reject.
• rua= — where aggregate reports go. This is the one that makes DMARC useful.
• ruf= — where forensic (per-message) reports go. Most large providers do not send these at all, for privacy reasons, so do not build a process that depends on them.
• adkim= / aspf= — alignment mode, as above.
• fo= — controls when forensic reports are generated. Only relevant if ruf= is in use.
• ri= — the aggregate reporting interval in seconds. The default is 86400 (daily) and providers commonly ignore anything shorter.

Sending reports to a domain you do not own

If your rua= address is at a different domain from the one publishing the record — an external DMARC analytics vendor, or your MSP — the receiving domain has to confirm it is willing to accept them. Without that confirmation, most providers will not send the reports, and you get silence that looks exactly like “no mail is failing”.

The confirmation is a TXT record published on the destination domain:

yourdomain.com._report._dmarc.reportvendor.example

containing v=DMARC1. Any competent vendor documents this and most set it up for you, but it is worth knowing it exists — it is a common reason a correctly formed DMARC record produces no reports at all.

Record mistakes that quietly break everything

• Two DMARC records on the same host. Publishing a second TXT record at _dmarc does not merge with the first; per RFC 7489 the result is that no policy is applied. This usually happens when a vendor adds a record during onboarding and nobody removes the old one.
• The record on the wrong host. It belongs at _dmarc.yourdomain.com, not on the root domain next to SPF. A DMARC record published at the root does nothing.
• v=DMARC1 not first, or a stray character making the record unparseable. A malformed record is treated as no record.

Check for these before concluding that a domain “has DMARC”. Publishing a record and having a working policy are different states, and the gap between them is silent.

Common alignment failures

The marketing email problem. Your marketing team sends from newsletter@yourdomain.com through an ESP. The ESP signs with DKIM using their domain, not yours. SPF passes because the ESP is in your SPF record, but DMARC alignment fails because the From domain doesn’t match the signing domain. Fix: configure DKIM for your domain on the ESP platform.

The subdomain problem. DMARC applies to the domain it’s published on. Subdomains need their own DMARC record or inherit via the sp= parameter. If sp= isn’t set, subdomains inherit the root domain policy — which may not be what you want.

The forwarded email problem. Forwarded mail commonly fails DMARC because the forwarding server changes the envelope sender (breaking SPF) and doesn’t re-sign with DKIM. This is expected behaviour — account for it in your analysis but don’t use it as a reason to delay enforcement.

What enforcement actually buys you

It is worth being precise about this, because DMARC is often oversold.

What p=reject stops: mail that uses your exact domain in the visible From address without authenticating. That is direct-domain spoofing, and it is the form of impersonation your customers and staff are least equipped to spot, because the address really is yours.

What it does not stop: lookalike domains, display-name spoofing, compromised mailboxes sending genuinely authenticated mail, and everything that arrives from somewhere other than your domain. DMARC is one control, and a narrow one.

There is a second, more practical benefit. Enforcement is a prerequisite for BIMI — the standard that puts your logo next to your messages in supporting mailboxes — and it increasingly features in security questionnaires and cyber insurance assessments. For Australian firms that handle client money or personal information, “we are at p=none” is becoming an answer that invites follow-up questions.

None of which changes the order of operations. Get the reports, fix the failing sources, then enforce. Enforcing before the sources are clean does not improve security — it just stops some of your own mail.

A practical enforcement path

1. Publish v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
2. After two weeks of reports, identify all failing sources and fix authentication for each
3. Move to p=quarantine; pct=10 (applies to 10% of failing mail) — watch for legitimate mail landing in spam
4. Increase pct incrementally to 100
5. Move to p=reject once p=quarantine at 100% runs cleanly for two weeks

If you’d rather not manage that ramp-up and the ongoing report review yourself, Mail Shield handles DMARC enforcement as a managed service.

Check your current DMARC configuration →

Working through the whole stack rather than just DMARC? The email authentication checklist covers SPF, DKIM and DMARC in the order they need to be fixed.

Wondering how common this is? In our benchmark of 316 Australian accounting firms, 75.3% had no enforced DMARC policy — most of them sitting on exactly the p=none configuration this article describes.

Sources

• RFC 7489: DMARC
• Google & Yahoo email sender guidelines