DMARC Enforcement Migration: Lessons from Large-Scale Deployments

• July 2023
• Engineering Memo · External Release

Moving a sending domain from DMARC p=none (monitoring only) to p=quarantine or p=reject (enforcement) is one of the most impactful email security decisions an organisation can make — and one of the most commonly executed incorrectly. The mistake that causes disruption: escalating DMARC policy before confirming that all legitimate sending sources are correctly authenticated and aligned. The result of this mistake is immediate: legitimate emails from services the organisation uses — CRM platforms, marketing automation, customer support tools — begin failing DMARC and are quarantined or rejected by receiving ISPs.

This note documents the correct enforcement migration process, with specific attention to the steps that most organisations skip and the specific failure modes that result from skipping them.

Why p=none Alone Is Insufficient

DMARC at p=none provides one significant benefit: visibility into which sources are sending email using the domain in the From: address, through aggregate reports (RUA) and forensic reports (RUF). This visibility is genuinely valuable — it reveals shadow IT sending sources, spoofing attempts, and authentication configuration gaps that are invisible without DMARC reporting.

But p=none provides no protection. An attacker spoofing the organisation's domain in phishing emails — sending as ceo@yourcompany.com to trick recipients into clicking malicious links — is not blocked by a p=none policy. The receiving ISP evaluates DMARC, sees the authentication failure, sees the p=none policy, and delivers the phishing email to the recipient anyway. The organisation sees the spoofing in their DMARC aggregate reports but cannot prevent it from reaching recipients. p=none is a data collection mechanism, not a protection mechanism.

The protection comes at p=quarantine (ISPs place DMARC-failing mail in spam) and p=reject (ISPs reject DMARC-failing mail outright). ISPs including Gmail treat a published DMARC record as a baseline trust signal — it demonstrates that the domain owner has established authentication monitoring infrastructure. However, the deliverability benefit is only fully realised at enforcement levels. Programmes that remain at p=none indefinitely collect data without acting on it, and leave their domain's brand reputation unprotected against spoofing.

Step 1: Deploying the DMARC Record Correctly

The initial DMARC record at p=none requires only three elements: the version (v=DMARC1), the policy (p=none), and the aggregate report address (rua=mailto:dmarc-reports@yourdomain.com or a dedicated DMARC reporting service address). The forensic report address (ruf=) is optional — forensic reports include message content and may have privacy implications; many organisations receive only aggregate reports initially and add forensic reporting after reviewing their privacy policy implications.

The DNS TXT record format: _dmarc.yourdomain.com IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com". The record goes at the _dmarc subdomain of the sending domain — not at the domain itself. Verify the record is correctly published by querying it: dig TXT _dmarc.yourdomain.com. The response should show the DMARC record. If no response or a different record appears, DNS propagation may not be complete — wait 24 hours and verify again before relying on DMARC reports arriving.

The aggregate report address should be monitored actively from the day of DMARC deployment. Reports begin arriving within 24–48 hours from major ISPs that process DMARC. Set up the RUA address as a monitored mailbox (not an unmonitored shared inbox where reports accumulate unread) and commit to reviewing reports weekly for the first 6 weeks of the monitoring phase. This is when the most actionable data appears — new sending sources, authentication failures, and alignment gaps that would have been unknown without DMARC monitoring.

Step 2: Analysing Aggregate Reports — Finding All Sending Sources

DMARC aggregate reports reveal every IP address that sent email using the domain in the From: address during the reporting period. This includes all expected sources (the primary MTA, email marketing platforms, CRM systems) and potentially unexpected sources (third-party services that send on behalf of the domain, spoofing sources, and misconfigured systems that are using the domain without authorisation).

The analysis process: parse all aggregate reports for the reporting period (most DMARC monitoring services do this automatically and present results in a filterable interface); list every distinct source IP address that appeared; categorise each IP as owned infrastructure, authorised third-party service, or unidentified; for each authorised third-party service, note whether it is passing DKIM alignment, SPF alignment, or both. Sources that are passing both DKIM and SPF alignment are already correctly authenticated and can proceed to enforcement. Sources that are passing only SPF or only DKIM need to be configured to pass the other (or at least one is sufficient for DMARC compliance, but dual-authentication is more robust). Sources that are failing both require investigation and remediation before enforcement.

