DMARC p=none vs quarantine vs reject: What Agencies Should Recommend

DMARC policy none quarantine reject decisions should be based on evidence, not a slogan. p=none is useful for monitoring and discovery. p=quarantine is an intermediate enforcement policy. p=reject can be appropriate when legitimate senders are understood and SPF or DKIM alignment is working, but agencies should not jump straight to reject on a client domain without checking who sends mail.

DMARC is powerful because it connects authentication results to the visible From domain. It can help reduce unauthorized use of a domain, but it can also disrupt legitimate mail if the agency does not understand the client's senders.

Use Inbox Pulse for a configuration-risk snapshot across client domains. Use the broader 10-domain agency audit when you also need SSL, DNS, and domain expiry context. For how CertPilot checks public DNS and email-authentication records safely, see how CertPilot checks domains.

What DMARC does

Domain-based Message Authentication, Reporting, and Conformance, or DMARC, sits on top of SPF and DKIM. It lets a domain owner publish a policy at _dmarc.example.com.

DMARC asks:

1. Did SPF or DKIM pass?
2. Did the passing result align with the visible From domain?
3. What policy does the domain owner request if alignment fails?
4. Where should aggregate reports be sent, if configured?

The alignment part is critical. A message can pass SPF for one technical return-path domain while the visible From domain is different. A message can pass DKIM for a platform domain while the client domain is not aligned. DMARC cares about the domain the recipient sees.

For the broader operating-team model, read DMARC, SPF, and DKIM explained for agencies.

What Does DMARC p=none Mean?

DMARC p=none tells receiving mail systems to take no DMARC enforcement action based on the domain's DMARC policy. It is commonly used as monitoring mode while a team identifies legitimate senders, checks SPF and DKIM alignment, and decides whether stronger policy is appropriate.

p=none does not mean DMARC is broken. A domain can publish a valid DMARC record with p=none, receive aggregate reports, and use those reports to understand who is sending mail. The limitation is that p=none does not ask receivers to quarantine or reject messages that fail DMARC.

Agencies should not jump directly from "DMARC exists" to p=reject. First confirm legitimate senders, fix SPF or DKIM alignment, and make sure someone owns the reporting and support process.

The three common DMARC policy states

| Policy | Plain-English meaning | Best used for | Agency caution | |---|---|---|---| | p=none | Monitor only; receivers are not asked to quarantine or reject based on DMARC failure | Discovery, sender inventory, rollout planning | Does not request enforcement | | p=quarantine | Ask receivers to treat failing mail suspiciously, often spam/junk placement | Intermediate enforcement after sender review | Can affect real mail if senders are not aligned | | p=reject | Ask receivers to reject failing mail | Mature domains with aligned legitimate senders | Not a safe first step for unknown sender setups |

These policies are requests to receivers, not guarantees that every receiver will behave identically.

What p=none means

p=none means the domain owner is not asking receivers to block or quarantine messages solely because they fail DMARC. It is commonly used for monitoring.

Example:

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

For agencies, p=none is useful when:

• The client does not know every platform that sends mail.
• A domain has never had DMARC before.
• A migration is underway.
• You need to identify legitimate senders before enforcement.
• You are setting up reporting and review.

The limitation is obvious: p=none does not enforce. It can improve visibility, but it does not ask receivers to quarantine or reject failing mail.

What p=quarantine means

p=quarantine asks receivers to treat DMARC-failing mail as suspicious. Many receivers may place it in spam or junk, though behavior varies.

Example:

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com

Agencies can recommend quarantine when:

• Key senders have been identified.
• SPF or DKIM alignment is working for normal business mail.
• Marketing and transactional platforms have been reviewed.
• The client understands that some failing mail may be treated more aggressively.
• There is a monitoring path for reports or support issues.

Quarantine is often a practical intermediate step. It creates enforcement pressure without immediately requesting hard rejection.

What p=reject means

p=reject asks receivers to reject messages that fail DMARC.

Example:

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

Reject can be appropriate for mature domains with clean sender inventory and working alignment. It is not automatically the right first step. If a client has unknown senders, old SaaS platforms, forwarding workflows, or incomplete DKIM, moving directly to reject can disrupt legitimate messages.

The agency recommendation should be based on evidence:

• Which platforms send mail?
• Which senders align with the visible From domain?
• Are DKIM signatures present for major senders?
• Does SPF align where DKIM does not?
• Are aggregate reports reviewed?
• Are support teams prepared for failures?

Why alignment matters

DMARC alignment means the authenticated domain matches, or closely matches depending on strict/relaxed mode, the visible From domain. This is why a message can "pass SPF" in a technical sense but still fail DMARC.

Example:

| Scenario | SPF | DKIM | DMARC | |---|---|---|---| | Google Workspace sends as client domain with aligned DKIM | Pass | Pass aligned | Pass | | CRM sends using its own return-path and no aligned DKIM | Pass for CRM domain | Missing | Fail | | Newsletter sender has DKIM for client domain | SPF may vary | Pass aligned | Pass |

