DMARC p=none vs Quarantine vs Reject: Which Policy to Use

DMARC has three policies. p=none only monitors: failing mail is delivered and you receive reports. p=quarantine asks receivers to treat failing mail as suspicious, typically sending it to spam. p=reject asks receivers to refuse failing mail outright. Start at none, then tighten once reports show your real senders pass.

What the policy actually controls

DMARC does not decide whether SPF or DKIM pass. It sits on top of them. A message passes DMARC when SPF or DKIM passes and the passing domain aligns with the visible From domain. The p= tag tells receivers what you want done with messages that fail that test. Receivers keep discretion, so a policy is a request that most large providers follow, not a guarantee.

Policy	Failing mail is…	Gives you	Risk
p=none	Delivered normally	Reports and visibility	Spoofers are not blocked
p=quarantine	Usually routed to spam	Partial protection	Legitimate mail may land in spam if misconfigured
p=reject	Refused at the receiving server	Strongest anti-spoofing	Legitimate mail from missed senders bounces

Why most domains should start at none

Almost every organisation has senders it forgot: a billing platform, an old newsletter tool, a form plugin. With p=none those senders keep working while the aggregate reports (sent to your rua= address) show you who is sending as your domain and whether they pass.

A starter record from BusinessMCP’s guide:

v=DMARC1; p=none; rua=mailto:[email protected]

You can publish it today with the help of the free BusinessMCP checker, which shows the exact DMARC record to paste when none exists and verifies it after you publish. The wider setup steps cover SPF and DKIM, which must be in place for DMARC to mean anything.

The staged rollout

BusinessMCP’s SPF, DKIM and DMARC guide lays out a six-step path that matches common industry practice:

1. Publish p=none with a rua= address.
2. Monitor reports for two to four weeks.
3. Fix legitimate sources that fail, by adding SPF includes or enabling DKIM.
4. Move to p=quarantine, optionally starting with pct=25.
5. Monitor for another two to four weeks.
6. Move to p=reject.

Key takeaway: the policy change is the easy part. The work is the weeks of report-reading that tell you it is safe to change it.

Using pct to phase in enforcement

The optional pct= tag applies the policy to a percentage of failing messages. At p=quarantine; pct=25, receivers should quarantine about a quarter of failing mail and treat the rest as if the policy were one step lower. That gives you a smaller blast radius while you watch for complaints from users whose mail went missing. Raise the percentage in steps, for example 25, 50, then 100, pausing at each to read reports. RFC 7489 defines the tag; behaviour at individual receivers can vary, so treat it as a soft rollout aid rather than a precise dial.

Reading aggregate reports without losing a week

Aggregate reports arrive as compressed XML from receivers like Google and Microsoft. Reading them raw is miserable, so most people either use a free reporting service or write a small script. You are looking for three things:

• Unknown sources sending as your domain. These are either forgotten legitimate services or spoofers.
• Known sources failing SPF or DKIM alignment. These need DKIM signing on your domain.
• Volumes. A source with a handful of messages may be noise; a source with thousands is probably real mail you need to fix before enforcing.

Reports are aggregate and delayed by a day or more, so they will not catch a mistake right away. After each policy change, also watch bounce notices and ask a few colleagues to confirm mail still arrives.

Which policy fits which situation

Situation	Reasonable policy
New domain, just starting to send	none, then move up as volume grows
Established domain, complete sender inventory, clean reports	quarantine then reject
Domain that never sends mail	reject (plus an SPF record that authorises nothing)
Many third-party senders you do not control	Stay at none or quarantine until each is aligned

Parked or non-sending domains are good early candidates for p=reject, because there is no legitimate mail to lose and spoofers love unused domains.

Common mistakes

• Jumping to reject on day one. The most common way to bounce your own invoices.
• Never leaving none. It satisfies bulk-sender rules but leaves spoofing open. Google’s DMARC setup page describes the phased approach.
• Ignoring subdomains. The sp= tag sets a policy for subdomains; without it they inherit the main policy.
• Not aligning third-party senders. A marketing platform signing with its own domain fails DMARC for you even though DKIM passes.
• Broken reporting address. If the mailbox in rua does not exist, you are flying blind.

Where policy fits in the bigger deliverability picture

DMARC enforcement protects your brand from impersonation and is increasingly expected, but it does not by itself lift inbox placement for your own legitimate mail. If everything passes and messages still go to spam, read why mail goes to spam despite authentication. For provider rules that make a published DMARC policy mandatory, see Gmail and Yahoo bulk sender requirements, and use BusinessMCP’s Google and Yahoo requirements guide for a plain-language summary with a verification date. Always confirm current requirements with the providers.

Reading the trade-off honestly

There is a real tension in DMARC enforcement. The stricter the policy, the better the protection against someone sending forged mail in your name, and the greater the cost of a mistake. Large brands and banks go to reject because phishing under their name is a serious problem. A five-person company that sends a monthly newsletter has less to lose from spoofing and more to lose from a misconfigured vendor. Both can be right.

A useful way to decide is to ask three questions:

1. Do I know every system that sends as my domain? If not, stay at none until the reports tell you.
2. Is a forged message from me likely to cause harm? If customers pay invoices based on email, the answer leans toward enforcement.
3. Do I have someone who will read reports and respond? Enforcement without monitoring is a delayed outage.

What changes for deliverability

Moving to quarantine or reject does not directly raise your inbox placement. What it does is stop other people from damaging your reputation by spoofing your domain, and it signals to providers that you manage the domain seriously. For bulk senders, Google and Yahoo require a published policy, but p=none satisfies it, according to BusinessMCP’s Google and Yahoo requirements guide. Enforcement is therefore a security decision first and a deliverability decision second.

Subdomain policy and forwarding

Two edge cases are worth knowing. First, mail forwarded through mailing lists or auto-forwarders can break SPF, and some lists modify messages in ways that break DKIM. A strict policy can therefore cause forwarded mail to be rejected. Second, set sp= deliberately: a parent at reject with subdomains inheriting the same policy is fine if every subdomain is aligned, and a source of surprises if not. Test each subdomain with a real message and check the headers, as shown in the deliverability test walkthrough.