DMARC Policy Progression: From p=none to p=reject Without Breaking Email

The Microsoft customer support ticket arrived on a Tuesday in late October. The customer had been at DMARC p=quarantine for three weeks and was now seeing legitimate email from a contract worker being marked as spam by their own internal users. The customer wanted to know if they should move back to p=none or push forward to p=reject. The right answer was neither, but explaining why required walking through six weeks of DMARC aggregate report data and identifying three sender systems the customer had forgotten they used.

This is the situation most teams are in when they think about DMARC enforcement. They started with good intentions. They published p=none to monitor. They saw their reports, mostly looked clean. They moved to p=quarantine. Some things broke. They are now at the moment of “do we move forward to reject, fall back to monitor, or freeze here?” The right answer depends on data the team probably has not been reading carefully enough.

We have been guiding customers through DMARC progression since the Gmail and Yahoo October announcements brought new urgency to authentication. The progression sequence we use is not novel. The novelty is in the specific failure modes we have catalogued at each phase and the operational discipline required to move forward safely.

This post is the long version of that progression. Eight months from a clean start to p=reject with full alignment. The phases are not equal length. The data collection and analysis is the work; the policy publication is mechanical.

Why progression rather than direct enforcement

The temptation is to skip ahead. Publish p=reject from day one, force the rest of the organization to figure out which sending systems are broken, fix things as they emerge. This approach fails for predictable reasons.

The first reason is unknown senders. Almost every organization has more email-sending systems than the IT team knows about. Marketing automation tools added by the marketing team. HR systems sending automated notifications. Finance tools sending payment reminders. Customer support tools sending case updates. Each of these is a potential source of “legitimate” mail that may not be properly authenticated through your domain. Direct p=reject blocks all of this mail at the receiver side without any warning.

The second reason is partial alignment. Many SaaS tools sign DKIM with their own domain rather than the customer’s domain. Others send through their own infrastructure with Return-Path domains they control. Either case produces mail that passes SPF or DKIM at the sender level but fails DMARC alignment with the From header. The mail is legitimate but DMARC fails. Direct p=reject blocks legitimate authenticated mail because of alignment issues that take weeks to identify and fix.

The third reason is forwarding. Mail forwarded by intermediate systems (mailing lists, corporate mail forwarders, individual .forward files at universities) may lose alignment in transit. The forwarded mail fails DMARC at the eventual receiver even though the original was authenticated. Direct p=reject produces forwarding failures that confuse legitimate communication.

The fourth reason is reputation cost. When mail is rejected by DMARC at scale, receivers note the volume. Repeated rejection events flag the sending domain for additional scrutiny. The reputation damage from a botched DMARC rollout takes months to recover.

The phased approach exists to address each of these failure modes deliberately. The phases give the operator time to identify unknown senders, fix alignment issues, address forwarding scenarios, and build sending reputation under enforcement without catastrophic mistakes.

Phase 0: Pre-flight data collection (weeks 1-2)

Before publishing any DMARC record, document what you have.

List every system that sends mail using the domain in the From header. Marketing automation, transactional email service, CRM, HR system, finance system, payroll, customer support, sales engagement platform, third-party services that send on the company’s behalf (PayPal sending invoices with noreply@example.com in the From header, for example).

For each system, document the Return-Path (envelope sender) domain and the DKIM signing domain. These may differ from the From domain. Document them anyway.

Document the current SPF record. Walk the include tree, identify each include, identify which sender it supports. Often this surfaces SPF records pointing to services no longer in use (drop them) or services missing (add them, but consider whether they sign DKIM with your domain instead).

Document existing DKIM keys. Many organizations have DKIM signatures from years ago for services that no longer exist. Audit and clean up. Confirm current DKIM keys for active senders are using 2048-bit RSA where possible (older 1024-bit keys are deprecated and may not pass authentication in 2024+).

This data collection takes 1-2 weeks for medium-sized organizations. The output is a spreadsheet listing every sender, their Return-Path, their DKIM domain, and notes about known alignment issues.

The temptation to skip this phase is strong because the deliverable is not glamorous. The data collection is the foundation. Without it, the later phases produce confusion.

