Skip to content
EN
Seal my domain

Back to the guides · Technical · 22 min read

Taking DMARC up to reject without breaking anything

The ladder from none to quarantine to reject after the May 2026 revision: pct is gone, sp and np do the work, and the organisational domain is resolved by walking up the tree.

Updated in August 2026

You get to p=reject subdomain by subdomain and week by week, not by percentage, because since May 2026 percentages no longer exist. The DMARC revision removed the pct tag, so the manual doing the rounds online (publish pct=10, then pct=25, then pct=50) describes a mechanism that is no longer in the standard. The policy either applies in full or does not apply at all.

What does work is this: observe at p=none until the inventory of who sends in your name is closed, start enforcement with the flow you control one hundred per cent, protect the subdomains with sp and np while the root domain stays tolerant, and leave the root until last. Six to twelve weeks, depending on how untidy the house is.

What changed in May 2026

DMARC stopped being an informational document and moved onto the standards track. RFC 7489 is obsolete and three documents replace it: RFC 9989 (protocol and policy), RFC 9990 (aggregate reports) and RFC 9991 (failure reports). These are the changes that touch day-to-day work:

DMARCbis changes that affect deployment
ChangeWhat it means in practice
pct= removedNo more "roll out at 10%". This rewrites the entire classic runbook.
New t= tagAsks the validator not to apply the policy and to handle the message under its own rules. It is the conceptual successor to pct=.
np=Policy for subdomains that do not exist. np=reject kills spoofing of invented subdomains without touching the real ones.
sp=Policy for subdomains that do exist. It was already there; now it is normative.
Tree walk instead of the Public Suffix ListThe organisational domain is discovered by walking up the tree with up to eight DNS queries, rather than consulting a hand-maintained list.
psd=Values y, n or u, for declaring public suffixes.

A practical transition rule: publish records that read correctly under both the old norm and the new one. Do not use pct for anything, and do not assume t= is protecting you.

Before touching the policy: the four buckets

Moving to reject is a promise to the world that everything leaving with your domain in the From is authenticated and aligned. If that promise is false for even one sender with volume, its messages stop arriving on the day of the change: usually the ERP that issues invoices, the CRM, the website form or the marketing agency. Which is why the real work is not publishing the record, it is closing the inventory. Every IP appearing in the aggregate reports goes into one of these four buckets:

  1. Bucket 1 · Legitimate and alignedIt is yours, it authenticates and it aligns. Nothing to do. Just note it down so you do not investigate it again next month.
  2. Bucket 2 · Legitimate and not alignedIt is yours and it authenticates, but with somebody else's domain: signing with the provider's d=, or using the provider's Return-Path. Fixed by signing with your domain or changing the Return-Path. This bucket sets the timetable: while it carries material volume, you do not move up a step.
  3. Bucket 3 · ForwardersLow volume spread across many different IPs, with SPF fail and DKIM pass. That is normal forwarding behaviour and it cannot be fixed from your side: ARC mitigates it, and the intermediary is the one who implements ARC. It is not a reason to hold off.
  4. Bucket 4 · SpoofingVariable volume, no authentication at all, origins you do not recognise. This is precisely why DMARC exists and why getting to reject is worth the trouble.

There is a single numeric criterion for moving from one phase to the next: at least 98 per cent of legitimate volume passing DMARC for seven consecutive days. One good day does not count, because some senders only send at month end.

Week 0: observe and change nothing

Observation record
_dmarc.empresa.es. IN TXT "v=DMARC1; p=none; rua=mailto:rua@rep.empresa.es; ruf=mailto:ruf@rep.empresa.es; fo=1; adkim=r; aspf=r"

With p=none nothing changes for anyone: nobody stops receiving your mail. The only thing that happens is that reports start arriving.

Minimum duration: two weeks. Realistic duration: four to six if the company has invoicing, an ERP, a CRM, web forms and an agency in the mix. There is always a forgotten sender, and it always shows up late. Two warnings about this record: the rua mailbox has to be one somebody genuinely processes, because publishing a rua nobody reads is the same as having no DMARC; and do not count on failure reports (ruf), which almost nobody sends today for data protection reasons, Google included.

Weeks 2 to 6: inventory and clean-up

With the reports in hand, the list of sending sources has to be closed: every IP and every domain sending in your name either authenticates in alignment or is switched off. This is the pattern you will see most often in the XML, and it is worth being able to read it before you argue about it with a provider:

A valid signature that does not align
<policy_evaluated>
  <disposition>none</disposition>
  <dkim>fail</dkim>     <!-- ALIGNMENT result -->
  <spf>pass</spf>
