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.

What your DMARC policy actually says

Your DMARC policy is the p= tag inside the TXT record published at _dmarc.yourdomain.com. It tells receiving mail servers what you want done with mail that claims to be from your domain but fails authentication. There are three legal values:

• p=none watches only. Failing mail is still delivered, and you get reports. This is monitoring, not protection, which is why scanners flag it as a DMARC policy that is not enabled.
• p=quarantine asks receivers to send failing mail to the spam or junk folder, where a person can still find it.
• p=reject asks receivers to refuse failing mail outright, so it never reaches the inbox or the spam folder.

A complete record reads v=DMARC1; p=none; rua=mailto:[email protected], where rua is the address your reports go to (more on that below).

One thing to keep straight after RFC 9989, the 2026 DMARC standard that obsoletes RFC 7489: the p value is your assessment of failing mail, not a command the receiver must obey. RFC 9989 §5.3.6 leaves the final handling to the receiver’s local policy. Publishing p=reject sharply raises the odds that spoofed mail is refused. It does not force the outcome. For the full standards background, see our RFC 9989, 9990, and 9991 explainer.

What a “policy of reject” does

When you publish p=reject, receivers that support DMARC refuse failing messages during the SMTP conversation, before the message is accepted. The receiver returns a 5xx error, the sending server generates a bounce, and the message is never stored. In your aggregate reports it shows up as disposition=reject inside the policy_evaluated block of each failing message group.

That is the strongest protection DMARC gives you against spoofing, and it has the bluntest failure mode. Any legitimate sender you forgot to authenticate bounces the same way an attacker does. That is why reject is the end of a staged rollout, not the start.

Two cautions most older guides miss. First, p=reject is not the right end state for every domain. RFC 9989 §7.4 says domains hosting users who might post to mailing lists SHOULD NOT publish it, and that “In the absence of other knowledge and analysis, Mail Receivers MUST treat such failing mail as if the policy were ‘p=quarantine’”. For a domain full of human mailboxes, quarantine is the recommended end state. Reject fits transactional or marketing-only domains, parked domains, and dedicated sending subdomains where no person reads or posts mail. Second, that automatic downgrade is part of the freshly published DMARCbis standard, so not every receiver applies it yet. Treat it as the spec’d direction, not something every receiver enforces today.

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.

If the record exists but validating resolvers return SERVFAIL, the issue may be DNSSEC rather than DMARC syntax. Run the domain through the DNSSEC checker before editing the policy record again.

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.

rua and ruf: where your reports go

A DMARC policy is only half the record. The other half is reporting, and it works at every policy level, including p=none. That is the whole reason p=none is useful: it shows you every sender before you risk blocking anything. Two tags control it:

• rua (aggregate reports). rua=mailto:[email protected] tells receivers where to send aggregate reports. These are XML files, usually GZIP-compressed, that summarize who sent mail using your domain and whether each group of messages passed SPF, DKIM, and DMARC. In practice you get roughly one report per receiver per day. RFC 9990 recommends a daily-or-more-frequent cadence and no longer carries the old ri interval tag, which DMARCbis removed. Aggregate reports are widely supported and are the data you use to reach enforcement safely.
• ruf (failure reports). ruf=mailto:[email protected] requests failure reports, which carry message-level detail about individual failures. RFC 9991 renamed these from “forensic” to “failure” reports. Far fewer receivers send them, largely for privacy reasons, so do not lean on ruf as your main signal.

If your reporting address sits on a domain other than the one being reported on, the receiving domain has to authorize it (RFC 9990 §4). That authorization is a _report._dmarc record in the reporting destination’s DNS, of the form reporteddomain.com._report._dmarc.reportingdomain.com. Without it, conformant receivers will not send your reports cross-domain.

This is one place our own setup shows through. Each DMARCTrust account gets a reporting address of the form {your-id}-{token}@reports.dmarctrust.com. Because that address is on our domain, receivers need the external authorization record above, so we publish it for you in our own DNS at yourdomain.com._report._dmarc.reports.dmarctrust.com. Your aggregate reports then flow to us with no DNS work on your side. For the full reporting tag reference, see the aggregate reports section of the DMARC record tags guide.

FAQ

What is a DMARC policy of reject?

A DMARC policy of reject is p=reject in your _dmarc TXT record. It asks receiving mail servers to refuse mail that fails DMARC during the SMTP transaction, so the message never reaches the inbox or the spam folder and the sender gets a bounce. It is the strongest setting. RFC 9989 cautions against it for domains whose users post to mailing lists, so in practice it fits transactional or marketing-only domains best.

What is the difference between quarantine and reject?

p=quarantine asks receivers to put failing mail in the spam or junk folder, so a person can still find it. p=reject asks receivers to refuse failing mail outright, so it never arrives and bounces back to the sender. Quarantine is the safer end state for domains where humans send and receive mail. Reject suits domains where only systems send and nobody posts to mailing lists.

What is rua in DMARC?

rua is the tag that tells receivers where to send aggregate reports, like rua=mailto:[email protected]. Aggregate reports are XML summaries, usually GZIP-compressed, of who sent mail using your domain and whether it passed SPF, DKIM, and DMARC. Receivers send them on a roughly daily cadence. The ruf tag requests failure reports with message-level detail instead.

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.