How do DMARC quarantine and reject policies affect sender reputation and email delivery?
Updated on 25 Jul 2026: We updated this guide for RFC 9989 and safer quarantine-to-reject rollouts.
A DMARC quarantine or reject policy affects delivery first, not sender reputation first. p=quarantine asks receivers to treat mail that fails DMARC as suspicious, commonly by placing it in junk. p=reject asks receivers to refuse that failing mail. Neither policy is the same as a spam complaint, and quarantine placement caused by DMARC is not automatically a reputation penalty for authenticated mail that passes DMARC.
The caveat is important. If legitimate email fails DMARC, enforcement turns an authentication problem into a delivery problem. Quarantine can hide the problem in junk folders. Reject can stop the message completely. Treat enforcement as an operational rollout, not a DNS edit.
- Quarantine: A request to accept failing mail but handle it as suspicious.
- Reject: A request to block failing mail before it reaches the mailbox.
- Reputation: A receiver-side score built mainly from authenticated mail behavior, complaint rates, bounces, engagement, volume, history, and abuse signals.
Suped's DMARC monitoring turns aggregate reports into source-level visibility, so enforcement decisions are based on actual passing and failing mail streams instead of guesswork.
The direct answer
DMARC enforcement affects sender reputation indirectly. The policy tells receivers what the domain owner wants done with mail that fails DMARC. The receiver still makes the final decision. A receiver can junk a quarantined message, reject it, accept it, or apply its own local filtering rules.
Separate the issue into two parts. First, what happens to a specific failing message. Second, what reputation score a receiver applies to future mail. Quarantine and reject clearly change the first part. They do not, by themselves, prove that future authenticated mail deserves worse inbox placement.
Receiver behavior is local
DMARC is a policy request. Receivers use it together with their own abuse controls, forwarding logic, mailbox rules, and risk scoring. When a receiver overrides the published policy, current DMARC guidance says the reason should appear in aggregate reporting.
- Policy request: The domain owner publishes the requested treatment for failing mail.
- Local decision: The receiving mailbox provider decides the final disposition.
- Reputation signal: Authenticated wanted mail and authenticated unwanted mail still drive the strongest reputation outcomes.
What RFC 9989 changes for enforcement
RFC 9989 now defines DMARC and obsoletes RFC 7489. The quarantine and reject policies remain, but rollout guidance has changed. The standard removed percentage-based enforcement and gives clearer treatment to testing, forwarding, mailing lists, and receiver overrides.
Current policy rules
- No percentage rollout: The pct tag was removed because receivers applied intermediate values inconsistently.
- Testing mode: The new t=y signal asks receivers not to apply the declared policy. It is not a 10%, 25%, or 50% rollout control.
- DKIM at reject: A domain at p=reject must not rely only on SPF for DMARC pass because forwarding commonly breaks SPF.
- Receiver analysis: Receivers use the policy with other knowledge and analysis, especially for indirect mail such as forwarding and mailing lists.
For a staged rollout, use aggregate reports to identify legitimate failures, fix SPF or DKIM alignment, and apply enforcement first to a controlled sending domain or subdomain when practical. Move the broader domain only after the remaining failures are understood.
How quarantine changes delivery
Quarantine is the cautious enforcement step. If a message claims to be from your domain but fails DMARC, the receiver is asked to keep it away from the inbox. In practice, that often means the junk folder, although some receivers use different handling.
A quarantined message does not hurt reputation in the same way as a recipient clicking spam. The larger risk is operational. If real customer receipts, password resets, invoices, or sales messages fail DMARC and land in junk, people miss them. The sender then sees support tickets, lost replies, and lower conversion, even if the reputation system has not directly punished the domain.
Quarantine policy recorddns
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com
Do not add pct=25 as a safety control. RFC 9989 removed the pct tag because receiver behavior was unreliable at intermediate values. The stronger control is to fix legitimate sources before changing policy.
|
|
|
|
|---|---|---|---|
p=none | Monitor | Deliver normally | Spoofing continues |
p=quarantine | Junk | Hidden failures | Missed mail |
p=reject | Block | Clear failure | Lost mail |
DMARC policy effects in normal operation.
How reject changes delivery
Reject is the stronger enforcement policy because it asks the receiver not to deliver failing mail. It gives clearer protection against exact-domain spoofing, but it leaves less room for legitimate misconfigured mail to survive.
Reject also gives a clearer failure signal when the message came from infrastructure you control. An SMTP 5xx response or bounce is easier to notice than a message silently sitting in a junk folder. Repeated DMARC bounces can raise the bounce rate recorded by a sending platform, but the reject policy itself does not automatically lower mailbox-provider reputation. The signal is less useful for forwarded or abusive mail because the failure does not always reach your system.
Reject is a delivery decision
Do not publish reject because it sounds cleaner. Publish it when reports show that legitimate traffic has already been fixed, and make aligned DKIM the durable path through forwarding.
- Forwarding: Forwarded messages commonly break SPF, while DKIM can survive if the message is not modified.
- Mailing lists: List software can alter the message or From address, so test domains used by people who post to lists.
- Vendors: One forgotten platform can turn a reject policy into customer-visible failure.
- Bounces: A bounce is useful only when it reaches a team that can fix the sender.
Reject policy recorddns
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com
Why reputation usually stays separate
Authentication tells the receiver which identity deserves the reputation outcome. If mail passes DMARC, the receiver has a stronger basis for applying domain reputation to that message. A DMARC pass validates use of the From domain, but it does not prove that the message is wanted or safe. If mail fails DMARC, the message is not authenticated as your domain, even if the visible From address claims your brand.
That distinction matters. A spoofed message failing DMARC under your domain should not be treated the same as your authenticated newsletter generating complaints. The first is unauthenticated abuse. The second is wanted or unwanted mail that the receiver can connect to your sending identity.
What changes
- Disposition: Failing mail is more likely to be junked or blocked.
- Visibility: Reports expose which sources fail SPF or DKIM alignment.
- Risk: Misconfigured legitimate senders become harder to ignore.
What does not automatically change
- Complaints: DMARC junk placement is not the same as a user spam report.
- Engagement: Authenticated campaigns still earn their own inbox history.
- Control: Receivers still apply their own filters after reading the policy.
The practical question is not whether quarantine is secretly poisoning your reputation. The practical question is whether enough legitimate mail still fails DMARC that enforcement will damage delivery outcomes.
When quarantine is safer
Quarantine is usually safer when the domain has many mail streams, unclear vendor ownership, legacy systems, shared support tooling, or regular forwarding. It buys time. It also reduces brand abuse compared with monitoring only, because receivers get a stronger instruction for unauthenticated mail.
A DMARC rollout path: monitor, find sources, fix authentication, check failures, quarantine, reject.
Skip quarantine only when reports are clean and the domain has a simple sending setup. For a complex company, the normal path is monitoring, cleanup, quarantine, then reject.
Policy readiness bands
Illustrative thresholds based on the share of legitimate traffic that still fails DMARC.
Observe
Unknown
Source ownership is incomplete.
Hold
>1%
Legitimate failures still need owners.
Quarantine
0.1-1%
Failures are low but still worth watching.
Reject
<0.1%
Failures are mostly spoofing or dead traffic.
How to roll out without hurting delivery
The safest rollout is measured and report-driven. Each legitimate sender should be authenticated properly or intentionally excluded before policy enforcement affects users.
- Inventory: List every system that sends mail using the domain, including billing, support, marketing, HR, product, and one-off tools.
- Validate: Check the DNS record with the DMARC checker before relying on reports.
- Create: If there is no record yet, generate one with the record generator.
- Monitor: Run p=none long enough to see weekday, weekend, batch, and campaign traffic.
- Fix: Configure aligned SPF and DKIM for each legitimate sender, with aligned DKIM as the durable path through forwarding.
- Stage: Apply quarantine to a controlled sending domain or subdomain when practical, then compare aggregate reports. Suped's Hosted DMARC can manage policy changes without repeated DNS edits.
- Enforce: Move to quarantine, then reject, using a safe transition plan when the domain has meaningful traffic.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
After each policy change, review who is failing, whether the source is approved, whether the failure comes from SPF alignment, DKIM alignment, forwarding, or a missing sender setup, and whether the volume is high enough to affect real users.
Where Suped fits
Suped's platform turns DMARC aggregate reports into a managed enforcement workflow. Teams can identify sending sources, investigate SPF or DKIM alignment failures, apply hosted policy changes, and set alerts when failure volume rises.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
The practical workflow is to identify unverified sources, assign fixes, confirm the domain match for SPF or DKIM, then move policy only when the remaining failures are not legitimate mail. The multi-tenant dashboard supports the same process across multiple customer domains for MSPs and agencies.
A practical Suped workflow
- Detect: Use issue detection to find failing sources and broken authentication.
- Fix: Follow source-specific steps before increasing policy enforcement.
- Stage: Use hosted policy controls when DNS change windows slow the rollout.
- Alert: Trigger real-time alerts when failures increase after quarantine or reject.
Common policy scenarios
The right policy depends on the domain's sending reality, not on a universal preference for quarantine or reject. These patterns help identify what to publish next.
|
|
|
|---|---|---|
New domain | p=none | Needs data |
Complex senders | Quarantine | Catches gaps |
Clean reports | Reject | Blocks spoofing |
No sending | Reject | Protects brand |
Forwarding-heavy | Quarantine | Lower breakage |
Policy choice by operating scenario.
If the specific concern is whether rejections hurt reputation at large mailbox providers, treat that as a separate question. The short version is that Gmail and Yahoo care much more about authenticated mail quality than about the fact that your domain asks receivers to reject unauthenticated mail.
Views from the trenches
Best practices
Hold p=none until every known sender has stable SPF or DKIM pass with a matching domain.
Use quarantine as a short observation stage when source ownership or forwarding is unclear.
Move to reject only after reports show failed mail is mostly spoofing or abandoned traffic.
Common pitfalls
Treating quarantine spam placement as a complaint signal leads teams to chase the wrong fix.
Skipping report review hides legitimate mail failures because quarantine creates no bounce.
Expecting every receiver to honor the exact DMARC action creates false confidence in rollout.
Expert tips
Compare aggregate reports by source before and after each policy change, not only totals.
Separate forwarding failures from vendor misconfiguration before deciding reject is risky.
Keep non-sending domains at reject once you confirm no approved mail stream exists today.
Marketer from Email Geeks says quarantine was designed as a graduated enforcement step, and DMARC should be treated as a policy signal instead of a spam filter.
2022-03-01 - Email Geeks
Marketer from Email Geeks says some receivers accept mail that fails under reject, and others reject or junk mail under quarantine.
2022-03-02 - Email Geeks
The practical choice
Quarantine and reject do not operate like spam complaints. They change how receivers handle mail that fails DMARC. The real delivery risk comes from legitimate mail that still fails authentication when enforcement starts.
- Use none: When you are still discovering senders or fixing known failures.
- Use quarantine: When most mail is clean, but you still need a cautious enforcement step.
- Use reject: When reports show that failed mail is mainly spoofing, broken forwarding, or traffic you no longer support.
Suped's DMARC platform connects policy status, source discovery, authentication failures, hosted controls, and alerts. That workflow helps teams verify legitimate mail before moving to stronger enforcement.