Phase 1: Monitor with p=none (weeks 3-6)

The first published DMARC record. The policy directs receivers to take no action on failed authentication but to send aggregate reports to a designated address.

The DMARC record:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensics@example.com; pct=100; aspf=r; adkim=r;

p=none means no policy action. Failed authentication is logged but mail still flows. The rua parameter specifies where aggregate reports go. The ruf parameter specifies where forensic reports (per-failure detail) go, though many receivers no longer send forensic reports due to privacy concerns. The pct=100 means apply to all mail. The relaxed alignment (aspf=r, adkim=r) allows subdomain alignment, which is more forgiving than strict alignment.

The DMARC report consumer is critical at this phase. Raw DMARC aggregate reports are XML files sent to your designated address. Reading them manually is impractical at any volume. Use a service: dmarcian, EasyDMARC, Postmark DMARC Digests, Valimail, MailHardener, or open-source tools like ParseDMARC. The service ingests the XML reports and produces dashboards showing what is failing and why.

The work of Phase 1 is reading the reports. You will see:

Senders you knew about, properly authenticating. Good.

Senders you knew about, failing authentication. Either misconfigured (fix configuration) or alignment issue (decide on subdomain strategy or DKIM signing approach).

Senders you did not know about. This is where Phase 0 documentation gets validated. Every “unknown” sender in the reports needs to be identified and decided about: legitimate (document and fix authentication), unauthorized (investigate as potential abuse), or unauthorized but expected (the marketing team signed up for another tool without telling IT).

Forwarding failures. Mail that authenticated at the original sender but failed DMARC at the eventual receiver because forwarding broke alignment. Identify the forwarding patterns and plan ARC implementation (more on this in a later post).

The clean exit criteria for Phase 1: every meaningful sender in your aggregate reports either passes DMARC or you have a documented plan to fix the failure. The volume of failed mail dropping to under 5% of total mail volume is a reasonable signal that you understand your senders.

Time in Phase 1: 4-6 weeks minimum. Some organizations spend 3-6 months here. The longer time is not wasted; it surfaces edge cases that only appear under specific calendar events (quarterly reports, year-end billing, annual conferences) or seasonal sending patterns.

Phase 2: Quarantine with subdomain (weeks 7-12)

The first enforcement step. Instead of moving the entire domain to quarantine, start with subdomain enforcement.

The DMARC record:

v=DMARC1; p=none; sp=quarantine; rua=mailto:dmarc-reports@example.com; pct=100; aspf=r; adkim=r;

The sp=quarantine policy applies to subdomains. The main p=none policy still applies to the root domain. The idea: catch any sending from unauthenticated subdomains (legitimate or spoofed) without affecting the main mail flow.

This phase often surfaces subdomain abuse. Spammers commonly use random subdomains of legitimate domains to bypass reputation checks (abc123.example.com for spam, where the legitimate sender uses example.com and marketing.example.com). The subdomain quarantine policy catches this without affecting the legitimate root domain mail.

The aggregate reports during Phase 2 should show subdomain failures being quarantined and root domain mail still flowing. If legitimate subdomain mail starts failing, identify it and fix authentication.

Time in Phase 2: 4-6 weeks. Some organizations skip this phase if they have full visibility from Phase 1 and are confident no legitimate subdomain mail exists. The conservative approach is to keep this phase as a checkpoint.

Phase 3: Quarantine for root domain at 10% (weeks 13-16)

The first enforcement step affecting the root domain. The pct parameter applies the quarantine policy to a percentage of failing mail rather than all of it.

The DMARC record:

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

Now 10% of mail that fails DMARC for the root domain gets quarantined. The other 90% continues to flow with no action. If something legitimate is failing, you see the impact at 10% of the volume rather than 100%.

The aggregate reports show the impact. If legitimate mail is in the failing category, you see roughly 10% of users reporting “missing emails” or “this went to spam.” The impact is bounded; you can identify and remediate before going to higher percentages.

The wrong response to seeing legitimate failures at 10% is “increase to 100% and hope it works out.” The right response is “investigate the failures, fix the authentication, then increase the percentage.”

