p=none vs quarantine vs reject

5 June 2026 · 12 min read

The one setting that decides whether DMARC actually protects you

A DMARC record can be long, full of tags and addresses, but only one part of it tells receiving mail servers what to do with a message that fails authentication. That part is the policy, written as p= in your DNS record. It has exactly three valid values: none, quarantine and reject. Everything else in DMARC, the reporting, the alignment rules, the identifiers, exists to serve the decision encoded in those few characters.

The trouble is that the three policies look almost interchangeable in a config file and are anything but in practice. p=none stops nothing. p=quarantine sends failing mail to spam. p=reject makes failing mail vanish before it reaches an inbox. Pick the wrong one and you either leave your domain wide open to spoofing, or you knock your own legitimate email out of delivery. This article explains precisely what each policy instructs a receiver to do, how to read the difference in your own reports, and how to move from the safe-but-useless starting point up to full enforcement without ever causing an outage.

If you just want to read your current policy off your live DNS, run your domain through the free DMARC checker before you go any further. It will show you the exact p= value receivers see today.

What a DMARC policy actually is

DMARC sits on top of two older standards, SPF and DKIM. SPF checks whether the sending server is permitted to send for the envelope domain. DKIM checks whether the message carries a valid cryptographic signature tied to the domain. DMARC adds two things those standards lack on their own.

First, it adds alignment: it is not enough for SPF or DKIM to pass for some unrelated domain, the passing domain has to match the domain in the visible From: header that a human reads. This is what stops an attacker from sending From: you@yourbank.com while passing SPF for attacker-server.net.

Second, and this is the policy, DMARC lets the domain owner publish an instruction telling every receiving mail server in the world what to do when a message claiming to be from that domain fails alignment. That instruction is the p= tag. A receiver that supports DMARC, which now includes Gmail, Yahoo, Microsoft and effectively every large mailbox provider, looks up your record, evaluates the message, and obeys the policy you published.

So the policy is a public promise about your own domain. You are telling the world: "If a message fails to prove it came from me, here is how strict I want you to be." A minimal record with a policy looks like this:

v=DMARC1; p=none; rua=mailto:reports@yourdomain.com

The v=DMARC1 declares the version, p=none is the policy, and rua= is where aggregate reports should be sent. The policy is the load-bearing part. To understand how that single word changes behaviour, you have to look at each value in turn.

p=none: monitor only, enforce nothing

p=none tells receivers: "Evaluate this message, send me a report about it, but take no special action either way." A message that fails DMARC under p=none is delivered exactly as it would have been if you had no DMARC record at all. Nothing is blocked. Nothing is diverted. The only thing that changes is that you start receiving data.

This is deliberate, and it is the correct place to begin. The entire point of p=none is to give you visibility before you give receivers permission to act. When you publish it with a rua= address, mailbox providers begin sending you daily aggregate reports listing every IP address that sent mail claiming to be your domain, how much of it passed or failed SPF and DKIM, and whether it aligned. For most organisations this is the first time anyone has ever seen the full picture of who sends as their domain: the marketing platform nobody told IT about, the invoicing tool finance set up three years ago, the helpdesk software, the legacy server in a branch office.

The danger of p=none is not that it does something wrong. The danger is that people stop there. A domain sitting on p=none for years is fully spoofable. An attacker can forge your From: address, fail DMARC completely, and the message still lands in the inbox because you told receivers to do nothing about failures. The green tick in a dashboard that says "DMARC present" is misleading: presence is not protection. We have written a whole piece on this trap in why p=none gives a false sense of security, and it is worth reading if anyone in your organisation believes the box is already ticked.

Think of p=none as the observation stage. You are gathering evidence, identifying your legitimate senders, and fixing their SPF and DKIM so they pass alignment. It is essential, but it is a stage you pass through, not a destination.

p=quarantine: treat failures as suspicious

p=quarantine tells receivers: "If a message fails DMARC, do not trust it. Set it aside." In practice the overwhelmingly common interpretation is to deliver the failing message to the spam or junk folder rather than the inbox. The message is not destroyed, the recipient can still dig it out of junk, but it no longer arrives where it would be seen and trusted.

This is the first policy that actually does something to protect you. A spoofed message that fails alignment now gets shunted to junk at most providers, which dramatically reduces the chance a recipient acts on it. For a great many domains, quarantine is a perfectly reasonable enforcement level, and for some it is the sensible permanent home.

