Guide
DMARC policy: none, quarantine or reject, and how a firm moves between them
In short
A DMARC policy tells receiving mail systems what to do with email that fails DMARC: none asks for nothing, quarantine asks them to treat it as suspicious, and reject asks them to refuse it. Firms usually start at none to collect reports, fix the services that fail, and move to quarantine and then reject once the reports show that legitimate mail passes.
Where the policy lives
The policy is the p= tag of the DMARC record, published under the name _dmarc followed by your domain. It applies only to mail that fails DMARC: mail for which neither SPF nor DKIM passes for a domain aligned with the From address.[1]
_dmarc.samplefirm.example TXT "v=DMARC1; p=quarantine; sp=reject; np=reject; rua=mailto:[email protected]"Two related tags are worth knowing. sp= sets the policy for subdomains that exist, and np= the policy for subdomains that do not, which criminals could otherwise invent.[1] A subdomain without a DMARC record of its own is covered by the record of its parent domain.[2]
p=none: reports, not protection
With none, the domain owner expresses no preference about failing mail.[1] Receivers apply their usual filtering and send their reports, and nothing else changes. That is why it is the right place to start: the NCSC points out that a policy of none does not interfere with your email traffic in any way, and gives you time to confirm that SPF and DKIM are configured correctly.[3]
It is the wrong place to stay. A message forging your domain meets a policy that asks receivers for nothing, and Microsoft describes none as the value to use for testing and tuning a DMARC policy.[2] Meeting Google’s requirements for bulk senders is not a reason to stop there either: they accept a policy of none, because they are about delivery rather than protection.[4]
p=quarantine: treated as suspicious
Quarantine asks receivers to accept failing mail but treat it as suspicious. What that means is up to the receiving system: the message may go to the junk folder or a quarantine, or be delivered with a warning added.[2] In Microsoft 365, with the setting that honours senders’ DMARC policies switched on, failing mail from a domain at quarantine goes to the Junk Email folder.[2]
p=reject: refused
Reject asks receivers to refuse failing mail. Microsoft 365, honouring the policy, rejects such a message during delivery, and the sending server receives a bounce.[2] The NCSC’s view is plain: a DMARC policy of reject on all of your domains is the best way to prevent spoofing of your email.[5]
Domains that never send email need the same protection. For registered domains that are not used for mail, Microsoft recommends a record of v=DMARC1; p=reject; so that nobody can send in their name.[2]
Moving from none to reject
The route is the same whoever does the work: publish, observe, fix, tighten and observe again. Microsoft recommends starting with a domain or subdomain that sends little mail from few sources, and leaving the main domain until last.[2]
- Publish p=none with a reporting address, and collect reports across a normal stretch of business, including month-end billing and any newsletters.
- Match every sending source in the reports to a service the firm recognises. A source nobody recognises is either a forgotten service or someone sending as you.
- Fix each legitimate service that fails: add it to SPF, switch on DKIM signing with your own domain, or have the provider send from an aligned subdomain.[2]
- Move to quarantine, and watch both the reports and the people who rely on those services, then move to reject.
- Keep watching. The NCSC recommends monitoring reports closely for at least two weeks after reaching reject, and notes that many organisations move from quarantine to reject after about three months.[5]
What to look for before each step
- Before quarantine: every source that sends legitimate mail passes SPF or DKIM for a domain aligned with yours.
- Before reject: a spell at quarantine in which no genuine mail is reported as failing, and nobody at the firm or among its suppliers finds mail in junk.
- After reject: the failures in the reports come only from sources you do not recognise, which is the policy doing its job.[2]
Two questions firms ask at this point
Can reject stop our own mail?
Yes, if a legitimate service still fails. Reject asks receivers to refuse any mail that fails DMARC, and receivers cannot tell a forgotten billing system from a criminal.[2] That is why the reports are read before each step, and why whoever looks after your DNS should know how to return to quarantine quickly if something unexpected appears.
Is quarantine enough?
Quarantine still delivers the message somewhere a person may find it and act on it, such as a junk folder.[2] For a firm whose clients move money on the strength of an email, reject is the safer end point once the evidence shows that genuine mail passes.
What changed in RFC 9989
The DMARC standard was revised in May 2026. RFC 9989 replaced the earlier specification, RFC 7489, and removed the pct tag, which let a domain apply its policy to only a percentage of failing mail.[1] Much of the guidance still in circulation, including the NCSC’s pages from 2019 and Microsoft’s own instructions, describes staged roll-outs with pct.[5][2]
RFC 9989 offers a testing flag instead. With t=y, a receiver that supports it applies the policy one level below the one published: reject is treated as quarantine, and quarantine as none.[1] Each step therefore changes how all of your failing mail is treated, which is a good reason to fix services before tightening, rather than to tighten in small percentages and hope.
When reject is not right yet
Sometimes a service cannot be fixed in the time available: an old scanner, a supplier that cannot sign with your domain, a system due to be replaced. Tightening anyway would stop that mail. The honest answer is to hold the policy where it is safe, record which service is blocking the next step and why, and give it an owner and a date. A firm that can show that decision is in a better position than one that set reject without checking.
mailcounsel works this way with your IT provider, and our sample record shows how each policy step and its reasons are written down. To see which policy your domain publishes today, run the free check, or arrange a scope call to plan the steps.
Next step
See what your domain publishes today.
The free check reads your public DNS records. The scope call takes twenty minutes, with your IT provider if you like.
Sources
- RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC). IETF, RFC Editor, May 2026. Checked 10 September 2026.
- Set up DMARC to validate email in Microsoft 365. Microsoft Learn, updated 17 July 2026. Checked 10 September 2026.
- Email security and anti-spoofing: implement a DMARC policy of ‘none’. National Cyber Security Centre, 7 October 2019. Checked 10 September 2026.
- Email sender guidelines. Google Workspace Admin Help. Checked 10 September 2026.
- Email security and anti-spoofing: reject spoof emails. National Cyber Security Centre, 7 October 2019. Checked 10 September 2026.