Before recommending enforcement, agencies should find the legitimate senders that do not align and fix them where possible.

How RUA reporting fits

DMARC aggregate reports, often configured with rua=, can show which sources are sending mail and how they authenticate. They are valuable for monitoring and enforcement planning.

Inbox Pulse does not aggregate DMARC RUA XML reports or replace platforms such as EasyDMARC, Dmarcian, OnDMARC, Google Postmaster Tools, Microsoft SNDS, or enterprise deliverability suites. Treat Inbox Pulse as a configuration audit layer. If the client needs ongoing aggregate report analysis, they still need a DMARC monitoring platform or an internal reporting process.

For bulk configuration checks, see bulk DMARC checks for client domains.

Agency decision framework

Use this framework:

| Situation | Suggested policy posture | |---|---| | No sender inventory | Start with p=none | | Known business email, unknown marketing tools | p=none while inventory is completed | | Major senders aligned, minor unknowns remain | Consider p=quarantine carefully | | All important senders aligned and reports reviewed | Consider p=reject | | Client cannot monitor failures | Avoid aggressive changes | | Active migration | Delay enforcement changes until stable |

This is not legal or compliance advice. It is an operations framework for reducing avoidable email disruption.

How to explain DMARC to non-technical clients

Use plain language:

• p=none: "We are watching who sends mail as your domain."
• p=quarantine: "We are asking inbox providers to treat suspicious mail more cautiously."
• p=reject: "We are asking inbox providers to block mail that fails your domain's authentication rules."

Then explain the risk: if legitimate senders are not configured correctly, stricter policy can affect real business messages. The client needs to confirm platforms, owners, and sending workflows before enforcement.

Practical checklist before moving beyond p=none

• Confirm Google Workspace or Microsoft 365 alignment.
• Confirm marketing platforms.
• Confirm CRM and sales tools.
• Confirm helpdesk and ticketing systems.
• Confirm ecommerce and transactional senders.
• Check SPF for multiple records and lookup-limit risk.
• Check DKIM selectors for major senders.
• Confirm RUA reporting destination and owner.
• Document who approves the policy change.

The Google bulk sender DMARC agency checklist is a useful companion when clients send higher-volume mail or use multiple platforms.

Safe DMARC policy progression

A practical agency rollout usually moves in stages:

1. Start with p=none to observe authentication results and sender patterns.
2. Identify legitimate senders across mailbox, CRM, marketing, ecommerce, support, and transactional platforms.
3. Fix SPF and DKIM alignment issues for the senders that matter.
4. Move to partial enforcement if appropriate, such as a careful quarantine rollout.
5. Move toward stricter policy only when the client understands the operational impact and support path.

This progression avoids the common mistake of treating p=reject as a universal best practice. A stricter policy can be valuable, but timing matters.

Example rollout path for an agency-managed client

A cautious rollout might look like this:

| Phase | Policy | Agency work | |---|---|---| | Discovery | p=none | Inventory senders, check SPF/DKIM, set RUA destination | | Cleanup | p=none | Fix missing DKIM, multiple SPF records, and unknown senders | | Limited enforcement | p=quarantine; pct=25 if appropriate | Watch for support issues and report anomalies | | Broader enforcement | p=quarantine | Confirm normal business workflows still work | | Strong enforcement | p=reject | Use only when legitimate senders are understood |

The exact path depends on the client. Some domains should stay at monitoring longer. Some can move faster because they have a simple sender setup. The agency's job is to make the risk visible before policy changes affect real mail.

Client conversation checklist

Before recommending quarantine or reject, ask:

• Who sends email as this domain?
• Are there marketing campaigns scheduled soon?
• Which platforms send transactional messages?
• Does sales use a CRM or sequencing tool?
• Does support send through a helpdesk?
• Who receives DMARC reports?
• Who approves policy changes?
• Who handles urgent failures?

These questions keep the policy conversation operational. Without them, DMARC becomes a technical checkbox with business risk hidden underneath.

What to put in the monthly proof report

For agencies packaging email-authentication work into reporting, summarize:

• Current DMARC policy.
• SPF and DKIM status for known senders.
• Any unauthenticated or unknown sending sources.
• Recommended next policy step.
• Risks before moving to stricter enforcement.
• Client decisions needed.

This makes the work visible without pretending that DMARC alone guarantees deliverability.

Policy tags agencies should understand

The p= tag is the headline, but it is not the only operational detail in a DMARC record.

| Tag | Example | Why agencies care | |---|---|---| | p | p=none | Main domain policy | | sp | sp=quarantine | Subdomain policy, if present | | pct | pct=25 | Percentage of messages policy applies to | | rua | rua=mailto:dmarc@example.com | Aggregate report destination | | adkim | adkim=s | DKIM alignment strictness | | aspf | aspf=s | SPF alignment strictness |

