When DMARC Enforcement Breaks the Business: The Change Management Lessons of a p=reject Rollout

In mid-2025, we started seeing an unusual pattern in complaints from clients: their mail through marketing platforms, CRMs, and various SaaS tools was suddenly being rejected. The clients hadn't changed anything. After a few days of investigation, the cause was clear — they were all sending under a parent company's domain, and the parent company had moved DMARC from p=none to p=reject over a single weekend.

The parent's decision was correct on its merits. The domain had a high volume of spoofing activity. The legitimate sending sources were known to the parent's central IT team. Moving to enforcement was the right call. What broke wasn't the policy — it was the rollout. Subsidiaries operating under the parent's umbrella domain had built marketing operations on platforms the parent's central team didn't have visibility into. None of those platforms were authenticated. When the policy flipped, every one of them stopped working.

This post is about the change management discipline of DMARC enforcement — what tends to break, what to communicate to whom, and how to roll out the policy change in a way that doesn't create an operational crisis on the way to a more secure environment.

What Actually Broke

The parent company's domain was the shared root for dozens of business units, regional offices, and acquired subsidiaries. Each of those units had, over the years, signed up for various SaaS tools — marketing automation platforms, event registration systems, customer outreach tools, regional newsletters, partner-facing communication platforms — and configured the tools to send mail under the corporate domain. Some had gone through central IT for proper authentication setup. Many hadn't. The tools sent mail under the parent's domain via their own infrastructure, with the parent's domain in the visible From: field but no SPF authorization, no DKIM signing under the parent's domain, and therefore no DMARC alignment.

While the policy was p=none, all of this mail was delivered. Recipients received it, some of it landed in spam (because authentication was missing), but enough got through that the campaigns showed measurable engagement. The parent's DMARC reports showed a long tail of unauthenticated sources — which, in hindsight, was the warning that the move to enforcement would have consequences.

The day the policy flipped to p=reject, every one of those unauthenticated sources started being rejected. Marketing campaigns mid-flight stopped delivering. Event registration confirmations bounced. Regional newsletters didn't reach subscribers. Within 24 hours, subsidiaries had millions of dollars in active marketing spend tied to platforms that no longer produced delivered mail.

The fix was real, but slow: each affected business unit had to coordinate with central IT to either authenticate their sending platform properly (which most could do, given a few weeks), or migrate the affected mail to an authorized platform (which took longer). In the interim, business operations were materially impacted.

What Should Have Happened

The right rollout for an organization of that complexity is the standard DMARC enforcement playbook, paced over weeks and coordinated with stakeholders. Aaron Stevenson, Senior Manager of Professional Services EMEA at Proofpoint, put it well on our LinkedIn discussion of the case:

"Education around the fact that DMARC provides a fail-closed environment instead of a fail-open free for all can help, but only if it is listened to. The organisation needs executive sponsorship and buy in that going forward, any new systems need to be compliant, or they will be treated the same way as any other spoofing. Had this company fully grasped the reasons behind and working of DMARC, then the response to 'My emails were blocked' should have been 'Good!! Now go away and fix them before you try again.'"

That framing — fail-closed instead of fail-open — is the conceptual shift. In a fail-open environment, every team can sign up for any SaaS tool and start sending under the corporate domain, and central IT only learns about it if someone complains. In a fail-closed environment, every team that wants to send under the corporate domain must first get the sending platform properly authenticated. The friction is the feature: it ensures that central IT knows about every authorized sending source and that every source is configured securely.

The transition between those two states is where the change management work lives. You don't get to fail-closed by flipping a switch. You get there by:

1. Building the inventory. Six to eight weeks before the policy change, run aggregate DMARC reports at p=none and catalog every source. For each unauthenticated source, identify the business owner — the team that's actually using the platform. This is harder than it sounds in a decentralized organization. Some sources will trace back immediately. Others will require detective work.

2. Communicating the timeline. Department leaders, business application owners, mission-critical vendors, and marketing teams all need to know that authentication enforcement is coming. The communication should be specific: here's the date, here's what your team needs to do, here's who to contact for help, here's the consequence if you don't act. Generic security awareness blasts are not enough. Targeted, action-oriented communication to the people who own the affected systems is.

