DMARC policy: none, quarantine, reject
The p= tag in your DMARC record answers one question for every mail system on earth: what should happen to a message that claims to be your domain but fails DMARC? There are three possible answers — none, quarantine and reject — and the right way to think about them is not as a menu but as a ladder you climb, in order, at a pace your own data dictates.
Climbed properly, the ladder takes you from zero protection to full enforcement without a single lost message. Rushed, it silently discards legitimate mail from the senders you forgot you had. This article is about doing it properly.
What is a DMARC policy?
A DMARC policy is the p= tag in your DMARC record: the instruction that tells receiving mail servers what to do with mail that claims to be your domain and fails DMARC.
When people say "our DMARC policy", they almost always mean the value of that one tag. A DMARC record carries several — a version, a reporting address, alignment settings — but only p= decides the fate of failing mail, and it accepts exactly three values: none, quarantine and reject. If p= is missing or misspelt, receivers have nothing to act on: they fall back to monitoring at best, and if there is no usable rua either, the record may be disregarded altogether.
Two things the policy does not do are worth stating plainly. It has no effect on mail that passes DMARC — a message with an aligned SPF or DKIM result is delivered on its merits whatever your p= says. And it is not necessarily the only policy your domain runs: the optional sp= tag sets a separate policy for your subdomains. Leave sp= out and every subdomain inherits p=; set it, and you have two policies side by side, which is how a domain ends up enforcing at the apex while mail.example.com stays wide open. DMARC record tags explained covers sp= and the rest of the record in full.
What each policy actually does
First, a necessary dose of honesty: a DMARC policy is a request, not a command. You are telling receivers what you would like done with failing mail; the receiving system makes the final call, and occasionally deviates — most commonly softening reject to quarantine for mail that looks like legitimate forwarding. The disposition field in your aggregate reports shows what each receiver actually did.
That said, major mailbox providers honour these requests overwhelmingly:
| Policy | What you are asking receivers to do | Risk to legitimate mail |
|---|---|---|
p=none | Deliver failing mail normally; just include it in reports. | None — nothing changes. |
p=quarantine | Treat failing mail as suspicious — typically the spam folder. | Misconfigured real senders land in spam. |
p=reject | Refuse failing mail outright during delivery. | Misconfigured real senders bounce. |
Notice what the table implies: the risk column is entirely about your own senders. Spoofed mail should be failing at every rung — the question the ladder answers is whether your legitimate mail is ready for enforcement.
Seen from the outside, that first row is what a checker means when it reports that your DMARC policy is not enabled: a warning about the rung you are standing on, not an error in your record. DMARC policy not enabled: what it means takes the phrase apart, including the two other states it gets used for.
p=none explained — monitoring, not "no protection"
p=none is often dismissed as the policy that does nothing, and that is half right. It changes nothing about delivery: a forged message that fails DMARC under p=none reaches the inbox exactly as it would have with no DMARC record at all. Nothing is blocked and no attacker is inconvenienced.
What it changes is what you can see. Published with a rua address, it switches on the aggregate reports that show every source sending as your domain — passing or failing, from mailbox providers around the world. That is the map you need before you can safely block anything, which is why p=none is the correct first rung rather than a failure of nerve.
It also counts for compliance. The Gmail and Yahoo bulk-sender rules require a DMARC record on your From domain, and p=none satisfies that requirement; neither provider's rules oblige you to publish a rua address. The catch is that bulk senders must also pass DMARC, and aggregate reports are the only way to find out whether you do — a record with no rua meets the letter of the rule while telling you nothing. Google and Yahoo DMARC requirements sets out the full checklist.
Where p=none stops being a sensible first step is when it becomes permanent. If your reports have run clean for weeks and the record has not moved, you have paid the whole cost of DMARC — the DNS work, the sender audit, the monitoring — and collected none of the protection. Monitoring documents the spoofing; only enforcement stops it.
p=quarantine explained — where quarantined mail actually goes
DMARC asks receivers to treat failing mail as suspicious. It does not prescribe how, so "quarantined" names an outcome rather than a mechanism, and the mechanism varies:
- The spam or junk folder. The usual result at consumer mailbox providers, and what most people picture when they read the word.
- A held quarantine area. Business filtering platforms often divert the message to a holding queue that an administrator — and sometimes the recipient — can review and release.
- Header tagging and delivery. Some receivers deliver the message anyway with the authentication result recorded in its headers, leaving the decision to a downstream rule or to the recipient.
You do not have to guess which of those happened. The disposition field in your aggregate reports records what each receiver actually applied, receiver by receiver — how to read a DMARC report shows where to find it.
The difference that matters when you are choosing between the top two rungs is recoverability. Quarantined mail still exists: a customer expecting your invoice can find it in spam, and an administrator can release it. Rejected mail does not exist for the recipient — it is refused during the SMTP transaction, so there is nothing to search for and nothing to release. Quarantine is the rung to stand on while you are still slightly unsure; reject is the rung you move to once you are not.
If your domain carries high-stakes volume, the pct= tag introduces quarantine in stages instead of all at once:
| Record | What receivers apply | What happens to the rest |
|---|---|---|
p=quarantine; pct=25 | Quarantine on roughly a quarter of failing mail | The remainder is treated one notch softer, as p=none — delivered normally |
p=quarantine; pct=50 | Quarantine on roughly half of failing mail | The remainder is treated as p=none |
p=quarantine with pct=100, or no pct at all | Quarantine on all failing mail | Nothing is sampled out |
Widen the sample only once the previous stage's reports look the way you expected. Sampling has two limits worth holding on to. Mail that is sampled out is not waved through unchanged — it drops exactly one rung, so the remainder under p=reject is quarantined rather than delivered. And pct is a request like the policy itself: some receivers ignore it entirely, and under p=none there is nothing for it to sample in the first place.
Which policy should I publish?
The right value today depends on one thing: how much you currently know about who sends mail as your domain. Find your situation below.
| Where you are | Publish | Why | When to move on |
|---|---|---|---|
| No DMARC record, or one you have never read a report from | p=none with a rua address | No delivery risk at all, and it starts the reporting that every later decision depends on | After two to four weeks, once you can account for every sending source |
| Every source in the reports is identified, and your legitimate senders pass and align | p=quarantine, with pct= if the volume is high-stakes | Failing mail is diverted rather than delivered, and anything you got wrong is still recoverable from spam | After a few clean weeks at quarantine with no unexplained failures |
| Quarantine has run clean and nothing unidentified is still failing | p=reject | Forged mail is refused at the door of every major provider before a human sees it | Nowhere — this is the destination. Keep rua on permanently |
| Sources you cannot identify are still failing, or you connected a new sender this week | Whatever you have now — hold it | Tightening while the picture is incomplete is how real mail disappears silently | Once the unknowns are resolved and the new sender appears in reports as passing |
Whichever row you are on, the change itself is one line of DNS, and hand-editing a live TXT record is where typos happen. The DMARC record generator assembles the whole value from the policy, reporting address and optional tags you choose, ready to paste at your DNS provider. To see what you have published right now before changing anything, the DMARC checker fetches your live record and explains its policy, reporting and alignment tags.
Step 1: start at p=none and switch the lights on
The first rung is the one described above: p=none with a rua reporting address, published at zero risk to your mail, because delivery behaviour does not change at all.
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:[email protected]"Publish this, then wait. Most large mailbox providers send aggregate reports daily, and within a few days you will start seeing the true map of everything that sends as your domain.
Step 2: read the reports and fix your legitimate senders
Give it two to four weeks — long enough to catch weekly newsletters, monthly invoices and other slow-cycle senders. In that window, your job is to sort every sending source in the reports into one of two buckets: mine or not mine.
For every source that is yours but failing, finish its authentication — usually by completing the provider's SPF include or its custom-domain DKIM setup so at least one check passes and aligns with your From domain. How to read a DMARC report walks through exactly what to look for, row by row.
Sources that are not yours need no action. They are the reason you are doing this — and the next rungs are what shuts them down.
Step 3: move to p=quarantine — with pct= if you want stabilisers
When your reports run clean — every legitimate source passing and aligned — tighten the policy:
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]"Editing a live DNS record by hand invites typos — the free DMARC record generator builds the updated value for you: pick quarantine (or reject, when you reach that rung), keep your rua address, and paste the result at your DNS provider.
Now failing mail starts landing in spam folders instead of inboxes. Spoofed mail loses most of its power; a misconfigured real sender is inconvenienced but not silenced, because recipients can still find the mail in spam.
This is the rung where the pct= staging set out above earns its keep on a high-volume domain: step through 25 → 50 → 100 over a couple of weeks, reading the reports before each widening, and remove pct (or set it to 100) when you are confident.
Step 4: finish at p=reject
p=reject is the destination — the policy that makes forged mail bounce at the door of every major provider before a human ever sees it:
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"Move here when quarantine has run clean for a few weeks: compliance steady, no unexplained failing sources that might be legitimate. Keep the rua address forever — reporting is how you spot the next tool someone connects without telling you, and new spoofing campaigns the moment they start.
When NOT to move up
The ladder has no schedule. Hold your current rung when any of these is true:
- Unidentified sources are still failing and you cannot rule out that they are legitimate — an office device that emails scans, a regional CRM, a tool one department quietly adopted. Enforce too early and their mail vanishes.
- A known legitimate sender is failing and the fix is still in progress. DNS changes and provider-side DKIM setups need time to verify in the reports.
- You have just added a new sending service. Let it appear in the reports as passing and aligned before tightening further.
The single worst DMARC mistake is jumping straight to p=reject on day one, without a reporting address or a monitoring period. It feels decisive; what it actually does is discard real mail from every sender you forgot about, invisibly.
Monitor the climb
Every step on this ladder is a decision, and every decision should be made on data: which sources are failing, whether they are yours, and whether the fix worked. That is precisely what DMARC's aggregate reports contain — and what DMARCmetric turns into a per-sender dashboard with a policy advisor that tells you when you are ready for the next rung and reads your live DNS record so its guidance is always current. If you would rather see it before signing up, the live demo shows the journey on realistic sample data.