TL;DR: A DMARC quarantine policy (p=quarantine) tells receiving servers to route mail that fails authentication to the spam folder instead of the inbox. It is the middle stage of the only safe DMARC migration: start at p=none to monitor, read your aggregate (rua) reports to find every legitimate sending source, move to p=quarantine using the pct= tag to ramp enforcement gradually, then finish at p=reject. Skip the stages and you will silently quarantine or bounce your own legitimate mail. This guide gives you the exact rollout schedule, how to read the reports, and how to use pct= to de-risk the whole thing.

#Table of Contents

• What a DMARC Quarantine Policy Does
• Why You Cannot Skip Straight to p=reject
• The Three-Stage Migration Overview
• Stage One: p=none and Reading rua Reports
• Stage Two: p=quarantine and the pct Tag
• Stage Three: p=reject and Full Enforcement
• A Concrete Rollout Schedule
• Avoiding Self-Inflicted Deliverability Loss
• DMARC Alignment: The Detail That Catches Setups
• Quarantine vs Reject for Cold Email Specifically
• FAQs
• Conclusion

#What a DMARC Quarantine Policy Does

DMARC is the policy layer that sits on top of SPF and DKIM. SPF and DKIM tell a receiving server whether a message authenticated. DMARC tells the server what to do about it when authentication fails - and it adds reporting so you can see who is sending mail that claims to be from your domain. The policy is set with the p= tag, which takes one of three values: none, quarantine, or reject.

A DMARC quarantine policy is p=quarantine. It instructs the receiving server that when a message claiming to be from your domain fails DMARC - meaning neither SPF nor DKIM passes with proper alignment - the server should treat it as suspicious and route it to the spam or junk folder rather than deliver it to the inbox. The message still reaches the recipient's mailbox; it just lands in spam instead of the inbox.

This sits between the two extremes. p=none means take no action at all, just monitor and report. p=reject means refuse the message entirely with a hard bounce. Quarantine is the intermediate enforcement level: real consequences for failing mail, but recoverable, because a quarantined message is still in the recipient's spam folder where it could in principle be found, rather than gone forever.

It helps to be precise about what "fails DMARC" means, because the phrase hides the alignment subtlety that trips up most setups. A message fails DMARC when neither SPF nor DKIM both passes and aligns with the visible From domain. That word "aligns" is doing heavy lifting; a message can have a passing SPF check and a passing DKIM check and still fail DMARC if neither passing mechanism is tied to the domain the recipient actually sees in the From line. Hold that thought - there is a full section on alignment later - because it is the difference between a migration that goes smoothly and one where legitimate sources keep mysteriously showing up in your failure reports. For now, just register that "fails authentication" in the DMARC sense is stricter than "fails SPF or DKIM" in the plain sense.

For your own outbound, the goal of moving toward enforcement is to protect your domain from being spoofed by phishers and to signal to mailbox providers that you run a tight, authenticated sending operation - which is itself a positive email deliverability signal. But the path to enforcement is exactly where teams hurt themselves, because turning on enforcement before you have accounted for every legitimate sending source means your enforcement policy starts quarantining or rejecting your own mail.

#Why You Cannot Skip Straight to p=reject

The single most expensive DMARC mistake is reading that p=reject is the "correct, strongest" setting and publishing it immediately. The logic feels right - strongest protection, best practice, done. The problem is that p=reject enforces against every sending source that is not properly authenticated and aligned, including the ones you forgot you had.

Almost every organization sends mail from more sources than it realizes. Your primary mail provider, sure. But also: your CRM sending on your behalf, your invoicing or billing platform, a marketing automation tool, a help-desk system, an e-signature service, a calendar scheduler, an analytics or survey tool, and whatever a colleague signed up for last quarter that sends from your domain. Each of these is a sending source, and each needs SPF and DKIM configured and aligned to your domain for DMARC to pass.

When you jump to p=reject before auditing these, here is what happens. Every source you forgot to authenticate starts failing DMARC. Under reject, that failing mail is hard-bounced. Your invoices stop arriving. Your password-reset emails vanish. Your scheduling links never land. And because the failures are happening at the receiver, you often do not notice for days - you just start hearing "I never got your email" from customers, with no obvious cause. By then you have done real damage, and worse, the pattern of suddenly-failing mail from your domain can itself ding your domain reputation.

