Why DMARC Deployment Fails: What Most Guides Don't Prepare MSPs For

1. Getting stuck at p=none indefinitely

The most common DMARC failure isn't a technical problem — it's inaction. An MSP publishes a p=none record for a client, gets a few aggregate reports, and then never advances the policy. Months pass. Years pass. The domain is still wide open to spoofing.

This happens because p=none requires active work to interpret. If you don't have a tool that parses the XML reports automatically and gives you actionable data, reviewing them is tedious enough to keep getting deprioritised.

Fix

Use a platform that parses reports automatically, shows you sender-by-sender pass/fail rates, and prompts you when the data supports advancing the policy. The goal of p=none is to collect data — it should have a defined timeline, not be a permanent state.

2. Email forwarding breaking DMARC alignment

Email forwarding is one of the most common sources of legitimate DMARC failures, and it surprises even experienced practitioners.

When an email is forwarded from one server to another, the original SPF authentication fails — because the forwarding server's IP isn't in the original sender's SPF record. If DKIM is also missing or stripped, the email fails DMARC alignment even though it's entirely legitimate.

Common forwarding scenarios that cause this:

Clients with email aliases at a previous domain that forward to their current inbox
Mailing list software that doesn't preserve DKIM signatures
CRM or ticketing systems that relay inbound email
University or alumni email addresses that forward to personal accounts

Fix

During the p=none phase, specifically look for high-volume failure sources that correlate with known forwarding scenarios. Don't advance to p=quarantine until you understand every significant failure source — legitimate or otherwise.

3. Shadow senders you didn't know existed

Most clients have more email-sending services than anyone in the organisation can name from memory. Their DMARC aggregate reports usually reveal at least 2–3 senders that aren't in the original sender inventory:

An old marketing automation tool they forgot to cancel
A transactional email integration added by a developer without telling IT
A CRM or ERP system that was recently migrated but the old instance is still sending
A monitoring or alerting tool that sends email reports with the company domain in the From: header

If you advance to p=quarantine with unidentified senders in your reports, some of those emails will start landing in spam — and you'll find out from a client phone call, not a dashboard.

Fix

Don't treat the p=none monitoring phase as passive waiting. Actively review the sender list weekly. For any source you can't identify, cross-reference the IP with its ASN — most DMARC tools show this. An unknown IP resolving to Mailchimp's ASN is almost certainly a forgotten marketing list.

4. SPF hitting the 10 DNS lookup limit

SPF records have a hard limit of 10 DNS lookups during evaluation. This limit is hit more often than you'd expect once a client has several email-sending services — each service adds its own include: mechanisms which cascade into additional lookups.

When SPF exceeds 10 lookups, the SPF check returns a PermError result, which behaves like a failure for DMARC purposes. The client's legitimate email starts failing DMARC alignment through no fault of the sending service.

Fix

Audit the SPF record before deploying DMARC. Count the lookup chain — every include:, a:, and mx: mechanism counts, plus their nested includes. If you're close to 10, consolidate using SPF flattening tools or switch to a service with dynamic SPF.

5. Subdomain gaps in policy coverage

A DMARC policy published on company.com does not automatically apply to mail.company.com, billing.company.com, or any other subdomain — unless you explicitly define an sp= tag or publish separate DMARC records on each subdomain.

Additionally, many clients have dormant subdomains — old marketing microsites, retired product pages, deprecated app subdomains — that are perfect targets for spoofing attacks because no one is monitoring them.

Fix

During your initial audit, enumerate all subdomains. For subdomains that don't send email, publish a restrictive record: v=DMARC1; p=reject; sp=reject; — this prevents spoofing from inactive subdomains with no risk of breaking legitimate mail.

6. Third-party senders that can't support DKIM

Some older software — enterprise applications, legacy CRMs, on-premises systems — sends email in a way that doesn't support DKIM signing on your client's domain. This isn't always fixable: the vendor genuinely doesn't support it, or the system is too old to update.

If these systems send significant volume, blocking them at p=reject would break real business processes.

Fix

Assign these senders a dedicated subdomain (e.g., notifications.company.com). Configure SPF on that subdomain to authorise the sender's IPs. Publish a DMARC record on the subdomain at the appropriate policy level. The root domain can be at p=reject; the subdomain handles the legacy traffic without affecting the root domain's protection.

7. No rollback plan when enforcement breaks something

The most operationally painful DMARC failure: you advance a client to p=quarantine or p=reject, a legitimate email stream starts failing, and the client's sales team is calling because their CRM notifications are going to spam.

This can happen even with a thorough p=none phase — a new sender was added the week before you advanced, or a vendor changed their sending infrastructure without notice.

Fix

Before any policy advancement, document the exact current DMARC record as a text string you can paste back immediately. Confirm the DNS TTL and that you have credentials to change the record within minutes, not hours. The rollback process should be fast enough that no one has time to escalate.

8. Policy drift after enforcement is achieved

Getting a client to p=reject is not a one-time achievement — it requires maintenance. Common ways DMARC breaks after enforcement:

A developer changes the DMARC record "temporarily" and never reverts it
A domain migration changes the DNS zone and the DMARC record doesn't transfer correctly
A client adds a new email-sending service without telling the MSP — the new sender fails alignment and triggers quarantine
An SPF record is updated for a different purpose and accidentally pushes over the 10-lookup limit

Fix

Monitor DNS records continuously with alerts on any change. When the DMARC record changes, you should know immediately — not when a client calls about missing email. Domain monitoring is standard infrastructure oversight, not a DMARC-specific feature.

The common thread

Most DMARC deployment failures come down to two things: insufficient monitoring during the p=none phase, and no ongoing oversight after enforcement. A good DMARC platform eliminates the first by parsing reports automatically. Domain monitoring eliminates the second by alerting on any DNS change. The combination means you can advance policy confidently and maintain it without constant manual checking.