A DMARC policy of p=quarantine asks receiving mail servers to treat failing messages as suspicious, usually routing them to spam or applying extra scrutiny, while p=reject asks receivers to refuse the message outright at the SMTP level. Quarantine keeps a recovery path for legitimate mail that fails authentication by mistake, whereas reject removes that path entirely. Most teams should move through a phased progression, from monitoring, to quarantine, to reject, informed by reporting data and a full inventory of the domains that send mail on their behalf, as explained in Surviving the Privacy Era: Why Your Emails Aren’t Getting Opened.
TL;DR:
- Moving from quarantine to reject should be phased gradually, using the pct tag to control the percentage of messages impacted and avoid disruption.
- Despite publishing a strict DMARC policy, receivers retain discretion and may override instructions based on additional spam and reputation checks.
- Key causes of DMARC failures include missing or misconfigured SPF/DKIM, delegated senders not authorized, and header modifications from forwarding or mailing lists.
- Implementing full enforcement requires a complete sender inventory, correct authentication setup, and continuous reporting to measure legitimate versus failed mail sources.
- Reaching reject status is worthwhile for domains sending valuable or high-risk mail, provided careful preparation and ongoing monitoring prevent blocking legitimate messages.
Digistrat
Move Toward Safer DMARC Enforcement
Digistrat assesses sender reputation, infrastructure, and list quality to help email teams address deliverability issues and protect email performance.
Table of Contents
- What quarantine and reject actually ask receivers to do
- Deployment controls: pct, subdomain policy and alignment modes
- Why mail ends up quarantined or rejected in the first place
- Choosing between quarantine and reject for each message stream
- A stepwise checklist for moving safely to reject
- Why the extra effort to reach reject is usually worth it
- How Digistrat gets you from quarantine to reject without the guesswork
- Where these definitions and standards come from
- Sources
- FAQ
What quarantine and reject actually ask receivers to do
The distinction between these two policies comes straight from the standard itself. Under RFC 7489, p=quarantine requests that mail receivers treat a failing message as suspicious, which in practice commonly means placing it into a spam or junk folder, though a receiver might instead apply heightened scrutiny or flag the message for the recipient without moving it anywhere. The policy does not force a single outcome; it sets an expectation. Reject, by contrast, requests that the receiver refuse the message during the SMTP transaction itself, meaning it is typically bounced back to the sending server before it ever reaches a mailbox, spam folder or otherwise.
That difference matters operationally. A quarantined message still exists somewhere, even if a recipient never opens their spam folder to find it. A rejected message simply never arrives, and the sender gets an SMTP-level bounce instead. For anyone auditing deliverability, this is the practical line between “the mail is hidden” and “the mail never left the building”.
What often surprises teams new to DMARC is how much discretion remains with the receiving server regardless of the policy a domain publishes. The DMARCbis guidance is explicit that a published policy is a request, not a binding instruction. A receiver can still choose to accept a message that technically fails DMARC, quarantine one that technically passes, or apply its own anti-abuse logic on top of whatever the domain owner asked for. Large mailbox providers run additional spam filtering, reputation checks and machine learning models that sit alongside DMARC evaluation, and those systems can overrule the stated policy in either direction.
This is worth remembering when a marketing team insists that “reject means it definitely won’t be delivered” or that “quarantine means it will definitely reach the spam folder”. Neither statement is quite accurate. Reject strongly discourages delivery of unauthenticated mail and, for most well-behaved receivers, does prevent it reaching a mailbox. Quarantine strongly discourages normal inbox placement, but a receiver applying additional scrutiny might still let a message through if other signals look clean. The policy sets intent; the receiver’s own systems decide the outcome.
Deployment controls: pct, subdomain policy and alignment modes
Moving from a passive p=none policy to full enforcement is rarely a single switch. DMARC gives you several tags specifically so you can dial enforcement up gradually rather than flipping a domain from unmonitored to fully rejected overnight.
The most important of these for a safe rollout is pct, which sets the percentage of failing messages the policy actually applies to. Set a lower percentage under a p=reject policy, for example, and only that portion of failing mail is rejected while the remainder is handled as though the policy were quarantine rather than being waved through as none. That detail is easy to miss but genuinely useful: excluded messages are not treated permissively, they simply drop back one level of enforcement rather than reverting to unmonitored delivery. It is a built-in safety net for progressive hardening, as RFC 7489 describes.
A handful of other tags shape how enforcement behaves in practice:
- The sp tag sets a separate policy for subdomains, which matters because many organisations have dozens of subdomains sending mail through entirely different systems than their main domain.
- The adkim and aspf tags control alignment strictness for DKIM and SPF respectively, choosing between relaxed matching (the organisational domain is enough) and strict matching (the exact subdomain must align).
- The t (test) tag flags a record as being in testing mode, a signal some tools and receivers use to interpret enforcement more cautiously while a domain is still being validated.
None of these controls are worth much without reporting. Aggregate reports (RUA) show which sending sources pass or fail authentication and at what volume, while forensic reports (RUF) provide message-level detail on individual failures. RFC 9990 makes the point plainly: visibility through this reporting is what gives domain owners the confidence to move from monitoring into enforcement, because without it you are guessing at the impact of every policy change rather than measuring it.
Why mail ends up quarantined or rejected in the first place
Most DMARC failures trace back to a small set of recurring causes, and understanding them is the difference between fixing the right thing and disabling enforcement out of frustration.
- Unsigned or unauthenticated messages from services the domain owner forgot to inventory, such as a CRM, invoicing tool or event platform sending on the company’s behalf without SPF or DKIM configured.
- Delegated senders that were never authorised in DNS, which is common when a marketing team adds a new email platform without looping in whoever manages the domain’s SPF record.
- SPF alignment failures, where the envelope sender domain does not match the visible “From” domain closely enough for the chosen alignment mode.
- DKIM breakage caused by forwarding or list rewriting, since many mailing lists and forwarding services alter message headers or footers in ways that invalidate the original DKIM signature.
The practical fallout from these issues varies by message type. Transactional mail, password resets and order confirmations tend to come from well-controlled infrastructure and authenticate cleanly, so it is usually marketing sends, third-party tools and anything passing through a mailing list or forwarder that break first under a strict reject policy. Mailing lists are particularly fragile because many of them rewrite the From address or inject footer text, which is precisely the kind of alteration that DKIM is designed to detect and flag as tampering.
Aggregate reports are the tool for separating genuine abuse from false positives. A spike in failures from an IP range tied to a known internal system usually points to a missing SPF entry or an unsigned sender, not to spoofing, and that distinction only becomes visible once you are actually reading the RUA data rather than reacting to isolated complaints.
Choosing between quarantine and reject for each message stream
There is no single correct policy for an entire organisation, because different mail streams carry different risk profiles. The decision is best made stream by stream rather than domain by domain.
- Transactional mail (receipts, password resets, account alerts) usually comes from a small, well-understood set of authenticated sources, making it a reasonable early candidate for reject once validated.
- Marketing mail often runs through several platforms over time and touches more third-party integrations, so it benefits from a longer period under quarantine while those integrations are audited.
- Mail from third-party vendors and delegated senders needs its own authorisation entry in SPF or its own DKIM selector before it can safely sit under anything stronger than quarantine.
- Subdomains, particularly ones used for testing, staging or infrequent campaigns, are worth policing with the sp tag rather than assuming the parent domain’s policy covers them adequately.
The other precondition, beyond message risk, is visibility. Before considering reject for any stream, you need reliable RUA and RUF reporting in place, along with a documented inventory of every system authorised to send as that domain. Without that inventory, moving to reject is closer to guesswork than to a calculated decision, and the DMARCbis draft is candid about receivers applying their own discretion on top of whatever policy you publish, which makes your own visibility even more important as a control you can actually rely on.
Pro Tip: Treat each subdomain as its own risk decision rather than inheriting the parent domain’s policy by default; a forgotten staging subdomain under p=none is a common gap that spoolers exploit.
A stepwise checklist for moving safely to reject
Reaching p=reject without breaking legitimate mail flows is a sequencing problem more than a technical one. The steps below follow the order most practitioners use.
- Confirm SPF and DKIM are correctly configured and aligned for every sending source before touching the DMARC policy itself, since DMARC enforcement only ever amplifies whatever authentication gaps already exist underneath it.
- Build a complete sender inventory, listing every platform, vendor and internal system that sends mail using the domain, including ones added informally by other teams.
- Publish p=none with RUA and RUF enabled and leave it running long enough to see a full cycle of sending activity, including monthly newsletters or quarterly campaigns that a shorter window would miss.
- Move to p=quarantine with a low pct value, then increase it gradually while watching aggregate reports for unexpected failures tied to legitimate senders.
- Progress to p=reject using the same pct ramp, starting small and only increasing once each step shows clean reports for a sustained period.
- Keep an incident playbook ready covering how to identify a blocked legitimate flow quickly, roll back to a lower pct value or revert to quarantine, and re-authorise a sender that was missed during inventory.
Reporting cadence matters as much as the steps themselves. Reviewing aggregate reports on the rollout timeline set out in our 90-day DMARC plan gives most organisations enough signal to catch a misconfigured sender before it causes real damage, rather than finding out weeks later that a customer invoice system has been silently failing.
Reporting is the control that makes enforcement safe. RFC 9990 notes that visibility through aggregate and failure reports is what allows domain owners to establish and maintain accurate authentication deployments, which is precisely what turns a risky jump to reject into a measured one.
Why the extra effort to reach reject is usually worth it
Reject asks more of you operationally than quarantine does, and I think that trade-off is worth making for most domains that send valuable mail, because the alternative leaves impersonation attempts quietly reaching inboxes under someone else’s judgement rather than yours. The organisations that struggle are usually the ones that rush the pct ramp or skip the sender inventory, then blame DMARC when a legitimate vendor gets blocked. Specialist input tends to shorten that path considerably, mainly by catching authorisation gaps before enforcement exposes them rather than after.
How Digistrat gets you from quarantine to reject without the guesswork
Getting from a monitored DMARC record to full enforcement means working through sender inventories, alignment settings and weeks of report data, which is critical in this process. Rather than handing over a dashboard and leaving you to interpret it, specialists implement the fixes directly, working from the same RFC-based enforcement model described above but applied to actual sending infrastructure.
The relevant services for this stage of the process include:
- A free health check to establish where your domain currently sits and what is authenticated versus what is not.
- Authentication setup to correct SPF and DKIM alignment issues before enforcement begins.
- Ongoing monitoring through the DMARC Checker, Monitoring and Setup service, so pct increases are backed by real reporting rather than a fixed calendar date.
- A Deliverability Review and Fix engagement for domains that need broader remediation alongside the DMARC rollout.
If you would rather talk through your specific setup before committing to a full engagement, an advisory session is available at £250 one-off and gives you direct access to a senior specialist for that conversation. For a wider look at the services and plans on offer, visit the deliverability services page to see what fits your situation.
Where these definitions and standards come from
The technical claims in this article draw on RFC 7489, the DMARCbis draft, and RFC 9990 on reporting visibility. Community statistics and practical guidance are also available through dmarc.org.
Sources
FAQ
Should you use quarantine or reject to enable BIMI?
BIMI generally requires a DMARC policy of either quarantine or reject at enforcement, rather than the monitoring-only p=none. Which of the two you choose depends on your own risk tolerance and reporting maturity, though many domains reach reject eventually as their long-term target.
What causes an email to go into quarantine?
An email is quarantined when it fails DMARC authentication under a domain publishing p=quarantine, meaning it failed SPF or DKIM alignment checks and the receiver chose to act on that by placing it into spam or applying extra scrutiny, as described in RFC 7489. Common causes include unsigned messages, unauthorised third-party senders and DKIM signatures broken by forwarding or list rewrites.
How do you fix a DMARC quarantine or reject policy that is not enabled?
If your DNS record shows p=none or is missing entirely, you first need to publish a DMARC TXT record with RUA reporting enabled and confirm SPF and DKIM are correctly aligned for every legitimate sender. From there, progress the policy from none to quarantine to reject gradually using the pct tag, checking aggregate reports at each stage before increasing enforcement further.
What does it mean when an email is rejected due to DMARC?
A DMARC rejection means the receiving mail server refused the message during the SMTP transaction because it failed authentication under a domain publishing p=reject, and RFC 7489 confirms this normally happens before the message ever reaches a mailbox or spam folder. The sending server typically receives a bounce message indicating the rejection.