The categories of sources found in DMARC reports that require specific handling:

Legitimate sources failing authentication: a CRM system, billing platform, or customer support tool that is sending transactional emails from your domain but not using DKIM signing aligned to your domain. These require configuration changes at the third-party service — enabling DKIM signing with a key published under your domain, or configuring the service's sending to use your domain's DKIM selector. Most modern SaaS email platforms support CNAME-delegated DKIM that allows you to publish a key for their signing infrastructure under your domain's DNS.

Forwarding sources: email addresses forwarded through third-party services (Google Workspace aliases, email forwarding services) that appear as source IPs from the forwarding service's infrastructure. These sources fail DMARC by design — forwarding typically breaks both SPF and DKIM alignment. ARC (Authenticated Received Chain) is the mechanism designed to preserve authentication state through forwarding, but is not universally implemented. Forwarding-related DMARC failures cannot be remediated at the sending side; they are expected and should be classified as known exceptions in the report analysis.

Spoofing sources: IP addresses that are not associated with any service the organisation uses, sending email that claims to be from the domain. These are the threat actors that DMARC enforcement blocks. At p=none, they deliver successfully; at p=reject, they are blocked. Identifying them in aggregate reports confirms the case for enforcement: the spoofing volume makes enforcement valuable, and the source characterisation confirms these are genuinely malicious rather than legitimate sources with authentication problems.

Step 3: Authenticating All Legitimate Sources

