DMARC Policy: When to Use None, Quarantine, or Reject

A DMARC policy tells mailbox providers what you want them to do when mail using your domain fails DMARC authentication. Start with monitoring, fix every legitimate sender, then move toward enforcement in stages.

What a DMARC policy does

A DMARC policy is the enforcement instruction in your domain’s DMARC record.

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It builds on SPF and DKIM. It checks whether a message is authenticated and whether that authentication aligns with the visible From domain.

The visible From domain matters because that is what the recipient sees.

If someone sends mail that claims to be from billing@example.com, DMARC asks two questions:

1. Did SPF or DKIM pass?
2. Did the passing authentication align with example.com?

If neither SPF nor DKIM passes in alignment, the message fails DMARC.

Define the p= tag in a DMARC record

The p= tag is the main DMARC policy tag. It tells receiving mailbox providers what policy you request for mail that fails DMARC.

A basic DMARC record looks like this:

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

The three main policy values are:

Policy	Meaning	Typical use
p=none	Monitor only	Collect reports before enforcement
p=quarantine	Treat failed mail as suspicious	Partial enforcement, often spam placement
p=reject	Reject failed mail	Strongest protection against spoofing

You may also see other DMARC policy tags:

Tag	What it does
pct=	Applies the policy to a percentage of failing mail
sp=	Sets a policy for subdomains
adkim=	Sets DKIM alignment mode, relaxed or strict
aspf=	Sets SPF alignment mode, relaxed or strict
rua=	Sends aggregate reports
ruf=	Requests forensic reports, though support is limited

For most dmarc rollout work, you will spend the most time on p=, pct=, rua=, SPF alignment, and DKIM alignment.

What receiving mailbox providers do with failed mail

When a message fails DMARC, the receiver evaluates your published policy.

• With p=none, the receiver accepts the message as usual and includes the result in reports when reporting is supported.
• With p=quarantine, the receiver usually sends the message to spam, junk, or another lower-trust path.
• With p=reject, the receiver may reject the message during SMTP or otherwise prevent delivery.

“May” matters here. DMARC is a sender-published request. Receivers use it as a strong signal, but they still run their own filtering systems.

Mailbox providers still make their own decisions

DMARC does not replace spam filtering.

A message can pass DMARC and still land in spam because of poor engagement, high complaint rates, suspicious content, bad sending patterns, or a damaged sender reputation.

A message can also fail DMARC and still get delivered if the receiver chooses not to enforce your requested policy. That is less common with major providers when a domain has a clear enforcement policy, but it can happen.

Think of DMARC as your domain’s email authentication policy. It tells receivers how to handle unauthenticated use of your domain. It does not guarantee inbox placement.

p=none: monitoring without enforcement

p=none means “do not enforce yet; send me reports so I can see who is using my domain.”

This is where most domains should start.

A monitoring record might look like this:

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

At this stage, your goal is not protection. Your goal is visibility.

When to start with p=none

Start with p=none when you are publishing DMARC for the first time or when you are unsure whether all mail streams authenticate correctly.

This is common for marketing and technical teams because most companies send mail from more places than they think.

You may have:

• Your primary email platform
• A marketing automation platform
• A CRM or sales engagement tool
• Product transactional email
• Billing and invoice systems
• Support desk notifications
• Survey tools
• Event platforms
• Recruiting systems
• Internal tools
• Legacy servers nobody has touched in years

If you move straight to enforcement, one missed sender can break real mail.

What data to collect before changing policy

Before you move beyond monitoring, collect enough DMARC aggregate report data to answer these questions:

• Which IPs and platforms send mail using your domain?
• Which sources pass SPF?
• Which sources pass DKIM?
• Which sources align with the visible From domain?
• Which failures are legitimate senders that need fixes?
• Which failures are spoofing, forwarding, or unauthorized systems?
• Do any subdomains send mail separately?
• Are marketing, transactional, and corporate mail all covered?

DMARC aggregate reports are XML files. Most teams use a reporting tool to parse them because raw reports are hard to read at scale.

You are looking for patterns, not one-off noise.

A legitimate sender needs at least one aligned pass:

• SPF passes and the SPF-authenticated domain aligns with the From domain, or
• DKIM passes and the DKIM signing domain aligns with the From domain.

DKIM is usually the safer long-term path because it survives forwarding better than SPF.

Risks of staying at p=none forever