Time in Phase 3: 2-4 weeks. The shorter time is acceptable because you have already done the heavy work in Phases 1-2. This phase is verification of your fixes.

Phase 4: Quarantine at 50% (weeks 17-20)

Increase the percentage. The DMARC record:

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

50% of failing mail now gets quarantined. The impact scales linearly with percentage. If you had 100 legitimate failing emails per day at 10%, you now have 500 quarantined per day. The impact is more visible to recipients.

This is often the phase where unknown senders surface. A small percentage of failing mail in earlier phases might not produce noticeable user impact. At 50%, the impact is hard to miss. Internal users complain about missing emails. Customer-facing teams report support tickets from senders who got rejection notices.

The aggregate reports should be showing predominantly authenticated mail at this point. If significant failure volume remains, the move to higher percentages is premature.

Time in Phase 4: 2-3 weeks. Same as Phase 3 in terms of verification.

Phase 5: Quarantine at 100% (weeks 21-24)

Full quarantine policy. The DMARC record:

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

Every failing mail gets quarantined. No partial enforcement. The phase verifies that the full quarantine policy works at scale before moving to reject.

The aggregate reports should be clean: minimal failures, all of which are legitimately unauthorized (spoofing attempts) or expected (occasional forwarding failures).

Time in Phase 5: 4-6 weeks. The longer time allows quarantine policy to stabilize and any remaining edge cases to surface. This is the last phase before reject; rushing it produces problems that are harder to fix at reject.

Phase 6: Reject at 10% (weeks 25-28)

The first true rejection phase. Mail that fails DMARC is rejected at the receiver, not quarantined. The rejection produces an SMTP error response to the sending server; the recipient never sees the message.

The DMARC record:

v=DMARC1; p=reject; sp=reject; pct=10; rua=mailto:dmarc-reports@example.com; aspf=r; adkim=r;

10% of failing mail gets rejected. Compared to quarantine, rejection is more visible to senders (they get bounce-style errors) and more permanent (the message is gone, not in a spam folder).

The phase tests reject behavior at low percentage. Any senders that still fail will produce bounces; the operator can identify and remediate.

Time in Phase 6: 2-3 weeks.

Phase 7: Reject at 50% (weeks 29-30)

Increase to 50%. The DMARC record:

v=DMARC1; p=reject; sp=reject; pct=50; rua=mailto:dmarc-reports@example.com; aspf=r; adkim=r;

Same pattern as Phase 4 but with rejection. Verify and remediate before going to full reject.

Time in Phase 7: 1-2 weeks.

Phase 8: Reject at 100% (week 31+)

Full DMARC enforcement. The DMARC record:

v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:dmarc-reports@example.com; aspf=r; adkim=r;

All failing mail rejected. The DMARC progression is complete.

The aggregate reports continue. The operator continues monitoring for new senders that may emerge (a new marketing tool, a new SaaS adoption, a forgotten system that resurfaces). The reports become the ongoing operational visibility into the domain’s email authentication health.

Time in Phase 8: indefinite. This is the steady state.

The forwarding problem and the ARC partial solution

DMARC enforcement breaks forwarding. The forwarding pattern: original sender sends to mailing list, mailing list adds a [List-Name] prefix or footer, forwards to subscribers. The modification breaks DKIM signature integrity. SPF passes for the forwarding system but the From header is still the original sender. DMARC fails alignment. Mail rejected.

The receiving providers know about this. They implement workarounds: trusted forwarding allowlists, ARC (Authenticated Received Chain) verification, mailing list specific handling. None of these is universal.

ARC is the standardized solution. The forwarding system inserts ARC headers documenting that DMARC passed at their server before forwarding. The receiver checks ARC headers and gives some credit for the prior pass even if the current DMARC check fails.

ARC implementation requires the forwarding system to be ARC-aware. Many mailing list managers (Mailman 3, Sympa, Google Groups) implement ARC. Older systems may not. The mailing list problem is partially solved but not fully.

For the DMARC progression timeline, the practical advice: ensure your own systems implement ARC properly. Discourage customers from operating their own mailing lists if practical (or use ARC-aware list management). Accept some forwarding failure as the cost of DMARC enforcement; the cost is justified by the protection enforcement provides.