3. Defining the success criteria. A common pattern from Tucker Shepard, CISSP, who commented on the case: "Something such as 'when DMARC compliance percentage remains above 98% for 7 days we'll move to reject.'" This is the right structure. The trigger for the policy change is a measurable threshold on the report data, not a calendar date. If you hit the threshold a week early, move early. If you don't hit it by the planned date, slip the date.

4. Using the percentage tag for gradual rollout. DMARC supports a pct parameter that applies the policy to only a fraction of failing messages. Starting at pct=10 for p=quarantine, then ramping to 25, 50, 100 over the course of weeks, lets you discover failures at low blast radius. By the time you're at pct=100 for quarantine, the things that were going to break have broken at low volume and been fixed. Then p=reject is straightforward.

5. Running a quarantine phase, not just a reject phase. The discipline of running quarantine before reject is exactly what was skipped in the case study. Quarantine routes failing mail to spam folders instead of bouncing it. Users notice and report the problem, IT investigates, the authentication gap is identified and fixed. The mail wasn't great during this phase — landing in spam isn't useful for marketing campaigns — but the operational damage was contained. Moving directly from p=none to p=reject skips the discovery surface and lets failures land in production.

6. Communicating rollback criteria. If something breaks at scale that wasn't anticipated, what's the rollback plan? Typically: revert the policy to p=quarantine (or p=none in extreme cases), fix the issue, then re-advance. The team needs to know the rollback exists and what triggers it, so the response to a problem isn't "we can't fix this because the policy is now enforced."

The Sub-Organization Problem

The parent-company case study illustrates a specific structural problem: when a single domain is shared across multiple decentralized business units, DMARC enforcement at the apex affects every unit's mail flow. The enforcement decision belongs to the domain owner. The operational consequences belong to whoever was sending under that domain.

For organizations in this configuration — common in corporate groups with shared brand domains, acquired companies on legacy domains, and large enterprises with regional autonomy — the architectural fix is usually to give each business unit its own subdomain for sending, with its own SPF, DKIM, and DMARC. The apex is reserved for corporate communication that central IT directly manages, and the subdomains are governed by the units that use them.

This separation lets each unit move at its own pace. The marketing unit at marketing.example.com can be at p=reject while the regional unit at regional-eu.example.com is still authenticating their newer SaaS tools at p=quarantine. Both can converge to p=reject eventually, but they don't have to move in lockstep.

The transition to this architecture is itself a project — one that ideally precedes DMARC enforcement rather than being driven by an enforcement incident. The parent-company case study would have been much less painful if each business unit had a subdomain to begin with. They didn't, so enforcement at the apex hit everyone at once.

The Vendor Pushback

A predictable side effect of DMARC enforcement is that SaaS vendors who don't properly authenticate mail under your domain will tell you that your DMARC policy is the problem. We've covered this elsewhere in our work — the pattern of CRM and marketing platform providers advising clients to downgrade DMARC from p=reject back to p=none as a "solution" to deliverability problems. The advice is wrong on its merits and revealing about the vendor's own infrastructure: if a vendor cannot configure DKIM signing on the customer's domain or proper SPF authorization, they are operating below the table stakes of enterprise email infrastructure in 2026.

The right answer to a vendor request to downgrade DMARC is to ask the vendor to fix their authentication. If they can't, the deeper question is whether you want to continue using the vendor.

This conversation is often where the value of enforcement becomes concrete to the business. The CRO who didn't care about DMARC suddenly cares when their marketing platform's deliverability problem gets escalated. The CMO who didn't have visibility into which platforms were on the approved tech stack now has a reason to consolidate. Enforcement is, among other things, a forcing function for vendor accountability.

The Three Lessons

If we distilled the change management discipline of DMARC enforcement to three principles:

Inventory before enforcement. Every source in the aggregate reports has a business owner. Find them before the policy flips.

Communicate to the people who can act. Generic security communication doesn't change behavior. Specific, deadlined, owner-targeted communication does.

Run quarantine before reject. The quarantine phase is where failures surface at survivable volume. Skipping it is how organizations end up with the parent-company case study.

The endpoint — p=reject on every active domain, with every legitimate source properly authenticated — is the right one. The path there is the work that makes the destination achievable without breaking the business along the way.

---

Written by the team at SH Consulting. We handle DMARC enforcement end-to-end, including the change management work that makes the policy change uneventful instead of operationally disruptive. Book a call and we'll walk through your environment.