DMARC Policy Explained from None to Reject

A DMARC policy tells receivers to deliver and report failing mail at p=none, treat it as suspicious at p=quarantine, or refuse it at p=reject. Choosing reject isn't a starting preference, it's a later evidence decision you make after every legitimate sender you've found passes with alignment.

That evidence question matters more than the DNS syntax. A record takes minutes to publish, but proving that quarantine or reject won't silence billing notices, support replies, or monitoring alerts takes patient report reading.

Table of Contents

• Why a Published DMARC Policy Is Not Enforcement
  • Compliant on paper and unprotected in practice
• None Quarantine and Reject Compared
  • p=none
  • p=quarantine
  • p=reject
• How Alignment Turns SPF and DKIM Into a Pass
  • One aligned pass is enough
  • Authentication is common and enforceable protection is not
• The DNS Tags That Change Receiver Behavior
  • Reading one complete record
  • Reporting tags decide whether you learn anything
• Turning Raw DMARC XML Into Readable Reports With Suped
  • What helps beyond parsing
• Reading Aggregate Reports Before Changing p
  • Sort every row into four groups
  • Give the groups time to settle
• Why Most Domains Never Leave Monitoring
  • The stall is an inventory problem
  • What counts as sufficient evidence
• Forwarding and Mailing Lists That Fail Honestly
  • Telling honest failures from attacks
  • Choosing quarantine or reject under forwarding
• Move to Enforcement Only With Evidence
  • Knowing when you're done

Why a Published DMARC Policy Is Not Enforcement

Say a SaaS company sends its product notifications, support replies, invoices, and outage alerts under one visible From domain. It publishes p=none, ticks a compliance box, and assumes spoofers are now blocked. They aren't. The record asks receivers to observe failures and send reports, not to change delivery.

That gap became a production issue when Google and Yahoo introduced stronger sender requirements beginning in February 2024 for bulk senders sending more than 5,000 messages per day, requiring SPF and DKIM authentication, a published DMARC record, and alignment with the visible From domain. Under those rules, p=none could satisfy the basic publication requirement, while noncompliant bulk mail could receive temporary SMTP failures.

Compliant on paper and unprotected in practice

So a domain can meet the baseline and still tell receivers to deliver mail that fails. Its marketing platform, transactional sender, help desk, SaaS notifications, and infrastructure alerts all keep flowing, including any that aren't aligned yet.

Publishing a record gives you visibility. Only quarantine or reject asks a receiver to act on a failure.

Treat none as observation, quarantine as suspicious treatment, and reject as refusal. The decision to move between them should rest on report evidence, not on how complete the DNS entry looks.

None Quarantine and Reject Compared

Choose a row from evidence, not from how strict it sounds. The table below covers what each value asks for, when it fits, and what breaks if you pick it too early.

p=none

p=none requests no delivery action and exists for observation. You publish it, point aggregate reporting at a mailbox someone reads, and learn who sends with your From domain. Its failure mode is obvious once you say it plainly. A convincing spoof that fails authentication can still reach the inbox, because you asked receivers not to intervene.

That's a reasonable trade while your inventory is incomplete. It isn't a safe resting place. Staying here indefinitely means you've bought reporting without buying protection, and the reports only help if someone acts on them.

p=quarantine

p=quarantine asks receivers to treat failures as suspicious, commonly by placing them in spam. RFC 7489, the DMARC specification defines the required p tag that determines receiver handling, and the quarantine request sits in the middle of that ladder. Pain from this setting is recoverable. A customer can fish an invoice out of a spam folder, and your support team hears complaints that point straight at the missed sender.

That's exactly why quarantine works as a proving stage. You're testing enforcement against real traffic while keeping a safety net under legitimate mail you haven't fixed yet. If a vendor slips through your inventory, you get noisy spam folders instead of vanished messages.

p=reject

p=reject asks receivers to refuse the message, preferably during the SMTP transaction. The sending system sees a bounce, the recipient sees nothing, and there's no spam folder to rescue a false positive from. For an impersonator, that's the point. For a forgotten alert mailer sending with your From domain, it's a silent outage until someone notices missing mail.