There is one extra tool that makes quarantine especially useful as a stepping stone: the percentage tag, pct. You can apply your policy to only a fraction of failing mail. For example:

v=DMARC1; p=quarantine; pct=25; rua=mailto:reports@yourdomain.com

This tells receivers to quarantine only 25 per cent of messages that fail, and treat the remaining 75 per cent as if the policy were none. It is a controlled dial. If something you missed starts failing, only a quarter of it is affected, the blast radius is contained, and your reports will show you the problem before you ramp the percentage higher. This is one of the safest mechanisms in the whole standard for de-risking a policy change, and we will come back to it.

A word of honesty about quarantine: behaviour is not perfectly uniform across receivers. Most send to spam, but the standard technically allows a receiver to treat a quarantined message in other ways, and some place it under heavier scrutiny rather than straight into junk. For your own legitimate mail this is exactly why you do not jump to quarantine until your senders pass alignment cleanly: a misconfigured legitimate sender under p=quarantine means your own newsletters, receipts or password resets start landing in junk folders.

p=reject: failures do not get delivered

p=reject tells receivers: "If a message fails DMARC, refuse it. Do not deliver it at all." At the SMTP level the receiving server rejects the message outright during the transaction, so it never reaches the inbox or the junk folder. From the recipient's point of view, it simply never existed.

This is the goal. p=reject is the only policy that genuinely stops exact-domain spoofing, because it is the only one where a forged message claiming to be from your domain is actively turned away rather than merely filed somewhere less visible. It is also the level that large mailbox providers and an increasing number of security and compliance frameworks expect. If your domain is a target for phishing, business email compromise or invoice fraud, reject is what closes the door. The mechanics of exactly that attack are walked through in how invoice fraud begins with a spoofed domain.

The reason people are nervous about reject, rightly, is that the cost of a mistake is higher. Under p=none a misconfigured sender produces a worrying report. Under p=quarantine it produces mail in junk that can still be recovered. Under p=reject a legitimate sender that fails alignment has its mail bounced and lost. If you flip straight to reject without doing the preparatory work, you can take down your own transactional email, payroll notifications or customer receipts, and the failures happen silently from your side because the rejection occurs on the receiver's server.

That risk is entirely manageable, but only if you arrive at reject in the right order rather than skipping to it. The whole of the next two sections is about that order.

How the three policies compare, in plain terms

Here is the practical difference, stripped of jargon, in the order of increasing strictness:

• p=none. Failing mail is delivered normally. You get reports. Protection against spoofing: none. Risk to your own mail: none. Purpose: see who sends as you.
• p=quarantine. Failing mail goes to spam or junk. You get reports. Protection: substantial, most spoofing is hidden from the recipient. Risk to your own mail: moderate, a broken legitimate sender lands in junk. Purpose: meaningful enforcement, and a staging level on the way to reject.
• p=reject. Failing mail is refused and never delivered. You get reports. Protection: full, against exact-domain spoofing. Risk to your own mail: high if you have not prepared, none if you have. Purpose: the protective end state.

Two points are worth underlining. First, you receive aggregate reports at every policy level, including reject, so you never lose visibility by enforcing. Second, the risk column is only about your own legitimate senders that have not been brought into alignment. Once every system that legitimately sends as your domain passes SPF or DKIM with alignment, the risk of reject drops to essentially zero, because the only mail being rejected is mail that was never yours.

There is also a subordinate policy for subdomains, sp=. If you do not set it, subdomains inherit the main p= value. You can, for instance, run p=reject on the parent while holding a particular subdomain at sp=quarantine during a migration. That is an advanced lever; most domains are fine letting subdomains inherit the parent policy, but it exists for the cases where one subdomain has a messier sender footprint than the rest.

The safe path from none to reject

Moving up the policy ladder is not a single switch you flip when you feel brave. It is a sequence, and the sequence is what keeps your email flowing. Here is the path that works.

1. Publish p=none with a reporting address. Get the record live and start collecting aggregate reports. Generate a clean starting record with the DMARC record generator if you do not have one yet. At this stage you change nothing about delivery; you are only switching on the cameras.

