Jorge LewisDMARC p=none vs quarantine vs reject is a one-word choice in a DNS record that decides what every mailbox provider on earth does with mail that fails authentication for your domain. Pick too loose and anyone can spoof your domain without consequence. Tighten too early and the mail you lose is your own. This guide is only about that choice: what each policy value actually does, when a cold email sender should move between them, and where the experts genuinely disagree about the end state. If you have not published the records yet, start with our SPF, DKIM, and DMARC setup guide and come back when _dmarc.yourdomain.com resolves.
We make this call on every sending domain we touch. Our parent agency, Referral Program Pros, has run more than 4,000 outbound campaigns and booked over 7,000 meetings, and GTM Bud was built on that same playbook, backed by a guarantee of 5 percent positive replies on LinkedIn or 1.5 percent on email, with a full refund if we miss it. Policy decisions made blind are how senders end up bouncing their own campaigns, so everything below is the sequence we actually run.
What does each DMARC policy actually do?
A DMARC policy is the instruction in the p tag of your DMARC record that tells a receiving server what to do with a message that fails both SPF and DKIM alignment. There are exactly three values. p=none asks the receiver to deliver failing mail normally and only report it to you. p=quarantine asks the receiver to treat failing mail as suspicious, which in practice means the spam folder. p=reject asks the receiver to refuse failing mail outright during delivery, so the sender gets a bounce instead of a placement. The policy only ever acts on mail that fails: a message that passes aligned SPF or DKIM is delivered identically under all three. That is the single most misunderstood fact in this decision. The policy is a statement about imposters, and the only way it touches your own campaigns is when your own configuration makes you look like one.
| Policy | What receivers do with failing mail | When a cold sender should run it | Cost if your own mail is misconfigured |
|---|---|---|---|
p=none | Deliver normally, send aggregate reports | First weeks on any domain, while reports prove what passes | None, which is also why it protects nothing |
p=quarantine | Route it to the spam folder | After reports show every legitimate source passing with alignment | Your own misaligned mail lands in spam, silently |
p=reject | Refuse it during SMTP, sender gets a bounce | Once quarantine has run clean and the domain has a single sending source | Your own misaligned mail bounces and never arrives |
One nuance before the ladder: these are requests, not commands. RFC 7489 defines the policy as the domain owner’s preference, and receivers overlay their own local policy, so some providers treat quarantine and reject identically or downgrade reject to quarantine. The disposition field in your aggregate reports shows what each receiver actually did.
Why should every cold sender start at p=none?
Because p=none is the only policy that generates evidence without risking your own mail. It takes no action against anything, and with a rua reporting address in the record, it buys you daily aggregate reports listing every source sending as your domain and whether each one passed alignment. That visibility is the entire point of the first phase: cold email stacks are exactly the setups where a sending platform signs DKIM with its own domain or routes bounces through its own Return-Path, which passes raw checks and fails alignment. At p=none that misconfiguration shows up as a report line. At p=reject it shows up as a bounced campaign.
There is also a compliance floor here. Google’s email sender guidelines require anyone sending 5,000 or more messages per day to Gmail accounts to publish a DMARC record with a minimum policy of p=none and alignment on at least one of SPF or DKIM, and Yahoo’s Sender Hub mirrors the requirement. So the bulk-sender box is ticked at p=none. The full threshold mechanics, including why most cold senders sit under the 5,000-a-day line anyway, are in our guide to the Google and Yahoo bulk sender rules.
But none-first is not none-forever. A domain parked at p=none indefinitely is a domain any spammer can impersonate with no consequence beyond a report you may never read, and sustained spoofing traffic feeds the reputation systems that score your real mail. Monitoring mode is a phase with an exit, not a destination.
When should you move from p=none to p=quarantine?
Move when the reports say your legitimate mail passes, not when the calendar says you are bored. The practical gate we use, and the one vendor enforcement roadmaps converge on, has two parts. First, time in monitoring: run p=none for two to four weeks so every sending source you forgot about has a chance to appear in the reports. Second, a pass-rate threshold: enforcement roadmaps from DMARC monitoring vendors such as DMARC Report recommend a consistent aligned pass rate above 95 percent across at least 30 days of reports before tightening. PowerDMARC’s cold email guidance likewise says to review reports for at least 30 days before moving to stricter enforcement, per its published guide. A dedicated cold sending domain with one sending tool usually clears both gates at the fast end, because there is only one source to verify.
Two record tags matter at this step and nowhere else. The pct tag applies the policy to a sampled percentage of failing mail, defaulting to 100 per RFC 7489, so p=quarantine; pct=25 quarantines roughly a quarter of failures while the rest ride as p=none. It is a gentle ramp for a crowded shared domain, and mostly unnecessary on a single-source cold domain. The sp tag sets a separate policy for subdomains, which otherwise inherit the root policy. If you cannot yet tell a pass from an aligned pass in the reports, fix that first with our walkthrough on how to read DMARC reports, because quarantine applied to misread reports is how senders spam-folder their own pipeline.
Quarantine or reject: where should a cold sender end up?
Here the sources genuinely split, and it is worth stating the disagreement plainly rather than pretending there is one answer. PowerDMARC’s guide to DMARC for cold emails lands on p=quarantine as often the optimal choice for cold senders, on the logic that a misconfigured legitimate source lands in spam rather than vanishing, and says p=reject should mostly be avoided in cold email campaigns. Folderly’s policy comparison prescribes the full staged path instead: none for discovery, quarantine for staged enforcement, and reject as the destination of the rollout, gated on authentication data showing the change breaks no real mail. Both positions are vendor-published, and both agree on the sequence; they disagree on where it should stop.
Our read, from running this across the agency’s sending domains: the split dissolves once you ask what kind of domain you are protecting. PowerDMARC’s caution is the right default for a shared company domain with a CRM, a help desk, and a billing tool all sending, because any one of them can drift out of alignment and reject turns that drift into silent loss. A dedicated cold sending domain is the opposite case. It has exactly one sending source, no mailing-list traffic, and reports that run clean within weeks, which makes it a strong candidate for p=reject eventually. One caveat from the standards side: the updated DMARC specification known as DMARCbis, which moved DMARC onto the IETF standards track in 2026, explicitly discourages p=reject for domains whose mail regularly passes through mailing lists, per DMARC monitoring vendors tracking the change. Cold sending domains have no such traffic, which is precisely why they can go further than the general-purpose advice suggests.
What does getting it wrong cost at each step?
The misconfiguration cost escalates with the policy, and the failure is always the same one: your own mail failing alignment while an enforcement policy is live.
- At p=none, errors cost nothing and teach everything. A misaligned tool shows up as failing rows in the aggregate report while every message still delivers. This is the only stage where mistakes are free, which is the whole argument for not skipping it.
- At p=quarantine, errors send your own campaigns to spam. Nothing bounces, nothing errors, reply rates just sag. Because quarantined mail is invisible to you, this failure mode can run for weeks, and it looks exactly like a copy or targeting problem. If reply rates dropped after you tightened policy, check disposition in the reports before rewriting a single subject line, and see our guide on why cold emails go to spam for the other suspects.
- At p=reject, errors bounce your own mail. Receivers refuse the message during SMTP with a 550-class error, so at least the failure is loud: your sending tool logs bounces instead of silence. Loud is better than silent, but the mail is gone either way, and a burst of rejections does its own reputation damage.
A related trap sits one layer down: an SPF record that exceeds the 10-lookup limit returns PermError, which makes SPF unable to pass at all and leaves DKIM carrying your entire DMARC result under any enforcement policy. That budget problem has its own guide on fixing SPF too many DNS lookups.
Does a stricter policy improve deliverability?
No, and this is the expectation to kill before you touch the record. DMARC policy is spoofing protection, not reputation. It instructs receivers about mail that fails authentication; it adds nothing to mail that passes. Folderly’s comparison makes the same point from the receiving side: a DMARC pass does not force a receiver to inbox the message, per its published policy guide. Your placement is decided by domain reputation, complaint rate, engagement, and volume, the layer covered in our cold email deliverability guide. What a tightened policy does buy, indirectly and over time, is a cleaner reputation surface: once spoofed mail bounces instead of delivering, strangers can no longer generate complaints and blocklist entries against your domain name. That is real value. It is just not an inbox placement lever, and anyone promising that p=reject will fix open rates is selling the wrong product.
Frequently asked questions about DMARC p=none vs quarantine vs reject
Does p=none satisfy the Google and Yahoo bulk sender requirement?
Yes. Google requires senders of 5,000 or more messages per day to Gmail accounts to publish a DMARC record with a minimum policy of p=none, with alignment on at least one of SPF or DKIM, per its email sender guidelines, and Yahoo mirrors this in its Sender Hub. The minimum is deliberately low: the requirement is about publishing a policy and passing alignment, not enforcement. Compliance starts at p=none; protection does not.
What does the pct tag do and should cold senders use it?
The pct tag applies your quarantine or reject policy to only a percentage of failing mail, with a default of 100 per RFC 7489. Setting pct=25 on p=quarantine means roughly a quarter of failing messages go to spam while the rest are handled as p=none. It is a useful ramp for large shared domains with messy sending estates. A cold sending domain with one source rarely needs it, because the pass rate should be near total before you tighten at all.
Will moving to p=reject improve my open or reply rates?
No. Policy acts on mail that fails authentication, which protects your domain from spoofing; it adds no reputation to mail that already passes. Open and reply rates are driven by sender reputation, targeting, and copy. A stricter policy helps indirectly over time by stopping spoofed traffic from polluting your domain reputation, but publishing p=reject on day one buys no placement.
Do receivers always honor quarantine and reject exactly as published?
No. RFC 7489 defines the policy as a request, not a command, and providers overlay local policy. Some treat quarantine and reject identically, and some downgrade reject to quarantine. The disposition field in your aggregate reports shows what each receiver actually did with each batch, which is why report reading beats assuming.
What happens to my own mail if I move to p=reject too early?
Receivers refuse it during the SMTP conversation and return a 550-class bounce, so every misaligned message never arrives. The classic trigger is a sending tool signing DKIM with its own domain or using its own bounce domain for SPF, which passes raw checks and fails alignment. At p=none that misconfiguration is a report line, at p=quarantine it is silent spam placement, and at p=reject it is the whole send gone.
Should the subdomain policy be different from the root domain policy?
Often yes, and the sp tag controls it, since subdomains inherit the root policy unless overridden. A common pattern is p=reject on a root domain that sends nothing, with subdomain handling set deliberately for streams that do send. Cold outreach is better run on separate lookalike domains with their own simple policies, which is how a managed cold email automation tool provisions sending infrastructure by default.
Pick the policy ladder once, then let the reports drive it
The DMARC p=none vs quarantine vs reject decision is a ladder, not a menu. Start at p=none with a rua address and let two to four weeks of reports prove what passes. Move to p=quarantine once the aligned pass rate holds above the 95 percent bar vendors converge on. End at p=quarantine if the domain is shared and messy, or carry a clean single-source cold domain through to p=reject and let spoofers eat the bounces. At every rung, remember what the lever does: it protects your name from imposters, and it earns you nothing in the inbox that reputation has not already earned.
If you would rather not babysit a DNS ladder at all, GTM Bud provisions authenticated sending domains with sane policies as part of onboarding, at a flat monthly rate per connected LinkedIn account: $600 per month covering up to 1,000 leads contacted, with a 14-day trial and no per-lead or per-campaign charges. Email sending is part of the campaign sequence and is not sold separately. See how teams running outbound email for startups use it to keep policy, alignment, and placement someone else’s problem while the meetings land on their calendar.