The staged migration exists precisely to surface every sending source before you enforce against it. You move to enforcement only after the reports have shown you the complete picture and you have fixed every legitimate source. There is no shortcut that is also safe. The teams that move fast and stay safe are the ones who let p=none do its monitoring job first.

#The Three-Stage Migration Overview

The migration has three stages, and they map directly to the three p= values. You move through them in order, and you only advance when the reports tell you it is safe.

Stage one - monitor. Publish p=none. This changes nothing about delivery; failing mail still gets delivered. What it does is turn on aggregate reporting so mailbox providers start sending you daily digests of every source sending under your domain, with pass and fail counts. You stay here until you have identified and authenticated every legitimate source.

Stage two - quarantine with a ramp. Move to p=quarantine, but use the pct= tag to apply the policy to only a fraction of failing mail at first. Start small, watch the reports, and increase the fraction as you confirm nothing legitimate is being caught. This is the careful enforcement stage.

Stage three - reject. Once quarantine at 100 percent has run cleanly with no legitimate mail being caught, move to p=reject for full enforcement. Failing mail is now hard-bounced, your domain is protected from spoofing, and you have the strongest deliverability and security posture.

The whole discipline is in the transitions. You never advance a stage on a hunch. You advance when the aggregate reports show that the mail failing DMARC is all illegitimate (spoofing, forwarding artifacts you have decided to accept) and none of it is your own legitimate sources. The reports are the instrument. The pct= tag is the safety valve. Together they let you reach full enforcement without ever risking a big chunk of your real mail.

#Stage One: p=none and Reading rua Reports

Stage one is monitoring, and the entire value of it is in the reports. This is the record you publish:

_dmarc.yourdomain.com  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"

The rua= tag is the aggregate report address. Once this is live, participating mailbox providers (Google, Microsoft, Yahoo, and others) send you a daily XML report summarizing all the mail they received claiming to be from your domain: which sources sent it, what IPs, and whether SPF and DKIM passed and aligned. These aggregate reports are the map of your entire sending footprint.

Raw DMARC aggregate XML is not human-friendly. You will want a report reader - a DMARC monitoring service that ingests the XML and shows you a readable dashboard of sources and pass/fail rates. Pointing rua= at a monitoring tool's address (or forwarding to one) is standard practice. The output you care about is a list of every sending source under your domain, each labeled passing or failing.

What you are looking for in the reports:

• Every legitimate source, identified. Your mail provider, CRM, billing, marketing, support, and any other tool. Each should appear. Your job is to recognize each source and confirm it is yours.
• Failing legitimate sources. A legitimate source that shows DKIM or SPF failing is a source you need to fix - configure its DKIM with your domain key and align it - before you enforce.
• Illegitimate sources. IPs and sources you do not recognize that are sending under your domain. Some of this is spoofing or spam using your domain. This is exactly what DMARC enforcement will eventually block.

You stay in stage one until two things are true: you can account for every legitimate source, and every legitimate source passes DMARC with alignment. This usually takes a few weeks for a typical organization, longer for a complex one with many tools. Do not rush it. The reports are showing you the landmines before you step on them. The whole reason a careful SPF, DKIM, and DMARC setup pays off is that this monitoring stage turns enforcement from a gamble into a known quantity.

#Stage Two: p=quarantine and the pct Tag

Once stage one confirms your legitimate sources are clean, you move to quarantine. But you do not move to full quarantine immediately. You use the pct= tag to ramp.

The pct= tag tells receiving servers what percentage of failing mail to apply the policy to. The rest is treated as the next-lower policy. So p=quarantine; pct=25 means: quarantine 25 percent of failing messages, and apply p=none (deliver normally) to the other 75 percent. This is your safety valve. If you missed a legitimate source, only a quarter of its mail gets quarantined at first, and the reports will show you the spike before it becomes a full outage.

A typical quarantine record with a partial ramp:

"v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@yourdomain.com"

The ramp schedule looks like this. You start at pct=25, watch the aggregate reports for a week or so, and confirm no legitimate mail is being quarantined. If clean, you raise to pct=50, watch again, then pct=75, then pct=100. At pct=100 (or simply p=quarantine with no pct, which defaults to 100), every failing message is quarantined. Each step gives the reports time to reveal any source you missed before the impact is large.

The discipline is the same as stage one: advance only when the reports are clean. If raising pct reveals a legitimate source suddenly showing in the quarantine counts, drop back, fix that source's authentication, and resume the ramp. The pct= tag turns a potential cliff into a set of small, reversible steps. It is the most underused safety mechanism in DMARC, and skipping it is how careful-seeming teams still lose mail.

