DMARC Policy: 3 Critical Stages From p=none to p=reject
Every guide to email authentication finishes with the same instruction and skips the part that matters: publish a DMARC policy. There are exactly three values it can take, the difference between them decides whether your legitimate mail keeps arriving, and the standard that defines them was rewritten in May 2026. This is what each value asks a receiving mail server to do, in what order to move through them, and where the published advice has not caught up.
Every claim here comes from a primary source read on 15 September 2026: RFC 9989, RFC 7208, RFC 6376, Google’s sender guidelines, Yahoo’s sender requirements, Microsoft’s Outlook announcement, Microsoft Learn and the UK NCSC. Where a figure cannot be traced to a published method, this post says so rather than borrowing one.
What a DMARC policy actually is
A DMARC policy is a DNS TXT record published at _dmarc.example.com, and it does two things.
First, it asks receiving mail servers to check alignment. SPF proves a message came from an authorised server for the envelope sender; DKIM proves a domain signed it. Neither of those domains has to match the address a human actually sees in the From field. DMARC is the layer that insists at least one of them does.
Second, it tells the receiver what you would like done with mail that fails that check. That preference is the p= tag, and the current standard — RFC 9989, published in May 2026 and obsoleting the 2015 specification — defines the three values precisely:
p=none— “The Domain Owner offers no expression of preference.”p=quarantine— “The Domain Owner considers such mail to be suspicious. It is possible the mail is valid, although the failure creates a significant concern.”p=reject— “The Domain Owner considers all such failures to be a clear indication that the use of the domain name is not valid.”
Read those again. Every one of them is phrased as a preference, not an instruction. The RFC is explicit that final handling “is always a matter of local policy and is left to the discretion of the Mail Receiver”. A DMARC policy is a request, and the receiving provider decides what to do with it.
The other tags worth knowing are rua=, which nominates a mailbox for daily aggregate reports, and ruf=, for per-message failure reports. Without rua=, receivers must not send you reports at all — which means a record published without it is doing the monitoring stage of a rollout with the monitoring switched off.
Is DMARC necessary? Three providers changed the answer in 2024 and 2025
For a decade this was optional hygiene. It is not any more, and the reason is not a regulation — it is that the three largest consumer mailbox providers each made it a condition of delivery.
The thresholds, checked on each provider’s own page on 15 September 2026:
Google. The Email sender guidelines say that from 1 February 2024, senders of more than 5,000 messages per day to Gmail accounts must “Set up SPF and DKIM email authentication for your domain” and “Set up DMARC email authentication for your sending domain”. Everyone else needs SPF or DKIM. Note the sentence that follows, which almost no summary reproduces: “Your DMARC enforcement policy can be set to none.” A DMARC policy of none satisfies Google, which is not what most vendor pages imply.
Yahoo. Its sender best practices require bulk senders to “Publish a valid DMARC policy with at least p=none — DMARC must pass”, and add that including a rua tag is strongly recommended. Yahoo does not publish a message-per-day number for “bulk” anywhere on that page, so treat Gmail’s 5,000 as the practical planning figure rather than Yahoo’s.
Microsoft. Its April 2025 announcement for high-volume senders to Outlook.com, Hotmail and Live.com applies to “domains sending more than 5,000 emails per day” and requires SPF and DKIM to pass plus “At least p=none and align with either SPF or DKIM (preferably both)”.
So the honest answer to “is DMARC necessary” is: if you send more than about five thousand messages a day to consumer mailboxes, it is a delivery requirement today. If you do not, nobody is forcing you — but every one of those providers treats an unauthenticated domain worse, and your domain is spoofable by anyone until you publish a DMARC policy of some kind.
One detail worth flagging, because it is in Microsoft’s post and reads oddly: the page states both that rejection took effect on 5 May 2025 and that after that date non-compliant mail would be routed to Junk with rejection to follow “in the future (date to be announced)”. Both sentences are live on the page. Read your own message headers rather than the blog if you need to know which behaviour you are getting.
Is DMARC free? Yes, and here is what is not
The record itself is free. It is a DNS TXT entry, it costs nothing to publish at any registrar, and the aggregate reports receivers send back are free too. Anyone charging you for “DMARC” as a product is not charging you for the DMARC policy.
What costs money is reading the reports. They arrive daily, as gzipped XML, from every provider that received your mail, and the useful signal — the gap between “SPF passed” and “SPF aligned” — is buried in nested elements. Microsoft Learn puts it plainly: the data “can be vast and difficult to parse”. Those reports are what turn a DMARC policy from a published string into information you can act on.
You have three options, and all three are legitimate. Pay a reporting vendor. Build parsing yourself. Or, for a small estate with three or four sending services, open the XML in a text editor once a week for a couple of months and read it, which is genuinely workable and which no vendor page will suggest.
We are not going to publish a price range for the tooling, for the same reason we do not publish one for cyber insurance: it depends entirely on domain count and mail volume, and a figure quoted without knowing the estate is marketing rather than information.
Quarantine or reject: what you are asking a receiver to do
This is the decision the whole exercise turns on, and the two values are not simply “strict” and “stricter”.
p=quarantine asks for the message to be delivered but marked. In practice it lands in Junk, where the recipient can still find it. A false positive is embarrassing and recoverable.
p=reject asks for the message to be refused at the SMTP conversation. A false positive is mail that never arrived, with a bounce to a sender who may not understand it. That is not a worse version of the same outcome; it is a different kind of failure.
Choosing between them feels like the irreversible moment in a DMARC policy rollout, and it is not: if enforcement surprises you, you can publish a weaker value the same afternoon and DNS will propagate within the hour.
RFC 9989 attaches two hard conditions to reject that are worth quoting because they are routinely ignored. First: “domains that publish ‘p=reject’ MUST NOT rely solely on SPF to secure a DMARC pass and MUST apply valid DKIM signatures to their messages.” Forwarding breaks SPF; DKIM usually survives it.
Second: “domains that host users who might post messages to mailing lists SHOULD NOT publish Domain Owner Assessment Policies of ‘p=reject’.” If your engineers are on open-source lists, that sentence is about you.
And there is a symmetrical instruction to the receiving side that changes what reject even buys: Mail Receivers “MUST NOT reject incoming messages solely on the basis of a ‘p=reject’ policy”, and in the absence of other analysis “MUST treat such failing mail as if the policy were ‘p=quarantine’”. A DMARC policy of reject is a strong signal, not a guarantee of refusal.
The three stages, and roughly how long each takes
A DMARC policy rollout has three stages — none, then quarantine, then reject — and every authority agrees on the order. Microsoft recommends “moving gradually (none → quarantine → reject) to avoid unintended mail loss”. The RFC requires monitoring at p=none “for at least a month”, then p=quarantine “for an equally long period of time”, before comparing the disposition results.
The UK’s National Cyber Security Centre is the only body we found that publishes observed durations rather than a minimum. Its email security and anti-spoofing collection says that “many organisations report being able to move on from a DMARC policy of ‘none’ after about 6 to 8 weeks”, and from quarantine to reject “after about 3 months”.
The work that happens during those months is the entire point, and it is not waiting. It is reading aggregate reports, finding the payroll system, the CRM, the invoicing tool, the ticketing system and the marketing platform that all send as you, and getting each of them either signing DKIM with your domain or using a bounce domain you control.
Skipping to reject on day one is the single most common way this goes wrong, and it fails in the most awkward possible manner: your own broadcast mail stops arriving, and you find out from a customer.
What changed in May 2026, and why your guidance has not
RFC 9989 replaced the 2015 DMARC specification, and two changes matter to anyone writing a DMARC policy today.
The pct= tag is gone, marked historic in the IANA registry. It let you apply a DMARC policy to a sampled percentage of failing mail, and the RFC’s own explanation for removing it is blunt: operational experience showed it “was usually not accurately applied, unless the value specified was either 0 or 100”, and the inaccuracies “varied widely from one implementation to another”. In its place is t=y, a test-mode flag that asks receivers to apply one level below your stated policy.
The other change is a DNS tree walk that replaces the public suffix list for working out which domain owns the policy, plus np= for non-existent subdomains and psd= for public suffix operators.
Here is the part to be careful with. Microsoft Learn’s DMARC page, updated in July 2026, still cites RFC 7489 and still documents pct= with worked examples. The NCSC collection still recommends stepping pct= from 50 to 100. Neither is wrong to do — receivers that implemented pct= have not removed it — but if you are reading guidance written before May 2026, check it against the standard rather than assuming it is current.
Microsoft 365: the alignment trap that catches nearly everyone
If your mail is in Microsoft 365, there is a specific and very common failure that produces a passing SPF check, a passing DKIM check, and a failing DMARC result.
Mail from the initial *.onmicrosoft.com domain is DKIM signed automatically. Mail from your custom domain is not, until you publish two CNAME records — selector1._domainkey and selector2._domainkey — and enable signing in the Defender portal under Email & collaboration → Policies & rules → Threat policies → Email authentication settings.
Until you do, Microsoft signs your mail with the onmicrosoft.com domain, and Microsoft’s own alignment table shows the result: a From address at your custom domain signed by contoso.onmicrosoft.com fails alignment in both relaxed and strict modes. DKIM passes. DMARC fails. No DMARC policy value you publish will fix that, because the problem is the signing domain rather than the preference.
Two more Microsoft 365 specifics worth checking while you are in there. The default DKIM key size is 1024 bits, and Google recommends 2048 — the KeySize parameter on New-DkimSigningConfig takes either. And new custom domains added since May 2025 use a different CNAME format from existing ones, so a record copied from an older tenant will not resolve.
On SPF, the limit that bites is in RFC 7208: implementations “MUST limit the total number of those terms to 10” for mechanisms that cause DNS lookups, and exceeding it “MUST return permerror”. Every SaaS product you add an include: for spends one. This is why the estates that struggle with email authentication are the ones with a dozen marketing tools, not the ones with complicated infrastructure.
What a DMARC policy cannot do
This is where most coverage of the subject quietly overstates itself, so it is worth being precise.
A DMARC policy authenticates the domain in the From header. That is all it does. RFC 9989 lists what is explicitly out of scope, and the list includes “attacks in the display name portions of the RFC5322.From header field” and “content analysis”.
So: an attacker who registers examp1e.com and publishes their own perfect SPF, DKIM and DMARC records passes every check you have, because they are authenticating their domain, which is exactly what the protocol is for. An attacker who sends from a free mailbox with your chief executive’s name in the display field passes too, because nothing in DMARC looks at display names.
Those are the two shapes most business email compromise actually takes. Email authentication stops people sending as your domain; it does nothing about people sending like you. Impersonation protection, external-sender tagging and payment verification procedures cover that gap, and we work through where each of those lives in our pillar guide to cyber security for small business.
It also does nothing about inbound mail to you. Publishing a record protects other people from mail claiming to be you. Whether you honour other domains’ policies is a separate setting on your own tenant.
When moving to enforcement is the wrong choice
There are real cases where moving to enforcement is the wrong call this quarter, and saying so is more useful than a checklist.
If you cannot name every system that sends as you. Not “we think it is Microsoft 365 and Mailchimp” — name them. If you cannot, you are not ready to enforce, and the reports are how you find out.
If your staff post to public mailing lists. The RFC says not to, in those words. Send list traffic from a subdomain with its own policy instead.
If a critical system cannot sign with your domain. Some older line-of-business applications and some cheaper SaaS tiers simply cannot. Move that traffic to a subdomain, or fix the tool, before you enforce on the parent domain.
If nobody owns the reports. A DMARC policy at reject with an unread rua mailbox is a mail outage waiting for a supplier to change their sending infrastructure. Enforcement without monitoring is worse than monitoring without enforcement.
There is also a case for going faster than the three stages: a parked domain that has never sent mail and never will. Microsoft’s recommendation there is v=DMARC1; p=reject; immediately, with no reporting tags, because no legitimate mail exists to break. If you own defensive domain registrations, that is a ten-minute job with no monitoring period at all.
The number nobody can honestly give you
Search for how many domains lack a DMARC policy and you will get a figure. Search again and you will get a different one. We went looking for a defensible answer and could not find it.
The one we could trace to a described method is DMARCeye’s Q1 2026 research, which reports that 28% of open-internet domains have no DMARC record at all, and that among domains already engaged with the protocol about 37% are still at p=none while 26% have reached p=reject. That is a vendor scanning a sample it chose, and it says so.
The other figures circulating for the same year range from roughly a third to well over 80%, and they disagree because they are measuring different populations: the top million websites, or a stock index, or the domains that happened to be in one vendor’s scanner. None of them publishes a reproducible domain list.
So there is no headline statistic here. The useful question is not what fraction of the internet has a record; it is whether your domain has one, what it says, and whether anybody read the reports this month. That you can answer today with a single DNS lookup.
What we would do, in order
For a business on Microsoft 365 with a handful of SaaS products sending on its behalf, this is a few hours of work plus a monitoring period.
One. Look up your current record. nslookup -type=TXT _dmarc.example.com tells you in seconds whether you have a DMARC policy and what it says. A surprising number of estates have two conflicting records, which is a permanent error.
Two. Fix DKIM before you touch anything else. Publish both selector CNAMEs, enable signing for every custom domain, and confirm the d= value in a real message header matches your From domain.
Three. Audit the SPF record against the ten-lookup limit, and move anything you cannot bring under it onto a subdomain.
Four. Publish v=DMARC1; p=none; rua=mailto:dmarc@example.com to a shared mailbox, never an individual’s. Then actually read what arrives.
Five. Remediate every legitimate sender the reports expose. This is the long part and it is the only part that determines whether enforcement is safe.
Six. Move to quarantine, wait, compare the report data, then move to reject. Do a low-volume subdomain first and the parent domain last.
That is the entire DMARC policy decision: three values, one order, and a monitoring period nobody can shorten for you.
Email authentication is the quietest of the controls on our list and the one most often assumed to be done. It sits alongside the identity work we describe in the gaps MFA will not close, because a spoofed domain and a stolen session end up in the same place — a convincing message from someone the recipient trusts.
Worth noting what this is not driven by: we read both of the cyber insurance applications Beazley publishes while writing this, and neither asks about SPF, DKIM or DMARC at all. Their email questions are about inbound controls — “screening for malicious attachments”, “screening for malicious links”, “tagging external emails” — and MFA on webmail. The full question set is in our piece on the controls underwriters check. Do this because your domain is being spoofed and because Gmail and Outlook.com now require it, not because an underwriter asked.
If you would rather have someone walk the reports with you, this is standard work in a cybersecurity risk management engagement, and it is the same three stages whatever continent the mail is leaving from.