1. Read the reports and inventory your senders. Spend a few weeks letting data accumulate, then work out who legitimately sends as your domain. Every marketing tool, every CRM, every ticketing system, every server. The reports are XML, but you do not have to parse them by hand: drop them into the DMARC report analyzer, and read reading your first DMARC aggregate report for a field-by-field walkthrough. Your goal is a list of legitimate sending sources and, for each, whether it currently passes aligned SPF, aligned DKIM, or neither.

1. Fix alignment for every legitimate sender. This is the real work and the step people skip. For each legitimate source, make sure either SPF or DKIM passes and aligns with your From: domain. Add the source to your SPF record (watching the ten-lookup limit, see SPF PermError), and set up DKIM signing with the provider's keys. Verify with the SPF checker and the DKIM checker. When your reports show all legitimate mail passing DMARC, and only unknown or clearly hostile sources failing, you are ready to enforce.

1. Step up to p=quarantine, ideally with pct. Begin with something like p=quarantine; pct=25, watch the reports for a week or two for any legitimate sender you missed, then raise the percentage toward 100. Quarantine with a low percentage is your safety valve: any mistake affects only a slice of mail and is recoverable from junk.

1. Move to p=reject once quarantine at 100 per cent is clean. When p=quarantine; pct=100 has run for a while with no legitimate mail failing, switch to p=reject. You can use pct again here if you want an extra-cautious ramp. By this point reject changes almost nothing for your real mail, because everything legitimate already passes, it simply turns the spam-foldering of forgeries into outright rejection.

The single rule that ties this together: you only ever tighten the policy after your reports prove your legitimate senders pass. Reports first, enforcement second, every time. We expand on this end to end in how to reach p=reject without breaking email.

Common mistakes when choosing a policy

A few patterns cause most of the self-inflicted damage:

• Sitting on p=none forever. The most common failure is not breaking mail, it is never protecting it. A domain stuck on none is spoofable indefinitely. If your record has read p=none for a year, it is doing nothing for your security.
• Jumping straight to p=reject. The opposite error. Publishing reject before fixing sender alignment bounces your own mail with no warning. Always pass through quarantine.
• Ignoring the pct tag. Treating the move to enforcement as all-or-nothing throws away the safest de-risking tool in the standard. Ramp the percentage.
• Forgetting subdomains and inactive domains. Subdomains inherit the parent policy unless you set sp=. Parked or non-sending domains should publish p=reject outright, since no legitimate mail comes from them, but they are frequently left wide open.
• Enforcing before all senders are inventoried. If you have not found every legitimate sender in your reports, you cannot know what reject will break. Finish the inventory first.

The deadlines pushing many organisations up this ladder are not optional any more. The bulk-sender requirements from the major providers are covered in why Gmail, Yahoo and Microsoft now require DMARC and revisited in the Google and Yahoo rules, one year on. The direction of travel is clear: p=none is increasingly treated as not having DMARC at all.

Where this fits in the bigger picture

The policy is the steering wheel, but it only works if the rest of the car is sound. SPF and DKIM have to be correct and aligned, or enforcement punishes your own mail. Reporting has to be flowing, or you are enforcing blind. And once you are at reject, complementary standards become worth adding: MTA-STS to protect the transport layer, and BIMI to display your logo, which several providers gate behind enforced DMARC. You can read the requirements for each on the products overview and the DMARC product page, and check whether you qualify for a logo with the BIMI checker and do you actually need BIMI.

If you would rather not run the staged rollout yourself, that is precisely what DMARC Engine is built to do. The platform takes your domain from p=none to p=reject safely, watching the reports, surfacing every sender, and only tightening the policy when the data says it is safe, so you reach full protection without an email outage. You can keep an eye on changes over time with emailed monitoring, and check your obligations against the major providers on the requirements page.

The practical takeaway

Three values, one decision. p=none watches and protects nothing. p=quarantine sends failing mail to junk and is your staging ground. p=reject refuses forgeries outright and is the goal. The right policy is not whichever feels safest in the moment, it is the strictest one your reports prove your legitimate senders can survive. Start at none, fix alignment for every real sender, ramp through quarantine with the pct dial, and finish at reject.

The fastest way to know where you stand right now is to read your live record: run your domain through the free DMARC checker, see your current p= value, and let the gap between that and p=reject define your next step. If you want that journey handled end to end, with the reports read for you and the policy advanced only when it is safe, that is exactly what the done-for-you DMARC service exists to do.