DMARC p=none vs quarantine vs reject: Which Policy to Use

A DMARC record has one setting that matters more than all the others: the policy, written as p=none, p=quarantine or p=reject. It tells receiving mail servers what to do with a message that claims to be from your domain but fails authentication. Pick the wrong one and you either leave your domain open to spoofing or block your own legitimate mail.

This guide explains each policy, the order to move through them, and how to tell when it is safe to move on.

What the policy applies to

DMARC checks whether a message passed SPF or DKIM and whether the domain that passed matches the domain in the From header. That match is called alignment. A message that passes neither aligned check fails DMARC, and the policy decides its fate. Messages that pass are delivered normally whatever the policy says.

So the policy only ever affects mail that fails. The risk in a strict policy is not spam being blocked; it is your own mail failing because a sending service was never set up to align. That is why the sequence below exists.

p=none: monitor only

v=DMARC1; p=none; rua=mailto:dmarc@example.com

Receivers deliver failing mail as if DMARC were not there, but they send you aggregate reports listing every source that sent mail as your domain and whether it passed. This is where every domain should start.

What it gives you: a complete picture of who sends as you, including services you forgot and spoofers you did not know about. What it does not give you: any protection. A domain at p=none can be spoofed freely, and some receivers treat it as barely better than no record.

Stay here until the reports show that every legitimate source passes. For a small domain that takes a week or two; for a company with many sending services, a month or more. The rua address is essential at this stage. Without it you are flying blind, and the free DMARC checker flags a record that lacks one.

p=quarantine: send failures to spam

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com

Failing mail is accepted but marked as suspicious, which in practice means the spam folder. This is the middle step: a spoofed message no longer reaches the inbox, but a legitimate message from a misconfigured service is not lost either, just hidden.

The pct tag lets you apply the policy to a percentage of failing mail. Start at pct=25, watch the reports for a week, then raise it to 50, 75 and 100. If a legitimate source starts failing at 25%, only a quarter of its mail is affected while you fix it.

p=reject: refuse failures

v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:dmarc-forensic@example.com

Failing mail is rejected during delivery. The spoofer gets a bounce; the recipient never sees anything. This is the destination for every domain that sends mail, and the only policy that fully protects your brand from impersonation.

Move here once you have run at p=quarantine; pct=100 for a few weeks without any legitimate source failing. The reports will keep coming, and you should keep reading them: a new service added without alignment will fail silently at reject, and the reports are how you find out.

The tags that go with the policy

The DMARC record generator builds a record from these choices and shows where to add it in DNS.

Which policy do you need?

• You send more than 5,000 messages a day to Gmail or Yahoo. Both require a DMARC record for bulk senders. p=none satisfies the letter of the requirement, but a stricter policy is part of what they call a good reputation.
• Your domain is used for invoices, password resets or anything a phisher would imitate. Get to p=reject. This is the case the policy exists for.
• A domain that sends no mail at all. Publish v=spf1 -all and p=reject straight away. There is no legitimate mail to break.
• You have just set up DMARC. p=none with a rua address, and a calendar reminder to review the reports.

Common mistakes

• Jumping straight to reject. The usual result is that a helpdesk or billing tool that was never aligned stops delivering, and nobody notices for days.
• Never leaving none. Many domains publish p=none to satisfy a checklist and stay there for years. It protects nothing.
• Forgetting subdomains. Without sp=, subdomains inherit the main policy, which is fine; but if you set a strict main policy and a weak sp to avoid breaking something, spoofers will use the subdomains.
• A broken SPF record. DMARC needs SPF or DKIM to pass. If SPF returns a PermError, as described in SPF PermError: too many DNS lookups, you are relying on DKIM alone.

For the bigger picture of how SPF, DKIM and DMARC work together, see our guide to email authentication.