This step is the most time-consuming in the migration process and the one where most organisations are tempted to shortcut. Each legitimate source that is failing DMARC must be configured to pass DMARC alignment — either through DKIM alignment (the source signs messages with a key published under the sending domain) or SPF alignment (the source's sending IPs are listed in the SPF record and the MAIL FROM domain matches the From: domain).

DKIM alignment is the preferred method for third-party services: it is not affected by forwarding, and it does not require IP-address-based SPF management that needs updating whenever the service changes its infrastructure. Most modern SaaS email platforms (Salesforce, HubSpot, Zendesk, Intercom, and many others) support CNAME-delegated DKIM — they provide a CNAME record that you publish in your DNS, which allows their signing infrastructure to sign messages with a key that is attributed to your domain. Once the CNAME is published and the service is configured to use it, messages from that service pass DKIM alignment under your domain.

The authentication work should be tracked in a spreadsheet: one row per identified sending source, columns for the source name, the authentication methods currently passing, the required configuration change, the person responsible for making the change, and the date the change is confirmed complete and verified in DMARC reports. This tracking document is the accountability mechanism that ensures all sources are addressed before enforcement begins.

Step 4: Verifying Alignment and Escalating Policy

Before escalating to p=quarantine, verify in DMARC aggregate reports that the overall DMARC pass rate has reached at least 99%. The remaining 1% should be attributable to known exceptions (forwarding sources, ARC-unaware systems) rather than to legitimate sending sources with authentication gaps. If any identifiable sending source is still appearing with failure status, resolve the authentication issue for that source before escalating.

Escalate to p=quarantine first — not directly to p=reject. p=quarantine allows monitoring of enforcement impact (are any legitimate messages appearing in spam folders at major ISPs?) before the irreversible step of rejection. Run p=quarantine for 2–4 weeks, monitor DMARC aggregate reports for any unexpected failures from new sources, and verify with test recipients at major ISPs that legitimate sends from all configured sources are still reaching the inbox. After confirming no unexpected quarantine impact, escalate to p=reject.

Once at p=reject, continue monitoring DMARC aggregate reports. New sending sources that are added after enforcement (a new tool, a new integration, a new third-party service) will immediately fail DMARC and their mail will be rejected by ISPs that enforce DMARC. The monitoring that catches these new sources early — ideally within 48 hours of first send — allows the authentication configuration to be added quickly before significant mail volume is rejected. This is the operational maintenance requirement of DMARC enforcement: it is not a one-time configuration but a continuous monitoring practice that catches authentication gaps as the organisation's sending infrastructure evolves.

The Subdomain Policy: sp= and What It Covers

The DMARC record's sp= tag sets the policy for subdomains of the protected domain. If sp= is not explicitly set, subdomains inherit the parent domain's p= policy. This matters because many organisations use subdomains as sending domains: marketing emails from newsletter.yourdomain.com, transactional emails from mail.yourdomain.com, customer service from support.yourdomain.com. Each of these subdomains must independently pass DMARC alignment — being a subdomain of a DMARC-protected parent domain does not automatically provide authentication for the subdomain's sends.

The sp= tag can be set independently from p=. A common approach: set p=reject on the parent domain (protecting against spoofing of the primary organisational domain) and sp=quarantine on subdomains (more conservative enforcement while subdomain authentication is still being verified). This allows enforcement on the primary domain while maintaining monitoring visibility for subdomains that may have more complex authentication situations.

Subdomains that are actively used for sending must have their own DMARC records (at _dmarc.subdomain.yourdomain.com) if they need a policy different from the parent domain's sp= setting. A _dmarc record at a subdomain takes precedence over the parent domain's sp= setting for that subdomain. This allows per-subdomain policy customisation while maintaining the parent domain's protection.

The pct= Tag: Graduated Enforcement

DMARC's pct= (percentage) tag specifies what percentage of messages that fail DMARC should have the policy applied to them. pct=100 (the default) applies the policy to all failing messages. pct=10 applies the policy to only 10% of failing messages, allowing the operator to test enforcement impact at reduced scale before full deployment.

The graduated pct= approach provides a rollout mechanism for p=quarantine and p=reject that reduces the risk of unexpected legitimate mail disruption. Starting with pct=10 at p=quarantine, reviewing for 1 week, increasing to pct=25, then pct=50, then pct=100 over 4 weeks provides a gradual confirmation that the quarantine is affecting only the expected sources (spoofing and forwarding) without unexpectedly affecting legitimate mail. This approach is particularly valuable for large organisations with complex sending ecosystems where all authentication sources may not have been fully identified during the monitoring phase.

The limitation of pct=: it is applied randomly to the specified percentage of failing messages, not selectively. A legitimate source that is failing DMARC will have pct= applied to some of its messages and not others — producing inconsistent delivery behaviour that can be confusing to diagnose. This reinforces the recommendation to resolve all authentication issues for legitimate sources before escalating to enforcement, rather than relying on pct= to soften the impact of enforcement on sources that are not yet authenticated.

Large-Scale Deployment Lessons

Organisations that have successfully migrated to p=reject across large, complex sending ecosystems share consistent lessons about what made the migration work. The most universally cited: starting earlier than seemed necessary. A DMARC migration that is straightforward for a small organisation with a single email platform becomes a multi-month cross-functional project for a large organisation with 30 integrated SaaS tools, multiple email marketing platforms, and legacy systems that were configured without authentication considerations. The organisations that succeeded gave themselves 6–9 months from p=none deployment to p=reject escalation; those that tried to compress the timeline into 2–3 months encountered the unexpected authentication gaps at p=quarantine that forced retreats to p=none for emergency remediation.

A second consistent lesson: assigning clear ownership for each sending source's authentication configuration. When authentication configuration for a third-party service is "someone's job" without being a specific person's job with a deadline, it does not get done. The tracking spreadsheet described in Step 3 is only valuable if each row has a named owner who is accountable for completing the configuration by a specific date and confirming completion. Without this accountability mechanism, the migration stalls at the source authentication step — sometimes indefinitely.

Third lesson: the importance of DMARC monitoring service investment. Manually parsing XML aggregate reports is tedious and error-prone. Organisations that invested in a DMARC monitoring service (dmarcian, Valimail, Proofpoint DMARC, or similar) in the p=none phase completed source identification more thoroughly and faster than those who attempted manual parsing. The monitoring service also provides the historical trend data that confirms authentication improvement across sources over time — the visual proof that the migration is progressing and the specific metrics that confirm readiness for policy escalation.

The fourth lesson, and perhaps the most operationally important: enforcement is not the endpoint. The organisations that successfully maintain p=reject over multi-year periods treat DMARC monitoring as a permanent operational practice, not a migration project that ends at p=reject. New sending sources are identified within 48 hours of their first send; authentication is configured within the first campaign cycle; and the DMARC pass rate is tracked weekly as a key authentication health metric. This operational permanence is what makes p=reject durable — without it, authentication drift gradually re-introduces sources that fail DMARC, and the protection that enforcement provides is progressively eroded.

DMARC Enforcement and Deliverability: The Reputation Benefit

Beyond the security benefit of blocking domain spoofing, DMARC enforcement at p=quarantine or p=reject contributes positively to the sending domain reputation at ISPs that use DMARC policy as a trust signal. A domain with p=reject DMARC demonstrates that the domain owner has taken deliberate steps to authenticate all legitimate sending sources and explicitly reject unauthenticated traffic. This is a quality signal that distinguishes the domain from the large population of domains that remain at p=none indefinitely — indicating either that the sender has not invested in authentication infrastructure, or that they have authentication gaps they are unable to resolve.

The reputation benefit is not immediate — DMARC enforcement does not instantly improve inbox placement the day the policy is escalated. It contributes to long-term reputation trajectory through a combination of effects: the blocking of spoofing traffic reduces the overall complaint signals attributed to the domain (spoofed phishing emails generate complaints from recipients who believe they came from the legitimate sender), and the explicit enforcement policy signals authentication maturity to ISP trust evaluators. These effects compound over months rather than appearing immediately after enforcement.

The practical advice from operators who have tracked this transition: measure domain reputation via Postmaster Tools for 6 months before and after enforcement escalation. Most programmes that complete the migration correctly see stable or improving domain reputation in the months after escalation, while programmes that escalated before completing source authentication see the disruption of legitimate mail that momentarily affects reputation. The migration quality determines the outcome — a well-executed migration to p=reject produces a net-positive reputation trajectory; a poorly executed one produces temporary disruption that takes additional months of clean operation to recover from.

Technical Notes: BIMI and DMARC p=reject

BIMI (Brand Indicators for Message Identification) is an emerging email standard that allows organisations to display their brand logo in email clients that support it — Gmail, Yahoo, and Apple Mail being the primary consumer-facing adopters as of 2025–2026. BIMI requires p=quarantine or p=reject DMARC as a prerequisite — domains at p=none are not eligible for BIMI logo display. For organisations whose brand logo visibility in inbox interfaces is a marketing priority, the DMARC enforcement requirement creates an additional business case for completing the enforcement migration.

BIMI also requires a Verified Mark Certificate (VMC) issued by a BIMI-approved Certificate Authority. The VMC verifies that the organisation claiming the brand logo is the legitimate trademark holder. The cost and process of obtaining a VMC adds a step beyond the DMARC enforcement migration itself, but both steps are dependencies for full BIMI logo display at Gmail. Organisations planning a BIMI implementation should complete the DMARC migration first, confirm the p=reject policy is stable and all legitimate sources are authenticated, and then pursue VMC issuance. Attempting VMC issuance before DMARC enforcement is stable produces a BIMI logo display that is immediately revoked when the VMC CA's ongoing DMARC monitoring detects policy changes or authentication failures.

The combination of DMARC p=reject, strong DKIM authentication, and BIMI logo display represents the current ceiling of email authentication implementation for consumer-facing brands. It is achievable for most organisations within 6–12 months of committed effort, provides measurable brand trust and deliverability benefits, and protects against the domain spoofing that is the foundation of most phishing campaigns targeting the organisation's customers. The path from p=none to full BIMI-capable p=reject is a multi-step process, but each step provides standalone value — there is no step in the migration that creates risk without also creating benefit, provided the sequencing described in this note is followed correctly.

DMARC enforcement migration is a project, not a configuration change. It requires time (a minimum of 3 months for simple environments, 6–9 months for complex ones), cross-functional coordination (multiple teams own the sending sources that must be authenticated), and ongoing operational commitment after enforcement (monitoring new sources, maintaining authentication coverage). Organisations that approach it as a project with defined phases, clear ownership, and realistic timelines consistently succeed. Those that treat it as a DNS record change that can be done in an afternoon consistently encounter the authentication failures that force emergency retreats from enforcement and extend the migration timeline by months. The correct approach is slower and more deliberate — and consistently produces better outcomes.