#Stage Three: p=reject and Full Enforcement

Reject is the destination, not the starting point. You reach it only after p=quarantine; pct=100 has run for a sustained period with clean reports.

"v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com"

Under p=reject, any message that fails DMARC is rejected outright - a hard bounce, no delivery, no spam-folder fallback. This is the strongest protection against domain spoofing and phishing, because it means no one can successfully send mail that claims to be from your domain unless it actually authenticates as you. For your brand's reputation and for the trust mailbox providers extend to your authenticated mail, reaching reject on your primary domain is the right end state.

The reason you can move to reject safely at this point is that quarantine at 100 percent already exercised full enforcement - every failing message was being acted on. The only behavioral difference between p=quarantine; pct=100 and p=reject is the consequence: spam folder versus hard bounce. If quarantine at full coverage caught no legitimate mail, then reject will not either, because the same messages fail the same checks. You have already proven the policy is safe; reject just makes the consequence harsher for the failing mail you have confirmed is illegitimate.

You can also apply the policy to subdomains explicitly with sp=. A record like p=reject; sp=reject enforces reject on the root domain and all subdomains. For cold-email operations that run on dedicated sending domains, you typically want your primary brand domain at reject for maximum protection, while newer dedicated sending domains may sit at quarantine until they have proven clean - the same staged caution applied per domain.

Keep rua= reporting on permanently. Even at reject, the aggregate reports remain valuable. They show you ongoing spoofing attempts being blocked, and they catch the day someone in your organization signs up for a new tool that sends from your domain without authentication. Enforcement without continued monitoring is how a clean setup quietly drifts back into broken over a year.

#A Concrete Rollout Schedule

Here is a defensible schedule. Adjust the durations to your organization's complexity - a simple setup moves faster, a sprawling one with many tools moves slower - but keep the order and the gates.

Weeks 1 to 4: p=none. Publish p=none with rua= pointed at a monitoring tool. Spend these weeks reading reports, cataloging every sending source, and fixing the authentication of any legitimate source that shows failures. Gate to advance: every legitimate source identified and passing with alignment.

Weeks 5 to 6: p=quarantine; pct=25. Begin enforcement on a quarter of failing mail. Watch reports closely for any legitimate source appearing in quarantine counts. Gate: clean reports, no legitimate mail caught.

Week 7: p=quarantine; pct=50. Raise the ramp. Confirm stability. Gate: still clean.

Week 8: p=quarantine; pct=75. Near-full enforcement. Gate: still clean.

Weeks 9 to 10: p=quarantine; pct=100. Full quarantine. Let it run a sustained period to be sure. Gate: a clean stretch with no legitimate mail quarantined.

Week 11 onward: p=reject. Move to full enforcement on your primary domain. Keep rua= reporting on indefinitely.

This is roughly a two-and-a-half month rollout for a typical organization, and that pace is a feature, not a delay. Each gate is a real decision point where the reports either green-light the next step or send you back to fix a source. Teams that compress this timeline are usually the ones who later discover a forgotten source bouncing in production. The cost of the extra weeks is far smaller than the cost of silently losing customer mail. If you are also standing up dedicated sending domains during this period, fold their warmup and the broader cold email deliverability checklist into the same timeline so authentication and reputation come up together.

#Avoiding Self-Inflicted Deliverability Loss

Most DMARC pain is self-inflicted. Here are the specific ways teams hurt themselves and how to avoid each.

Enforcing before the audit is complete. Covered throughout - this is the root mistake. Do not advance a stage on optimism. Advance on clean reports. The reports are not bureaucracy; they are the only thing standing between you and quarantining your own invoices.

Ignoring DMARC alignment, not just pass/fail. A message can have SPF or DKIM technically pass and still fail DMARC because the passing mechanism does not align with the From: domain. This is subtle and catches many setups. When you read reports, confirm that legitimate sources pass with alignment, not just that some check somewhere passed. A source that passes DKIM with the ESP's domain instead of yours will fail DMARC and get caught by enforcement.

Forgetting forwarded mail. Legitimately-forwarded mail can fail SPF and DKIM at the final hop through no fault of yours, and strict enforcement can catch it. This is exactly the gap that ARC email authentication is designed to cover. As you move to enforcement, be aware that some of the "failing" mail in your reports is legitimate mail broken by forwarding, and that reputable infrastructure and ARC-aware intermediaries are what keep it deliverable. Do not panic at forwarding-induced failures, but do understand them.