</policy_evaluated>
...
<auth_results>
  <dkim><domain>proveedor.com</domain><result>pass</result></dkim>   <!-- correct signature -->
  <spf><domain>empresa.es</domain><result>pass</result></spf>
</auth_results>

pass above and fail below is not a contradiction: the signature is valid, but it belongs to the provider and not to your domain. This is bucket 2 in its purest form.

Weeks 6 to 8: enforcement on the most controlled flow

Start with the lowest-risk subdomain, which is nearly always the transactional one: generated by a system, sent through a single provider, and never forwarded by hand.

First subdomain at reject
_dmarc.mail.empresa.es. IN TXT "v=DMARC1; p=reject; rua=mailto:rua@rep.empresa.es"

Then the campaigns subdomain. The corporate domain, where the people, the forwarding and the mailing lists live, always goes last.

Weeks 8 to 10: root to quarantine, subdomains to reject

The move that replaces pct=
_dmarc.empresa.es. IN TXT "v=DMARC1; p=quarantine; sp=reject; np=reject; rua=mailto:rua@rep.empresa.es; fo=1"

sp=reject and np=reject protect both real and invented subdomains while the root stays tolerant. This is the post-pct way of reducing risk: protect first what carries no human traffic.

It is worth understanding the tree walk here, because it changes who your sp applies to. Previously, to find the organisational domain of a subdomain, receivers consulted the Public Suffix List. Now they walk up the tree with up to eight DNS queries until they find a DMARC record. The practical consequence: a subdomain with no policy of its own inherits the parent's by the short route, and domains under unusual suffixes stop producing surprises.

Weeks 10 to 12: the root domain to reject

Final destination
_dmarc.empresa.es. IN TXT "v=DMARC1; p=reject; sp=reject; np=reject; adkim=s; aspf=r; rua=mailto:rua@rep.empresa.es; fo=1"

adkim=s (strict DKIM alignment) only once every flow signs with the exact domain. If any subdomain is doing the signing, adkim=s breaks it.

Domains that do not send mail

Defensive domains, retired brands and lookalike domains bought for protection need no staircase: they do not send, so there is nothing to break. They go straight to reject, with null SPF and DKIM, and it is one of the highest-return things you can do in an afternoon.

A non-sending domain, fully locked down
parked.es.                  IN TXT "v=spf1 -all"
*._domainkey.parked.es.     IN TXT "v=DKIM1; p="
_dmarc.parked.es.           IN TXT "v=DMARC1; p=reject; adkim=s; aspf=s;"

If the domain does not receive mail either, publish a null MX for it as well (a priority 0 MX pointing at a dot), per RFC 7505.

The three mistakes that really do break mail

MistakeWhat happensHow to avoid it
Moving up with bucket 2 still openThe legitimate but unaligned sender stops delivering on the day of the change. It is usually the invoices.Do not move the policy until seven consecutive days with 98% of legitimate volume passing.
Publishing adkim=s too earlyFlows signing from a subdomain stop aligning overnight.adkim=s only once every flow signs with the exact domain, not with one from the family.
Publishing a rua nobody processesYou believe you have DMARC, but you have no information, and you move up blind.Automated report processing, with an alert whenever a new sender appears.

And a fourth that breaks no mail but costs money: believing that reject fixes deliverability. It does not. DMARC stops other people using your domain and it is a requirement of the large providers, but on its own it neither improves your reputation nor gets you out of the junk folder. That depends on complaints, list hygiene and content.

Questions that always come up

My tool tells me to publish pct=25. Should I?

No. The tag disappeared in the May 2026 revision, and publishing it today is, at best, noise that receivers ignore. A tool still recommending it in 2026 tells you something about when it was last updated.

How long does it really take?

Six to twelve weeks. What sets the pace is not DNS, it is how many forgotten senders turn up in the reports and how long the people responsible for them take to reply.

Can I skip quarantine and go straight to reject?

On a transactional subdomain you control one hundred per cent, yes, and that is what this runbook recommends. On the corporate domain, no: that is where the forwarding, the lists and the people are.

What if a provider refuses to sign with my domain?

Then you have a commercial decision rather than a technical one: either change the Return-Path so it aligns through SPF, or move that flow onto a subdomain with its own policy, or change provider. What you cannot do is move to reject and hope for the best.

If reading this has made you realise the problem sits one step earlier, in flows that do not align, the guide to SPF, DKIM and DMARC explains where that alignment comes from and how to check it in a real message. And if what you want to know is exactly what Gmail, Outlook and Yahoo require in order not to reject you, that is in the requirements guide, with the three of them compared in one table.

Sources

Everything stated here comes from one of these places. If something carries no source, it is an opinion and is said as such.

This guide explains how things work and cites the rules with a link, but it is not legal advice.

Keep reading