How do DMARC quarantine and reject policies affect sender reputation and email delivery?
Updated on 26 Sep 2026: We updated this guide for RFC 9989 and clarified how quarantine or reject affects delivery and reputation.
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 states that the domain owner considers that failure an invalid use of the domain, which often results in refusal. 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 strong signal that failing mail is invalid; receivers decide whether to block it.
- Reputation: Receiver-side assessments 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.
What quarantine and reject actually change
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, which reputation signals 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 classifies percentage-based enforcement as historic and gives clearer treatment to testing, forwarding, mailing lists, and receiver overrides.
Current policy rules
- No percentage rollout: The pct tag is now historic because receivers applied intermediate values inconsistently.
- Testing mode: The new t=y signal requests the next more lenient policy: none for quarantine, or quarantine for reject.
- 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.
RFC 9989 says receivers must not reject a message solely because the domain publishes p=reject. They must combine DMARC with other evidence, and when no other analysis is available, treat the failure as p=quarantine. Real-world handling still varies, so aggregate reports remain the record of what receivers actually did.
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. For domains used by people who post to Internet mailing lists, RFC 9989 recommends at least one month at p=none followed by an equally long p=quarantine period before p=reject.
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 makes the pct tag historic because receiver behavior was unreliable at intermediate values. Older implementations can still parse it, which makes it unpredictable rather than safe. The stronger control is to fix legitimate sources before changing policy.
|
|
|
|
|---|---|---|---|
p=none | No special handling | Normal filtering | Spoofing continues |
p=quarantine | Treat as suspicious | Often junked | Missed mail |
p=reject | Treat as invalid | Often blocked | Lost mail |
DMARC policy effects in normal operation.
How reject changes delivery
Reject is the stronger policy because it states that the domain owner considers DMARC failures an invalid use of the domain. A receiver can refuse the message during SMTP, but RFC 9989 requires it to use other knowledge and analysis rather than reject solely because p=reject is published.
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.
DMARC policy also does not replace IP reputation. A message can pass DMARC and still land in spam because the sending IP, complaint rate, bounce pattern, volume stability, or content signals are poor. Enforcement helps receivers identify the responsible aligned domain; it does not repair unrelated reputation problems.
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
Operational readiness checks based on legitimate mail, not an industry pass-rate standard.
Observe
Unknown
Source ownership is incomplete.
Hold
Fix first
Any business-critical stream still fails.
Quarantine
Limited risk
Residual legitimate failures are known and monitored.
Reject
Ready
No approved stream depends on a DMARC failure.
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.
How Suped supports policy rollout
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 view
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 view
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
Choosing none, quarantine, or reject
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.