Setting it and never looking again. A DMARC policy at reject with no ongoing monitoring drifts. New tools get added, sources change, and a year later something legitimate is silently failing. Keep rua= reporting live and check it periodically forever.

Treating DMARC as the whole job. DMARC enforcement is a deliverability and security signal, but it is not a substitute for the rest of the work - clean lists, warmed domains, genuinely personalized copy that does not draw complaints. DMARC gets your authenticated mail trusted; it does not make bad mail good.

Done with this discipline, the migration is undramatic. You spend a couple of months reading reports and fixing sources, you ramp enforcement in safe steps, and you arrive at full protection without a single customer noticing anything except that your domain is now harder to spoof. That quiet, uneventful rollout is exactly what success looks like.

#DMARC Alignment: The Detail That Catches Setups

The single most common reason a legitimate source shows up failing in your DMARC reports is not a missing SPF or DKIM record. It is alignment. Alignment is subtle, it is where most setups break, and if you do not understand it, your reports will look confusing and your migration will stall.

DMARC does not pass just because SPF passes or DKIM passes. It passes when SPF or DKIM passes and the passing mechanism aligns with the domain in the visible From: header. Alignment means the domain that authenticated matches the domain the recipient sees. A message can have SPF technically pass and DKIM technically pass and still fail DMARC because neither one aligned with the From domain.

SPF alignment. SPF authenticates the envelope sender (the Return-Path), which is often different from the visible From address. If your mail provider uses its own domain for the Return-Path - say bounces@esp-domain.com while your From is you@brand.com - then SPF passes for esp-domain.com, which does not align with brand.com. SPF passed, but SPF alignment failed, so this mechanism does not satisfy DMARC.

DKIM alignment. DKIM signs with a domain specified in the signature's d= tag. If your ESP signs with d=esp-domain.com instead of d=brand.com, DKIM passes - the signature is valid - but it signed for the ESP's domain, not yours. So DKIM passed, DKIM alignment failed, and again this mechanism does not satisfy DMARC.

When both SPF and DKIM pass but neither aligns, DMARC fails despite everything technically "passing." This is exactly the scenario that catches teams who assume their ESP "handles authentication." The ESP handles SPF and DKIM, sure, but signs and bounces with its own domain by default, so nothing aligns to your From domain and DMARC fails. Under enforcement, that legitimate mail gets quarantined or rejected.

The fix is to configure your ESP to use your domain for the bits that matter: a custom Return-Path that resolves to your domain or a subdomain (for SPF alignment) and DKIM signing with your domain's key via a d=brand.com signature (for DKIM alignment). Most quality providers support both through a "custom sending domain" or "authenticated domain" setup. After configuring, do a test send and confirm in the headers that you see SPF or DKIM passing with alignment to your From domain, not just passing in the abstract.

The two alignment modes, relaxed and strict, are set with aspf= and adkim=. Relaxed (r, the default) allows alignment between a domain and its subdomains - mail.brand.com aligns with brand.com. Strict (s) requires an exact match. For most cold-email setups, relaxed alignment is the safe and correct choice; strict is for organizations with specific reasons to demand exact-domain matching. Start relaxed unless you have a concrete reason not to.

When you read your aggregate reports during the migration, do not just look at the SPF and DKIM pass columns. Look at whether the passing mechanism aligned. A source showing "DKIM pass" that still fails DMARC is almost always an alignment problem, and now you know exactly what to fix. Catching alignment issues at the p=none stage is the whole reason the monitoring stage exists.

#Quarantine vs Reject for Cold Email Specifically

The general DMARC migration applies to any domain, but cold-email sending domains have a few specifics worth calling out, because the goals are slightly different from your corporate mail.

For your primary brand domain - the one carrying customer mail, invoices, and your reputation - the goal is unambiguous: reach p=reject. This domain must be maximally protected from spoofing, because a spoofed brand domain is a phishing risk to your customers and a serious reputation threat. Run the full staged migration and finish at reject. There is no good reason to leave your primary brand domain short of reject once the reports are clean.

For your dedicated cold-email sending domains, the calculus is a little different. These domains exist to carry outreach and to be isolated from your brand. They still benefit from authentication enforcement - a properly authenticated sending domain is a positive deliverability signal and signals a legitimate operation to mailbox providers. But because these domains are dedicated to a controlled sending process where you know every source (it is just your outreach tooling), the audit is simpler and the spoofing-protection urgency is lower. A reasonable posture is to reach p=quarantine reliably and move to p=reject once the domain has proven clean, treating reject as the eventual destination rather than an immediate must-have on day one of the domain's life.