Agencies do not need to overload every client with tag-level detail, but technical teams should understand the implications. A domain can have p=none at the organizational domain and a stricter sp policy for subdomains. A record can also use pct during rollout, although support and monitoring still need to be ready.

Strict alignment can be valuable, but it can also expose sender misconfiguration. Do not change alignment mode casually during the same pass as a policy enforcement change.

Common bad recommendations

Avoid these:

• "Everyone should move to reject immediately."
• "DMARC is done because the DNS record exists."
• "RUA reports are optional noise."
• "SPF pass means DMARC pass."
• "A deliverability problem must be fixed by reject."

Better recommendations sound like:

• "Start with monitoring while we identify senders."
• "Move to quarantine after core senders align."
• "Use reject only when the client accepts the operational risk."
• "Use RUA reporting or a monitoring platform to see who is sending."

This language helps agencies stay credible with technical clients and safe with non-technical ones.

Subdomain policy considerations

Many client domains use subdomains for marketing or transactional mail. DMARC policy can affect those differently depending on the record. If no subdomain policy is specified, subdomains may inherit the organizational policy. If sp= is present, subdomains can have their own requested policy.

Before enforcement, ask whether the client sends from:

• news.example.com
• mail.example.com
• support.example.com
• events.example.com
• platform-specific custom sending domains

Those flows may need separate DKIM, SPF, and DMARC checks. A root-domain decision is not enough when subdomains are active senders.

Related resources

• Bulk DMARC check for client domains
• DMARC, SPF, and DKIM explained for agencies
• Google bulk sender DMARC agency checklist
• SPF 10 lookup limit agency debugging guide
• Multiple SPF records cleanup guide
• DKIM record not found agency fix guide

Frequently Asked Questions

What does DMARC p=none mean?

DMARC p=none means the domain is publishing a DMARC policy but is not asking receivers to quarantine or reject messages based on DMARC failure. It is monitoring mode. Agencies use it to observe sender behavior, collect reports if rua is configured, and find SPF or DKIM alignment gaps before recommending stronger policy.

What is the difference between DMARC p=none, quarantine, and reject?

DMARC p=none, quarantine, and reject are policy levels. p=none monitors without asking receivers to block or quarantine. p=quarantine asks receivers to treat failing mail suspiciously, often spam or junk. p=reject asks receivers to reject failing mail. The right choice depends on sender inventory, SPF and DKIM alignment, reporting, and client risk tolerance.

Should agencies always recommend p=reject?

No. Agencies should not always recommend p=reject. Reject can be useful when the client understands every legitimate sender and alignment is working, but it can disrupt valid mail if applied too early. A safer path is to inventory senders, monitor with p=none, fix SPF and DKIM alignment, then consider quarantine or reject when evidence supports it.

Is p=none useless?

No. p=none is useful for discovery and monitoring. It lets a domain publish DMARC and receive aggregate reports without asking receivers to enforce quarantine or rejection. For clients with unknown senders, p=none is often the responsible starting point. The limitation is that it does not enforce by itself.

When should an agency recommend p=quarantine or p=reject?

Recommend p=quarantine or p=reject only after the client has a sender inventory, important platforms are aligned through SPF or DKIM, and someone owns report review and support fallout. Quarantine is often a safer intermediate step. Reject can be appropriate for mature setups, but it should be based on evidence rather than used as a default recommendation.

Can Inbox Pulse tell me which DMARC policy to use?

Inbox Pulse can show visible DMARC configuration signals, including whether a policy is present and what value is published. It does not decide policy for the client. Agencies still need to review legitimate senders, alignment, reporting ownership, client risk tolerance, and mail-platform evidence before recommending a DMARC policy change.

What does DMARC alignment mean?

DMARC alignment means the authenticated SPF or DKIM domain matches the visible From domain closely enough to satisfy the domain's DMARC alignment mode. Alignment matters because recipients see the From domain, not necessarily the technical return-path or signing domain. A message can pass SPF for a vendor domain but still fail DMARC for the client domain if alignment is missing.

Does Inbox Pulse aggregate DMARC RUA reports?

No. Inbox Pulse is positioned as a bulk email-authentication configuration audit tool. It checks configuration risk across client domains, but it does not replace a full DMARC RUA report aggregation platform. If a client needs ongoing XML aggregate report analysis, use a dedicated DMARC monitoring platform or an internal reporting process.

How should agencies explain a DMARC policy change to clients?

Start with business risk. Explain that stricter DMARC policies can reduce unauthorized use of the domain, but only after legitimate senders are configured correctly. Show the client which platforms send email, which are aligned, and which need fixes. Ask for approval before moving to quarantine or reject, especially when marketing, CRM, ecommerce, and support platforms are involved.