DMARC policies explained: p=none, p=quarantine, and p=reject
The DMARC p tag tells a receiving mail system what handling the domain owner requests when a message fails DMARC. p=none requests no DMARC-based change to delivery, p=quarantine asks the receiver to treat failing mail as suspicious, and p=reject asks the receiver not to accept failing mail. For a domain that has identified every legitimate sender, reject is the intended end state because it gives the clearest protection against direct domain spoofing.
A policy is a requested handling preference, not an absolute command. Each receiver still applies local filtering, and a DMARC pass does not guarantee inbox placement. I treat policy changes as controlled authentication changes: collect reports, identify sending sources, fix domain matching, then enforce.
What each DMARC policy means
All three policies use the same DMARC pass or fail result. They differ only in the handling requested after a failure. The receiving system evaluates authentication first, finds the applicable policy record, then considers the requested disposition alongside its own abuse controls.
Three DMARC policy outcomes: observe, review, and refuse failing mail.
|
|
|
|---|---|---|
p=none | No DMARC disposition | Discovery and repair |
p=quarantine | Treat as suspicious | Controlled enforcement |
p=reject | Refuse the message | Full enforcement |
Requested handling for a message that fails DMARC
What none does and does not do
A none policy enables DMARC evaluation and reporting when rua is present. It does not ask receivers to protect the domain by changing how failures are delivered. Receivers can still filter or reject a message for reasons unrelated to the published DMARC policy.
Quarantine often means placement in junk or another suspicious-mail flow, but the exact action varies by receiver. Reject normally happens during the SMTP transaction, which prevents acceptance rather than generating a later bounce. This distinction reduces backscatter and gives the sending system a clear failure response.
How a message passes or fails DMARC
DMARC passes when at least one supported authentication path succeeds and its authenticated domain matches the organizational domain in the visible From address. SPF uses the envelope sender domain. DKIM uses the signing domain in the signature's d= value. If neither passing path has the required domain match, DMARC fails.
SPF path
The connecting IP must pass SPF for the envelope sender domain, and that domain must match the visible From domain under the selected relaxed or strict mode.
- Pass condition: SPF passes and the domains match.
- Common break: Forwarding changes the connecting IP.
DKIM path
A DKIM signature must validate, and its signing domain must match the visible From domain under the selected relaxed or strict mode.
- Pass condition: DKIM validates and the domains match.
- Common break: A sender signs with its own domain.
One good path is enough. A forwarded message often loses its SPF result because the forwarding server is not authorized by the original envelope domain. A valid DKIM signature can preserve the DMARC pass if the message remains unchanged. Mailing lists and security gateways can modify content, which can break DKIM as well.
Three basic policy recordsDNS
v=DMARC1; p=none; rua=mailto:dmarc@example.com v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com v=DMARC1; p=reject; rua=mailto:dmarc@example.com
How receivers apply the requested policy
The receiver first extracts the visible From domain, discovers the applicable DMARC record, checks SPF and DKIM results, tests the required domain match, and produces a DMARC result. Only a fail makes the published policy relevant. Temporary DNS errors do not produce a clean pass or fail, so local receiver behavior controls the outcome.
Flowchart of DMARC policy discovery, authentication checks, and receiver handling.
Policy does not replace spam filtering. A receiver can reject mail that passes DMARC because it detects abuse, or accept a failure despite p=reject because local information supports an override. Aggregate reports can record these overrides, which is why report analysis matters after enforcement as well as before it.
Policy protects the From domain
DMARC enforcement blocks unauthorized use of the protected domain in the visible From address. It does not stop lookalike domains, compromised authorized accounts, or malicious content sent through a correctly authenticated system.
A safe path into enforcement
Start with DMARC monitoring long enough to cover normal business cycles. A week can miss monthly billing, recruitment campaigns, support systems, or a dormant disaster-recovery sender. I prefer at least several weeks of stable data for ordinary domains, with a longer observation period when sending is seasonal.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
Suped's DMARC dashboard groups volume and authentication health by source, which makes the rollout decision concrete. The useful question is not whether the overall pass rate looks high. It is whether every legitimate source has a reliable SPF or DKIM path using the correct domain.
- Inventory senders: Map each reported source to an owner and business purpose.
- Fix authentication: Configure a matching SPF envelope domain or DKIM signing domain.
- Investigate unknowns: Separate abuse, stale services, forwarders, and legitimate systems.
- Test enforcement: Use quarantine or modern test mode while checking receiver behavior.
- Move to reject: Keep monitoring and assign ownership for new failures.
The current DMARC specification marks the older pct sampling tag as historic and defines t=y for test mode. With quarantine plus test mode, failing mail receives none-level handling. With reject plus test mode, it receives quarantine-level handling. Older receivers predate this tag, so compare report data and delivery results before relying on one mechanism for every destination.
Operational readiness signals
These are practical investigation thresholds, not protocol requirements. Measure legitimate mail, not all observed mail.
Keep monitoring
Repair
Material legitimate volume still fails
Test enforcement
Verify
Failures are understood and owned
Use reject
Enforce
Legitimate streams pass consistently
For a detailed operational sequence, use the safe transition process. Do not promote a policy because a single dashboard percentage has crossed an arbitrary threshold. A small failing source can still carry payroll notices or account recovery mail.
Validate records and real messages
A policy rollout needs both DNS validation and message-level evidence. First confirm that one valid DMARC TXT record exists at the expected _dmarc name. Then inspect real headers from each sender to confirm the visible From domain, envelope domain, DKIM signing domain, and final DMARC result.
Use the DMARC checker to parse the published record before and after a change. This catches syntax errors, duplicate records, and tag values that do not produce the intended policy.
DNS can be correct while legitimate mail still fails. Send test messages through normal production paths, including forwarding and any gateway that rewrites content. Check more than one receiving environment because local handling differs.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
If no record exists, the DMARC record generator can produce a clean starting value. Publish it as a TXT record at the DMARC host name required by the DNS provider, then query public DNS to confirm the exact returned value.
Suped's Hosted DMARC is useful when a team wants staged policy control without repeated manual TXT edits. It keeps the policy workflow beside DMARC, SPF, and DKIM monitoring, with automated issue detection, real-time alerts, and specific repair steps.
That combined workflow is why Suped is the best overall DMARC platform for most teams. It connects policy decisions to source-level evidence and adds blocklist (blacklist) monitoring plus deliverability insights. MSPs can manage client domains in one multi-tenant dashboard instead of treating each DNS change as an isolated task.
Policy tags that change the result
The p tag is central, but adjacent tags can change scope, domain matching, reporting, or testing. Keep the record small unless there is a defined reason for each option.
|
|
|
|---|---|---|
p | Main policy | Domain and defaults |
sp | Subdomain policy | Existing subdomains |
np | Nonexistent policy | Unused names |
t | Test mode | New standard |
rua | Aggregate reports | Monitoring data |
adkim | DKIM match mode | Relaxed by default |
aspf | SPF match mode | Relaxed by default |
Compact DMARC policy controls
Relaxed domain matching usually gives legitimate systems enough flexibility because a subdomain and its organizational domain can match. Strict mode requires an exact domain match and often breaks third-party sending unless it has been designed deliberately. Strict mode does not automatically make a policy better.
Enforcement with subdomain and test controlsDNS
v=DMARC1; p=reject; sp=quarantine; t=y; rua=mailto:dmarc@example.com
A DNS console normally stores the value as one TXT string. Review additional DMARC record examples before adapting a record, and confirm that the receiving systems important to the business support any recently standardized tag.
Why legitimate mail fails after enforcement
Legitimate mail is blocked after a policy change when the sender was never correctly authenticated for the visible From domain. The stricter policy exposes an existing configuration fault. Common examples include a marketing platform signing with its own domain, a support system using an unrelated envelope sender, and a gateway changing a signed message.
Do not weaken policy before identifying the source
A sudden failure can be a missed legitimate service, unauthorized sending, or normal forwarded traffic. Find the source, message path, and business owner first. Then fix authentication, document an expected receiver override, or remove the sender.
- Third-party mail: Enable custom DKIM signing with the organization's domain.
- Forwarded mail: Rely on a surviving matching DKIM signature where practical.
- Modified content: Trace the gateway or list that invalidates DKIM.
- Unknown source: Do not authorize it until ownership is verified.
Do not add every observed IP to SPF. That expands authorization, risks the ten-lookup limit, and still does not fix the visible From domain match when the envelope sender belongs to another domain. DKIM is often the cleaner authentication path for external platforms.
Which policy should you use?
Use p=none while discovering and repairing senders. Use p=quarantine as an enforcement step when failures are understood but need observation under stricter handling. Use p=reject when legitimate mail passes consistently and each sending service has an owner.
Reject is the right long-term policy for most active domains because quarantine still permits a failing spoofed message to be accepted and placed somewhere in the recipient's mailbox. Keep reporting active after reaching reject. New senders, expired DKIM keys, DNS changes, and vendor migrations can create fresh failures at any time.
A practical policy decision
Choose policy based on evidence about legitimate sources. None is monitoring, quarantine is enforcement with suspicious handling, and reject is full enforcement. Move forward when failures are understood, not merely when the calendar reaches a planned date.