p=none gives you visibility, not enforcement.

If you stay there forever, attackers can keep spoofing your domain and receivers will not have a strong instruction to block that unauthenticated mail.

That creates risk for:

• Phishing attacks using your brand
• Fake invoices or password reset messages
• Vendor fraud
• Customer trust
• Domain reputation
• Compliance expectations from partners or mailbox providers

p=none is a phase. It is not the finish line.

p=quarantine: partial enforcement

p=quarantine tells receivers to treat DMARC-failing mail as suspicious.

In practice, quarantine usually means spam or junk folder placement. Some receivers may apply extra filtering instead of a literal quarantine folder. The exact behavior varies.

A quarantine record can look like this:

_dmarc.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

What quarantine usually means in practice

With p=quarantine, you are telling mailbox providers:

If mail claims to be from my domain but fails DMARC, do not treat it like normal mail.

That is a meaningful step up from p=none.

It reduces the chance that spoofed mail lands in the inbox. It also gives you a safer enforcement stage before p=reject.

But it can still affect legitimate mail if you missed a sender.

For example, a support platform may send from support@example.com but sign DKIM with its own domain. If SPF also does not align, that mail fails DMARC. Under quarantine, those support messages may start landing in spam.

When quarantine is appropriate

Move to p=quarantine when your reports show that most legitimate mail passes DMARC alignment and the remaining failures are understood.

You do not need absolute perfection before quarantine. But you do need confidence.

Before switching, verify:

• Your main corporate mail passes DMARC.
• Your marketing platform passes DMARC.
• Your transactional provider passes DMARC.
• Your CRM and sales tools pass DMARC.
• High-value operational mail passes DMARC.
• Known failures are either fixed, deprecated, or accepted risks.
• Someone owns monitoring after the change.

Quarantine is appropriate when you want protection but still want a buffer. Users can often find quarantined mail in spam. Rejected mail usually never reaches them.

How pct= can phase enforcement gradually

The pct= tag lets you apply your policy to only a percentage of messages that fail DMARC.

Example:

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

This asks receivers to apply quarantine to 25% of DMARC-failing mail.

A gradual path might look like this:

Stage	Example policy	What you do
Monitor	p=none	Inventory senders and fix authentication
Light quarantine	p=quarantine; pct=10	Watch for legitimate failures
Broader quarantine	p=quarantine; pct=50	Confirm fixes hold under normal volume
Full quarantine	p=quarantine; pct=100	Prepare for reject

Not every receiver applies pct= in the same way. Still, it is useful for reducing blast radius during rollout.

p=reject: strongest protection

p=reject tells receivers to block mail that fails DMARC.

This is the strongest DMARC enforcement setting.

A reject record looks like this:

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

When a domain is ready for reject

A domain is ready for p=reject when legitimate mail consistently passes DMARC and failures are either unauthorized or acceptable to block.

You should have:

• Several reporting cycles with stable results
• Clear ownership of all sending platforms
• DKIM configured for third-party senders where available
• SPF records that include only active senders
• No important mail streams failing alignment
• A plan for subdomains
• A rollback path if a critical sender breaks

Do not use p=reject as a shortcut to clean up messy authentication. It will clean up the mess by blocking mail. That may include mail you wanted delivered.

Benefits for spoofing protection and brand trust

Reject gives receivers the clearest instruction.

If a phisher sends mail using your exact domain and fails DMARC, p=reject tells the receiver not to accept it. That protects recipients and reduces the value of your domain to attackers.

Benefits include:

• Stronger protection against direct domain spoofing
• Better control over who can send as your domain
• Cleaner authentication posture
• More confidence for partners and security teams
• Less brand exposure in phishing campaigns

For domains used in banking, healthcare, SaaS login flows, invoicing, or customer support, p=reject is often the right end state.

Risks if legitimate senders are not fully authenticated

Reject has sharp edges.

If a legitimate sender fails DMARC, the receiver may block the message before it reaches the mailbox. The recipient may not see it in spam. Your support team may only hear, “I never got the email.”

Common causes include:

• A third-party platform sending without custom DKIM
• SPF passing for the wrong domain
• DKIM signing with the vendor’s domain instead of yours
• A From domain that does not match the authenticated domain
• Too many DNS lookups in SPF
• Old systems sending directly from your domain
• Subdomains without a clear policy

Reject is worth it. But only after the authentication work is done.

A safe DMARC policy rollout plan

