DMARC

The Monitor-to-Reject Playbook: Rolling Out DMARC Enforcement Without Breaking Mail Flow

September 11, 2026

Rodney Hall, COO— AI-assisted and reviewed prior to publication.

Every MSP that has ever flipped a client's DMARC record to p=reject remembers the moment right before doing it: the quiet dread that some invoice-sending SaaS tool, some marketing platform, or some forgotten internal script is about to start bouncing mail with no warning. That fear is well founded, and it is also the reason so many domains sit at p=none for months or years after the record first goes live.

The safest way to reach enforcement is to treat p=none as an active data-gathering phase, use DMARC aggregate reports to inventory every sending source before touching the policy tag, fix authentication gaps sender by sender, and only then step up through quarantine to reject on a schedule the reports justify rather than a calendar deadline.

Why do so many domains stall at p=none?

Most domains stall because nobody built the sender inventory before they built the policy. A DMARC record at p=none collects visibility without enforcing anything, which is exactly why the original DMARC specification recommends it as the starting point for any deployment.

The trouble is that visibility only helps if someone reads the aggregate reports and acts on them. Shared mailboxes, help desk ticketing systems, HR payroll platforms, and marketing automation tools all send mail using a domain's name, and each one needs its own SPF include or DKIM selector before enforcement is safe. Skipping that inventory step is the single most common cause of mail flow breaking once quarantine or reject goes live.

What changed with DMARCbis, and why does it matter to the rollout?

The IETF has just replaced the fifteen-year-old DMARC specification with three new documents. RFC 9989, along with its companion reporting RFCs, moves DMARC from an informational document to a formal Standards Track proposal and, notably for anyone running a staged rollout, removes the pct tag that has been the backbone of gradual enforcement since 2015.

In its place, the new specification introduces a binary t tag. As Proofpoint's technical breakdown of the update explains, the tag tells receivers whether a domain owner is testing policy application, applying failure handling one level below the stated policy while t=y is set, before dropping to full enforcement once removed. That is a meaningfully different mechanic than the old percentage-based rollout, which let a domain owner apply reject to, say, 10 percent of failing mail while leaving the rest at quarantine.

MSPs used to nursing a client from pct=10 up to pct=100 in careful increments now need to plan around a rollout that is closer to a light switch than a dimmer. Existing records with pct still function, since the new RFCs remain compatible with the older specification, but any fresh deployment guidance built for the DMARCbis era should assume the finer-grained ramp is going away.

Where mail flow actually breaks during enforcement

Breakage almost never comes from the primary mail server. It comes from the long tail of authorized senders that were never inventoried, and from alignment mismatches that quarantine reports never surfaced because quarantine and spam-folder delivery look identical to an end user who never checks.

The practical difference between the three classic policy states is worth keeping in front of a client during the whole engagement:

A domain owner moving straight from none to reject skips the validation step entirely, which is why dmarcian's guidance on advancing DMARC policy treats the sequence of none, quarantine, then reject as the traditional and safer path, reserving a direct jump to reject for parked domains that send no legitimate mail at all.

How long should the monitor-to-reject rollout take?

There is no fixed timeline that fits every client, but the pace should be set by the aggregate report data, not the calendar. A domain is ready to advance only once several consecutive reporting cycles show zero unexplained authentication failures from senders the MSP has already vetted.

For a typical small or mid-sized business tenant with a handful of third-party senders, that usually means somewhere between four and twelve weeks at p=none, followed by a similar validation window at quarantine before reject goes live. Domains with complex sending ecosystems, franchise structures, or many marketing tools attached often need longer, and rushing that phase is what produces support tickets during the reject rollout rather than before it.

External pressure has compressed some of that patience. Google's email sender guidelines have required senders of 5,000 or more daily messages to Gmail addresses to authenticate with SPF, DKIM, and DMARC since February 2024, and enforcement of those bulk sender rules has continued to tighten through 2025. Yahoo published nearly identical standards on its own Sender Hub, meaning any client sending newsletters, invoices, or notifications at scale is already operating under a de facto deadline set by the mailbox providers rather than by internal IT policy.

Federal agencies have lived under a stricter version of that deadline for years. The Department of Homeland Security's Binding Operational Directive 18-01 required all federal executive branch agencies to reach p=reject within one year of the directive's issuance, a timeline far more aggressive than what most commercial MSP clients need, but useful as evidence that reject-level enforcement is achievable on a fixed schedule when the inventory work is done properly up front.

Building the pre-flight checklist

Before advancing any client past p=none, the sender inventory needs to be genuinely complete rather than assumed complete. A short but disciplined checklist catches most of the gaps that would otherwise surface as bounced mail:

• Pull at least three full reporting cycles of aggregate data and cross-reference every sending IP against a known list of authorized platforms.
• Confirm SPF alignment for each third-party sender, adding includes or restructuring to stay under the ten-lookup limit rather than nesting redundant records.
• Verify DKIM signing is active and using aligned selectors for every platform that claims to send on the domain's behalf, not just the primary mail server.
• Check that subdomains used for marketing or transactional mail have their own policy tags rather than inheriting a default that was never reviewed.
• Document any sender that cannot meet alignment, and isolate it on a dedicated subdomain with its own policy rather than letting it block the parent domain's enforcement.

Working through that list manually across dozens of client domains is where the rollout usually slows down for MSPs managing more than a handful of tenants. Structured tracking of report data, alignment status, and policy stage across every domain in a book of business is exactly the workflow ActiScan's domain-security scanning was built to support, and the platform's getting-started guide walks through connecting the first domain and reading the first aggregate report cycle.

Making enforcement operational, not just technical

The technical mechanics of DMARC have not changed in any way that undermines a careful rollout, but the tooling around it keeps evolving, from the DMARCbis tag changes to the mailbox providers' own enforcement ramps. What has stayed constant is the discipline required: inventory before policy, validation before enforcement, and reports read on a schedule rather than checked once and forgotten.

For MSPs standardizing this process across a client base, the economics tend to favor a platform that tracks every domain's stage, flags senders that would break under stricter enforcement, and surfaces the aggregate report data without requiring someone to parse raw XML by hand. ActiScan's pricing is structured around the number of monitored domains precisely because the monitor-to-reject work scales with the client list, not with any single technical step. Firms ready to move a backlog of p=none domains toward real enforcement can start a trial and begin building the sender inventory that makes the eventual jump to reject uneventful rather than eventful.

DMARC enforcement done well is boring, in the best sense. Mail flows the same way it did the day before, except now the domain is no longer a usable spoofing target. Getting there without breaking anything is less about the final policy tag and more about the months of inventory and validation that came before it.