Remember the blast radius. Your policy covers the organizational domain and normally its subdomains, so reject reaches marketing tools, ticketing systems, and notification senders that authenticate a vendor domain instead of yours. Receivers aren't legally bound by your record, but major mailbox providers do honor it, which makes a premature reject a real delivery event.

Practical rule: Monitor first, quarantine second, reject third. Skipping stages doesn't make you stricter, it makes you blind.

That order exists because each stage answers a question the previous one can't. None tells you who sends, quarantine tells you who still hurts, and reject commits you to refusing everything left over. Publishing reject on day one reverses the logic and lets the bounces do your inventory work.

How Alignment Turns SPF and DKIM Into a Pass

Consider a bulk sender that mails receipts for a retailer. Its SPF check passes cleanly, yet DMARC fails. The reason confuses most operators the first time they see it, and this diagram shows the rule that explains it.

DMARC doesn't pass because SPF or DKIM passed somewhere on the message. It passes when at least one mechanism both passes and aligns with the domain readers see in From. SPF alignment compares the authenticated envelope sender, the Return-Path domain, with that From domain. DKIM alignment compares the signing domain in the d= tag with it.

The vendor above SPF-authenticates its own return-path domain while the visible From uses the customer's domain. SPF passed, nothing aligned, so DMARC failed. This is the single most common surprise in early reports, and it's a vendor configuration problem, not a DNS mystery.

One aligned pass is enough

You don't need both mechanisms. A message with broken SPF can still pass DMARC when its DKIM signature validates and the d= domain aligns with From. That redundancy saves forwarded mail later, and it means your fix for a failing vendor can be whichever aligned path the vendor supports.

Default alignment is relaxed, so an organizational-domain match qualifies and mail.example.com can align with example.com. Strict alignment demands an exact domain match and is a deliberate tightening for mature setups, not a starting point. Choosing strict early adds failures without teaching you anything new about your senders.

Authentication is common and enforceable protection is not

The gap between passing checks and aligned passes has history. The FTC study of 569 large online businesses found 86% used SPF, but fewer than 10% had implemented DMARC in a way that enabled spoofing intelligence and receiver rejection. Those businesses authenticated plenty of mail. Almost none could ask receivers to refuse unaligned impostors.

Before changing p, read aggregate reports by source IP, envelope domain, DKIM signing domain, and alignment result. A source that passes nothing aligned is your work queue. A source with one aligned pass is done, even when its other check fails.

The DNS Tags That Change Receiver Behavior

Your record lives as a TXT entry at the _dmarc name for your domain. Only two tags are required, and the rest tune scope, sampling, and reporting. Use this table as the reference when you inspect a live record.

Reading one complete record

Take this starting record and decode it in order: v=DMARC1; p=none; sp=none; pct=100; adkim=r; aspf=r; rua=mailto:dmarc@example.com. The v tag announces DMARC, p=none sets monitoring for the main domain, and sp=none keeps subdomains on monitoring too, which protects a support subdomain that isn't ready while the apex advances later.

pct=100 applies that policy to all failing mail, which is the default. A lower percentage samples enforcement during a test, but sampling can't tell you which customers got affected, so treat it as a brief experiment. adkim=r and aspf=r keep both alignment modes relaxed while you learn your traffic.

Reporting tags decide whether you learn anything

The rua tag names where aggregate XML reports go. Point it at a mailbox or parser your team reads, because a record without rua leaves you blind and makes every later policy change a guess. ruf requests per-message failure samples, and it is often omitted at first since samples can contain message content and many receivers won't send them anyway.

Two failure modes deserve a check before you trust any report. Publishing two DMARC records, or a typo in the v tag, can lead providers to ignore your policy entirely. That's why a quick DNS health check belongs in the routine after each edit.

Confirm the published TXT matches the table before judging a single report row. Teams regularly debug senders against a record receivers never saw.

Turning Raw DMARC XML Into Readable Reports With Suped

Aggregate reports arrive as raw XML, one file after another, and reading them by hand gets old within a week. A parser earns its keep when it sorts each row into a decision: fix this sender, measure this forwarder, or treat this source as spoofing. That sorting is where monitoring turns into evidence. Domains sit at p=none because nobody can name which sender owns which failure, and a readable report is the only fix for that.