A safe DMARC rollout moves from visibility to enforcement without surprising your legitimate senders.

Use this as a practical sequence.

1. Inventory mail streams before enforcement

Start by listing every system that sends mail using your domain or subdomains.

Include both human and automated mail:

• Employee mail
• Newsletters
• Lifecycle campaigns
• Password resets
• Product notifications
• Receipts and invoices
• Sales outreach
• Support replies
• Alerts and monitoring
• HR and recruiting
• Partner or agency tools

Ask each team what they send, which From domain they use, and which platform sends it.

Then compare that inventory against DMARC reports. The reports will usually reveal senders you missed.

2. Fix SPF, DKIM, and alignment issues

DMARC depends on SPF and DKIM, but passing SPF or DKIM alone is not always enough. The passing domain must align with the visible From domain.

Use this checklist:

• Publish SPF for systems that send through your domain.
• Keep SPF lean. Remove retired vendors.
• Avoid exceeding SPF DNS lookup limits.
• Enable custom DKIM for third-party platforms.
• Use your domain, or an aligned subdomain, in DKIM signing.
• Prefer DKIM for platforms that support it well.
• Make sure the visible From domain matches your authentication plan.
• Check subdomains separately.

Alignment can be relaxed or strict.

With relaxed alignment, mail.example.com can align with example.com. With strict alignment, the domains must match exactly. Most domains use relaxed alignment unless they have a specific security reason to tighten it.

3. Move from none to quarantine to reject in stages

Do not jump from no DMARC to p=reject.

A practical path:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Then:

v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@example.com

Then:

v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc-reports@example.com

Then:

v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@example.com

Finally:

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

You can move faster if your domain is simple. You should move slower if you have many platforms, multiple business units, regional senders, or legacy infrastructure.

4. Monitor failures after each change

After each policy change, monitor both reports and business symptoms.

Watch for:

• New DMARC failures from known vendors
• Drops in expected campaign volume
• Transactional mail complaints
• Support tickets about missing mail
• Changes in bounce patterns
• Authentication failures by subdomain
• Forwarding-related failures

Forwarding can complicate SPF because the forwarding server is not usually authorized in your SPF record. DKIM often survives forwarding if the message is not modified. This is one reason DKIM alignment matters so much.

Where DMARC policy fits in deliverability

DMARC supports deliverability by proving domain control and reducing spoofing, but it does not guarantee inbox placement.

Mailbox providers evaluate many signals. Authentication is foundational. It tells receivers that a message is allowed to use your domain. After that, they still judge whether recipients want the mail.

DMARC builds trust, not automatic inbox placement

A strong DMARC policy helps receivers trust that your domain is not easy to spoof. That matters.

But a fully authenticated message can still perform poorly if recipients ignore it, delete it, mark it as spam, or never asked for it.

Inbox placement also depends on:

• Recipient engagement
• Spam complaint rates
• Sending consistency
• List quality
• Bounce rates
• Content and link reputation
• Domain and IP reputation
• Permission and consent
• Unsubscribe handling

DMARC answers, “Is this mail authorized to use this domain?”

It does not answer, “Do recipients want this mail?”

Email verification complements DMARC

DMARC protects your domain from unauthenticated use. Email verification protects your sender reputation from invalid recipients.

They solve different deliverability problems.

Control	Main job	What it prevents
SPF	Authorizes sending servers	Some forged envelope sender abuse
DKIM	Signs messages with a domain key	Message tampering and unauthenticated sending
DMARC	Enforces alignment with the visible From domain	Direct domain spoofing
Email verification	Checks recipient address quality before sending	Invalid-recipient bounces and risky addresses

If you run signup forms, outbound sales, lifecycle campaigns, or list imports, invalid addresses can hurt you even when DMARC is perfect.

Use verification before you send to catch addresses that are undeliverable, disposable, typoed, or risky. Bounceable can verify addresses in real time, flag disposable domains and role accounts, suggest typo fixes, and return a deliverability verdict before a bad address reaches your ESP.

A healthy deliverability program uses both sides:

• Authentication to prove you are who you say you are
• Verification to avoid sending to addresses that should not receive mail
• Permission practices to make sure recipients expect the mail
• Monitoring to catch problems early

DMARC enforcement is one of the best domain protection steps you can take. Roll it out carefully. Keep watching the data. Then support it with clean lists and sending practices that mailbox providers can trust.