From p=none to p=reject: how to enable DMARC enforcement in 2026

The scariest character in the DMARC record is p=reject.

Most domains stay stuck at p=none (monitoring only) forever because admins are terrified of blocking the CEO’s email or a critical client invoice.

This fear is healthy. But p=none provides zero protection against spoofing. To actually secure your domain, you need a plan. Even if you think that you don’t, you do. Trust me. Start by inventorying all your senders.

The staged rollout path

Never jump straight to reject. Follow this ladder:

Start with p=none and collect data for at least 2-4 weeks. Use a monitoring tool to inventory all legitimate senders and fix their alignment.

Once you have a complete picture, move to p=quarantine with t=y. This asks receivers to apply the next-lower policy while you test, so you can see what would happen without asking receivers to quarantine yet. Your record will look like v=DMARC1; p=quarantine; t=y; rua=...

After a week or two without complaints, remove t=y. Now failing mail is handled under p=quarantine. This stage is relatively safe because legitimate mail isn’t deleted, just foldered. Monitor support tickets closely.

When you’ve had weeks of silence on the complaint front, decide whether p=reject fits the domain. It can be appropriate for transactional or marketing-only domains. For domains hosting general-purpose human mailboxes, RFC 9989 recommends p=quarantine as the safer terminal policy.

The hidden blocker: SPF PermError

Before you enforce, check your SPF record. SPF has a hard limit of 10 DNS lookups.

If you include Google, Office 365, SendGrid, Zendesk, and Salesforce, you will likely hit 12 or 13 lookups.

An SPF PermError invalidates your entire SPF record. Suddenly, legitimate mail starts failing SPF. If you are at p=reject, you just blocked your own company.

To fix this, audit and remove unused services. Our SPF generator shows you the lookup count in real-time. Avoid flattening unless it’s your IPs.

The multiple records trap

A surprising number of outages happen because someone added a second DMARC record (for a new tool, say) without removing the old one.

If DNS contains two TXT records starting with v=DMARC1, receivers will often ignore both or behave unpredictably. Always update the existing record; never add a duplicate.

Strict vs. relaxed alignment

When you enforce, stick to relaxed alignment (the default).

For SPF, that means aspf=r. For DKIM, it’s adkim=r.

Strict alignment (s) means subdomains cannot authenticate for the parent domain. Unless you have a very specific architectural reason, strict mode causes more headaches than it cures.

Why you can’t wait

It used to be that DMARC was optional. In 2026, with Google and Yahoo’s sender requirements, having at least p=none is mandatory for bulk senders. See our guide on the 2026 email deliverability stack for the full picture.

But the goalpost is moving. High-security sectors and government standards are pushing for DMARC enforcement, usually p=quarantine or p=reject depending on the domain’s mail flow. The permissive era of email is closing.

FAQ

How long should I stay on p=none?

Until you have identified every legitimate service sending email as you. Usually 2-4 weeks covers most monthly billing cycles.

Should I still use pct?

No for new records. RFC 9989 moved pct to historic status. Keep parsing it if you see it in old records, but use t=y for a temporary dry run and omit pct from newly generated DMARC records. We cover the pct-to-t= change in RFC 9989 in the record tags guide.

What happens if SPF hits PermError?

SPF returns a “PermError” result, which counts as a fail. If DKIM also fails, DMARC will block the message.