What we have learned about the failure modes

Across multiple customer implementations, certain failure modes recur.

The “forgotten sender” failure. An organization runs p=quarantine for two weeks, sees no issues, escalates to p=reject. A week later, someone in accounting reports that monthly invoice emails sent by the accounting software are bouncing. The accounting software had been sending mail through its own infrastructure with a From header using the company domain but no SPF or DKIM authentication aligned with that domain. DMARC reject blocked the mail.

The “forwarding chain” failure. A customer in academia moves to p=reject and university faculty start reporting that emails sent to their .forward files at the university are not reaching them. The forwarding chain breaks DMARC alignment in ways that no single intermediate system can repair.

The “subdomain spoof” failure. An organization moves to p=reject and starts seeing aggregate reports for subdomain mail that fails DMARC. Investigation reveals that competitors or spammers have been using random subdomains to send mail spoofing the company. The DMARC enforcement is working correctly; it is catching spoof attempts. But the volume of spoofs is surprising.

The “DKIM key rotation” failure. An organization moves to p=reject and then rotates DKIM keys without proper key publication. Mail signed with the new key fails DMARC because the receiver cannot verify the signature. Several days of mail bounces before the key rotation issue is detected.

The “third-party send” failure. An organization moves to p=reject and a vendor sending mail on the organization’s behalf (PayPal, Stripe, customer notifications from a SaaS tool) stops working because the vendor’s mail does not authenticate properly with the customer’s domain. The vendor either needs to be reconfigured to send from a different domain, or the customer needs to set up proper authentication for that vendor’s sending path.

The honest assessment of the time investment

The 30-week progression is realistic for medium-sized organizations starting from no DMARC infrastructure. Smaller organizations with simpler sender stacks can complete progression in 12-18 weeks. Larger organizations with complex sender stacks may need 12+ months.

The time is justified by what is at stake. A botched DMARC rollout produces mail rejection at scale, reputation damage at receivers, business communication failures, and operational fire-drills that consume engineering time for months. The progression is the engineering work done up front to avoid those failures.

The Gmail and Yahoo October announcements have created urgency. Senders who have not started DMARC progression need to start now. The February 2024 enforcement deadline for the new bulk sender requirements does not technically require p=reject; the requirement is p=quarantine or p=reject. Starting from no DMARC means you should target p=quarantine minimum by January 2024 at the latest. The progression to p=reject can continue through 2024 at a more measured pace.

For organizations starting DMARC progression now, in November 2023, the realistic timeline targets are: p=none and aggregate report monitoring by end of November 2023. p=quarantine at 10% by early January 2024. p=quarantine at 100% by February 2024 to meet the bulk sender requirements. p=reject progression through 2024.

For organizations already at p=reject, the work is monitoring and remediating new senders as they emerge. The DMARC reports are the ongoing health check on the domain’s authentication posture.

What we are doing with customers

Our customer-facing process for DMARC progression mirrors the phases above with some specific operational practices.

We use a DMARC report consumer (we currently work with dmarcian for most customers) to make the aggregate reports digestible. Raw XML reports are unreadable at volume; the dashboard view is necessary.

We schedule weekly check-ins during active progression phases. The report data and customer-reported impacts are reviewed weekly. Decisions about whether to advance to the next phase or hold at the current phase are made based on data.

We document every alignment decision. When a customer has a third-party sender that is hard to align (vendor sends with their own DKIM domain that does not match the customer’s), the decision about whether to push for alignment, accept the alignment failure, or change vendors is documented with reasoning.

We coordinate with the customer’s IT and marketing teams. The DMARC progression affects systems owned by different teams. Without coordination, one team’s changes break another team’s authentication setup.

We train customer teams to read aggregate reports themselves. The eventual goal is the customer maintaining their own DMARC compliance without our involvement. Our job is to set the foundation and teach the customer to maintain it.

The eight-month progression is the conservative path. The pressure from the 2024 enforcement deadlines is pushing faster timelines. Customers who started in October are realistically targeting p=quarantine by February and p=reject by mid-2024. Customers who start now have less margin. Either way, the progression is the work; the destination is straightforward.