The reason to still pursue enforcement on cold-email domains is that it is part of looking like a legitimate sender rather than a throwaway. Mailbox providers in 2026 increasingly expect proper authentication as table stakes, and a cold-email domain stuck at p=none forever signals a sender who set up the minimum and stopped. Pairing solid DMARC enforcement with proper warmup and a clean cold email deliverability checklist is what separates a sending domain that lasts from one that gets burned in weeks.

One practical note for cold-email domains: because they are newer and you are warming them, sequence the DMARC migration alongside the warmup rather than rushing enforcement before the domain has any sending history. A brand-new domain has no real mail flowing yet, so its reports are sparse. Let the domain warm and accumulate genuine sending while you watch the reports, then move through quarantine to reject as the domain matures. Enforcement and reputation grow together.

Finally, remember that DMARC enforcement on a cold-email domain protects that domain's identity but does nothing about the content quality that actually drives complaints. A cold-email domain at p=reject with poorly-targeted, complaint-drawing copy will still get its reputation destroyed by complaints, because complaints are about content, not authentication. DMARC keeps impostors from spoofing your sending domain; it does not make your own mail welcome. Both layers matter, and they solve different problems.

#FAQs

#What does p=quarantine do in DMARC?

p=quarantine tells receiving mail servers to route messages that fail DMARC authentication to the recipient's spam or junk folder instead of the inbox. The mail still reaches the mailbox, just not the inbox. It is the intermediate enforcement level between p=none (no action) and p=reject (hard bounce), giving you real enforcement with a recoverable failure mode.

#How long should I stay at p=none before moving to quarantine?

Long enough to identify and authenticate every legitimate sending source - typically a few weeks for a simple setup and longer for an organization with many tools. The gate is not a fixed duration; it is a condition: every legitimate source appears in your aggregate reports and passes DMARC with alignment. Do not advance until that is true.

#What is the pct tag in a DMARC record?

The pct= tag sets the percentage of failing mail that the policy applies to. p=quarantine; pct=25 quarantines 25 percent of failing messages and delivers the rest normally. It is a safety valve that lets you ramp enforcement gradually - start at 25, watch your reports, and raise to 50, 75, and 100 as you confirm no legitimate mail is being caught.

#Can I go straight from p=none to p=reject?

You can, but you should not. Jumping to reject before auditing every sending source means any source you forgot to authenticate starts hard-bouncing immediately - invoices, password resets, scheduling links. The damage often goes unnoticed for days. Always pass through quarantine with a pct= ramp so the reports surface missed sources before they cause an outage.

#How do I read DMARC rua aggregate reports?

Aggregate reports arrive as XML, which is hard to read raw, so use a DMARC monitoring tool that ingests the XML and shows a dashboard of sending sources with pass and fail counts. Point your rua= address at the tool. You are looking for every legitimate source passing with alignment, any legitimate source failing (fix it), and unrecognized sources (spoofing that enforcement will block).

#Should cold-email sending domains use p=reject?

Your primary brand domain should reach p=reject for maximum spoofing protection. Dedicated cold-email sending domains can sit at p=quarantine until they have proven clean through the same staged process, then move to reject. The caution is per domain: do not enforce reject on any domain before its reports confirm every legitimate source authenticates correctly.

#Conclusion

A DMARC quarantine policy is the middle stage of the only safe path to email authentication enforcement. You start at p=none to monitor, read your aggregate reports until you can account for every legitimate sending source, ramp through p=quarantine using the pct= tag to enforce gradually, and finish at p=reject for full protection. The reports are your instrument and the pct= tag is your safety valve. Skip the stages and you will quarantine or bounce your own mail; respect them and the whole migration is quiet and uneventful.

The discipline that protects you here - never advancing without evidence, fixing every source before enforcing - is the same discipline that protects deliverability everywhere in cold outreach. Authentication gets your mail trusted. What you send still has to earn the reply.

That is the part FirstSales is built to keep clean: the AI drafts a personalized cold email for each prospect, you review and approve every draft, then it sends - so the authenticated mail leaving your domain earns positive signals instead of complaints that undo all your DMARC work. Start for $1 and pair a clean authentication posture with mail worth delivering.