Suped is a platform for managing email authentication, domain security, and deliverability. Its DMARC monitoring ingests aggregate XML, categorizes sending sources, and shows authentication results, compliance metrics, and historical trends, with recommendations for issues affecting legitimate delivery. Raw XML becomes a named list of vendors and failure modes, which is the raw material you need before quarantine or reject is safe to consider.

What helps beyond parsing

• Hosted records: Hosted DMARC, SPF, DKIM, and MTA-STS centralize policy changes, and SPF flattening addresses the ten-lookup limit that breaks growing sender lists.
• Alerts that matter: Email and webhook notifications flag new senders, authentication declines, and policy problems, so a broken vendor surfaces before you tighten p.
• Wider monitoring: Deliverability, blocklist, reputation, and lookalike-domain monitoring cover the impersonation and listing issues that DMARC alone doesn't.
• Portfolio support: A multi-tenant dashboard lets managed service providers run many client domains without switching accounts, with automated reporting built in.

Suped offers a free tier, so you can check what your domain publishes today with a dmarc checker before deciding whether a paid plan is worth it. The platform pays for itself when report volume or domain count makes manual XML review unrealistic, or when you want hosted authentication and staged policy guidance in one place rather than a mailbox that only collects reports.

Reading Aggregate Reports Before Changing p

Don't start with the pass rate. Start with the fields on each row, because one row covers one source IP and tells you a complete story: source IP, message count, policy_evaluated disposition, SPF and DKIM results with their domains, header_from, and the envelope and DKIM d= domains.

Sort every row into four groups

• Known vendor and aligned pass: It's done. Note the domain it aligns with and move on.
• Known vendor and failing alignment: A SaaS tool sends with your From domain but authenticates its own. Fix DKIM signing or the return path in that vendor's settings before touching p.
• Known forwarder or list server: SPF fails from a source you recognize. Measure its share of your failures and check whether it seals ARC before deciding how much it should worry you.
• Unknown IP with no DKIM: A sudden volume spike from a source nobody claims is likely spoofing until proven otherwise. It shouldn't block enforcement once groups two and three shrink.

That sorting turns a frightening report into a short work list. Failures often concentrate in group two, which is good news, because vendor settings are things you control.

Give the groups time to settle

Read at least one full billing and campaign cycle before calling any group finished. Monthly invoices, quarterly statements, and seasonal campaigns hide from short windows. Record the message count per group and the date you verified each vendor fix, since those numbers carry the enforcement decision.

Keeping that record current is easier alongside routine DNS monitoring of the records those fixes depend on. When a verified sender regresses, you'll know which change to revisit instead of reopening the whole inventory.

Evidence test: If you can't name the owner of every high-volume row, you aren't ready to leave none.

Why Most Domains Never Leave Monitoring

Adoption numbers flatter the industry. Tracking of 34,212 domains found 71.5% had adopted DMARC by 2026, while only 26.6% reached p=reject, leaving a 44.9-percentage-point gap between adoption and strong enforcement. Separate 2026 research covering approximately 1.8 million domains found 29.2% still used p=none, compared with 22.9% using quarantine or reject.

The stall is an inventory problem

Syntax rarely blocks anyone. What blocks teams is unfinished work that DNS can't do for them.

• Third-party SaaS creep: A CRM, billing platform, or survey tool starts sending with the company From domain and nobody tells operations.
• Forgotten subdomains: Support or product subdomains send for years outside the main inventory.
• Fear of the unseen failure: Nobody can prove a legitimate sender isn't lurking in next month's traffic, so the change slips another quarter.

Say a company fixes its main platform, its marketing tool, and its help desk. Reports look clean for two weeks. Then the annual renewal notices fire from a billing system that authenticates the vendor's domain, and the whole project pauses again. That scenario, repeated across vendors, is how domains sit at none for years.

What counts as sufficient evidence

Define the bar before you start arguing about dates. Every source IP sending wanted mail is identified and owned. Each authorized service produces an aligned SPF or aligned DKIM pass, verified in live reports rather than vendor documentation. Subdomains are checked, including any that will deliberately stay weaker under sp. Report volume covers a full business cycle, not one quiet weekend. Unknown failing sources carry a label: spoofing, forwarding, or a vendor still being fixed.

"DMARC adopted" is a weak security metric. Until the policy asks for quarantine or reject, receivers have no instruction to stop a spoof.

Once those conditions hold, remaining failures are either unwanted or explainable, and enforcement becomes a calculated change instead of a leap. If they don't hold, the honest status is still monitoring, however long the record has existed.

Forwarding and Mailing Lists That Fail Honestly

An employee forwards work mail to a personal account through an alumni forwarder. The message arrives with the original From intact, but the forwarder sent it from its own IP, so the original SPF check no longer matches. Nothing malicious happened, yet SPF alignment is gone.

Now picture a discussion list that adds a subject tag and a footer with unsubscribe text. Those edits change content the sender signed, which can invalidate the DKIM signature. Again, a legitimate path produces a genuine failure.

Microsoft's DMARC guidance identifies forwarded mail and mailing lists as normal causes of DMARC failure and points to trusted ARC sealing or narrowly scoped handling rather than treating every failure as hostile. ARC lets an intermediary preserve the original authentication results it saw, so a downstream receiver that trusts that sealer can still deliver the forwarded copy.

Telling honest failures from attacks

Reports separate the two patterns well. A steady trickle of failures from a known list server, with consistent volume and recognizable domains, looks nothing like a sudden burst from an unfamiliar cloud IP sending your From domain with no DKIM at all. Measure each source's share of total failures before deciding it matters.

Choosing quarantine or reject under forwarding

Reject gives you the strongest impersonation resistance, but it can drop forwarded and list mail where receivers don't trust ARC results. Quarantine is safer while forwarding volume is material and ARC support among your intermediaries is unconfirmed, because spam placement is visible and recoverable. Permanent none avoids both risks by protecting nothing.

Measure failure share by source, confirm whether intermediaries seal ARC, then pick the stricter policy your traffic can survive.

There's no universal winner here. A domain whose mail rarely gets forwarded can reject sooner. A domain serving list-heavy communities may hold quarantine longer and accept a smaller spoofing window. Either choice is defensible when it's measured.

Move to Enforcement Only With Evidence

Treat the move like a production rollout with a rollback plan, not a DNS tidy-up. These six steps take you from a fresh record to reject while tying every change to the evidence bar.

1. Publish p=none with reporting on: Set rua to a mailbox your team reads and keep sp=none until subdomains are inventoried.
2. Hold through one full cycle: Stay at none for at least one billing and campaign cycle while your four report groups settle and late senders appear.
3. Fix the known misaligned vendors: Configure aligned DKIM or SPF for each one and confirm the aligned pass in live reports before any tag changes.
4. Move to quarantine at pct 100: Use a sampled percentage only when a short test is unavoidable. Write your rollback trigger first: a failure spike from a known vendor, or support tickets about missing mail.
5. Advance to reject deliberately: After forwarding and list sources are classified, publish reject, or keep a weaker sp for a subdomain that still can't align. Roll back on the same triggers as quarantine.
6. Re-read the live record after every change: Confirm the published TXT matches your intended tags, because a deleted or mistyped record returns you to no policy at all.

Knowing when you're done

You're ready to stop at reject when you can answer three questions without checking: what's our current policy, which failing sources remain and why, and what event sends us back a step. If any answer needs a shrug, stay put and gather more evidence.

Keeping watchdog checks on the record afterward matters as much as publishing it. Our Uptime Monitoring runs HTTPS, TCP, ICMP and DNS checks from four probe regions, which suits the job of noticing when a record disappears. Nobody misses a vanished DMARC record until spoofed mail starts landing again.

Change discipline: One tag change at a time, one verification after it, and a written trigger that tells you when to undo it.

Publish p=none with reports flowing to a mailbox you'll read this week, classify every source in the first reports, and set your quarantine date against that evidence. Add continuous checks with Fivenines so the record you worked to enforce can't vanish unnoticed, and tighten to reject only when the remaining failures are mail you'd refuse yourself.