DMARC policy is a request to receivers: not a security score or a delivery guarantee
DMARC connects the domain visible in the From field with a passing, aligned SPF or DKIM identity. A policy of p=none asks for no special treatment of mail that fails DMARC. p=quarantine asks receivers to treat failures with suspicion, while p=reject asks them not to accept those failures. The current definition is RFC 9989. It supersedes the older DMARC document, so a runbook based on obsolete percentage sampling needs review.
The useful reframe is that enforcement does not repair authentication. It changes what a participating receiver is asked to do after evaluation. If an invoice service signs with its own unrelated domain and uses an unaligned return path, moving to reject can expose that design by blocking the message. The policy did not create the fault. It removed the previous tolerance.
Authentication also does not guarantee inbox placement. Receivers still consider permission, complaints, content, reputation and local policy. Define success narrowly: known legitimate routes pass aligned DMARC, unauthorised impersonation is subject to a stronger requested policy, and business-critical mail continues through the route people actually use.
Set entry conditions before changing DNS
Write down the domain, current DMARC record, DNS provider, accountable business owner and person authorised to roll back. Confirm that you can change the authoritative zone, not merely a stale copy in a hosting panel. Save the current TXT response from the authoritative nameservers and from an independent recursive resolver.
Build a route inventory that includes human mailboxes, marketing platforms, invoices, support tools, website forms, booking systems, scanners, monitoring alerts and low-frequency annual services. For each route, record the visible From domain, return-path domain, DKIM signing domain and selector, owner, expected volume and a recent test message. Reports are observations, not a complete asset register.
Do not proceed because a dashboard says “DMARC enabled”. Proceed when every critical route has an owner and recent evidence, unexplained high-volume sources have been investigated, report handling is stable, and a failed test has a named escalation contact. Stop if the zone owner is unknown, the existing record cannot be recovered, or a business-critical sender cannot be tested. Resolve those gaps before enforcement.
Every business that has lived through a bad DMARC change remembers the symptom: invoices or password messages start vanishing, and nobody notices until a customer complains. Setting hard entry conditions first: a named zone owner, a working rollback, every critical route tested: is what separates a controlled migration from an incident. It is the same preservation-first logic used throughout the DMARC setup guide.
If the monitoring record and sender map are not yet ready, begin with a controlled DMARC setup before planning enforcement.
Measure what your reports can and cannot see
Aggregate reports group authentication results by reporting organisation, source and policy evaluation. Google explains how its reports expose sending sources and authentication outcomes in its DMARC report guidance. Use several normal business cycles, including month-end billing and infrequent notifications. A quiet week does not cover a quarterly payroll run.
Create a coverage table with each inventory route down the left and reporting organisations or controlled test destinations across the top. Mark a route as observed only when the source, volume and identifiers make sense. Forwarding, shared infrastructure and provider IP changes can make source addresses alone misleading, so keep message-header samples beside report data.
Reporting is voluntary and can be delayed, incomplete or aggregated in ways that hide an individual message. Some small receivers send no report. A route can also be absent because nobody used it during the observation window. The trade-off is time: a longer observation period improves coverage but leaves spoofing at the weaker requested policy for longer. Use risk and business cycles to set the period, rather than adopting an arbitrary number of days.
Understanding what your reports can and cannot show is essential before you rely on them. A quiet week rarely covers a quarterly payroll run, and some receivers send nothing at all. Learning how to read DMARC reports properly tells you which routes are genuinely covered and which are still invisible to you.
Classify sources by identity and ownership
For each report row, ask four questions. Is the source authorised? Which visible From domain did it use? Did SPF pass with an aligned domain? Did DKIM pass with an aligned signing domain? Under RFC 9989, DMARC passes when at least one supported authentication path both passes and aligns. A bare SPF or DKIM pass against a provider-owned domain is not enough.
Use four practical categories: confirmed legitimate and aligned; confirmed legitimate but failing or unaligned; unauthorised or abusive; and unresolved. Do not authorise a source merely because its network name resembles a familiar supplier. Ask the service owner for account evidence and a same-route test. Conversely, do not block an unfamiliar source until finance, marketing and operations have checked it.
Prioritise legitimate failures by business harm, volume and ease of correction. A monthly payroll message deserves attention even if its report count is tiny. A noisy abandoned trial may be removable rather than repairable. Record that decision and disable the sender at its service as well as removing stale DNS authorisation. This prevents an old account from returning unnoticed.
When you group report rows into “confirmed legitimate”, “legitimate but failing”, “unauthorised” and “unresolved”, decisions stop being guesses. An unfamiliar source is not automatically an attacker, and a familiar network name is not automatically a supplier. Working from a maintained sender inventory gives you the ownership evidence these decisions need.
Repair the identity used by each legitimate route
Prefer a provider’s supported custom DKIM configuration where it signs with your domain or an aligned subdomain. Confirm the selector record in authoritative DNS, enable signing in the service, then inspect a newly delivered message. If SPF is the intended DMARC path, confirm the evaluated return-path domain is aligned with the visible From domain and that the sending host is authorised there.
DKIM often survives ordinary forwarding better than SPF, but message modification can break a signature. SPF can be useful for direct routes, yet forwarding commonly changes the connecting host. Keeping both healthy gives operational resilience without changing the rule that only one aligned path needs to pass DMARC. Do not add broad SPF includes as a substitute for understanding the route.
Test failure cases deliberately where safe: a plain message, an attachment, a template with tracking enabled, a forwarded copy and a reply from the actual workflow. If only some variants fail, stop and involve the provider before changing policy. Save the Authentication-Results field, DKIM signature identity, return path, timestamp and message event identifier with personal content redacted.
Choose the policy movement that matches your evidence, not the calendar
The usual policy movement is from none to quarantine and then reject, but it is not a calendar ritual. Quarantine provides a less final requested treatment while you confirm that failures are unwanted. Reject gives the clearest anti-spoofing outcome for failing mail. Either can still be applied differently under a receiver’s local policy, as DMARC expresses a domain owner preference rather than control over another system.
RFC 9989 removed the old pct tag. Do not publish p=reject; pct=10 believing the current standard limits enforcement to a tenth of failures. Review the current record syntax in the current DMARC specification. Use policy levels, separately governed subdomains and the specification’s current testing semantics only after confirming receiver support.
Subdomains require an explicit decision. The organisational-domain policy can affect them, while sp governs existing subdomains and np can express a policy for non-existent subdomains under the current specification. Inventory delegated and vendor-controlled subdomains before relying on inheritance. A separate subdomain policy can contain risk, but it also adds records and ownership that must be maintained.
Publish one controlled change with a rollback record
- Open the approved change record. Include current and proposed TXT values, affected domains, test routes, approver, time window and rollback authority.
- Validate the proposed syntax. Check that there is one DMARC policy record at the queried name, the version is first, reporting addresses are intentional and every tag is supported by RFC 9989.
- Lower uncertainty before impact. Correct known route failures and repeat real-message tests. Do not bundle an SPF rewrite, DKIM rotation and policy change into one event.
- Publish at the authoritative provider. Keep the previous value exactly as retrieved. Note the provider’s TTL and any change-audit identifier.
- Query the result. Ask authoritative nameservers and independent resolvers for
_dmarc.example.com TXT. Compare the returned string character for character with the approved value. - Run the route matrix. Send authorised tests through mailbox, campaign and transactional systems to controlled recipients, then retain headers and SMTP events.
If DNS answers disagree after the expected cache interval, stop additional policy work. Diagnose delegation, caching or split DNS rather than repeatedly editing the record.
Verify the real route, identity and message type: not just one test inbox
A successful test from an administrator’s mailbox says nothing about an invoicing platform. Verification must use the same service, account configuration, visible From domain, template path and relevant recipient type as production. Inspect the receiver’s Authentication-Results rather than trusting the sender interface. Record dmarc=pass and the aligned SPF or DKIM domain that produced it.
Check more than delivery to one inbox. Confirm the sending platform accepted the job, the receiving server accepted it, the message appeared where expected, links and replies still work, and unsubscribe handling remains intact for subscribed mail. Placement is a separate outcome and should not be attributed solely to DMARC.
Compare post-change aggregate data with the baseline by route and reporting organisation. Look for a fall in legitimate failures, a rise in policy actions against unauthorised sources and any previously unseen source. Google notes that aggregate XML can be viewed in a parser or service, but the underlying report remains the evidence described here. Export only the fields needed for analysis and restrict access because domains, IP addresses and counts can reveal suppliers and business activity.
Respond to failures without weakening the whole domain
If a legitimate message fails after the change, pause that sending route first. Preserve the bounce, header, report row and provider event. Determine whether failure came from DNS lookup, SPF authorisation, DKIM key retrieval, signature validation or alignment. Restoring the previous DMARC value may be justified for broad critical impact, but record who approved it and continue the investigation.
Do not immediately return the whole domain to none because one retired tool appears in reports. Nor should you exempt a route by moving it to a new domain without fixing ownership. The least disruptive correction may be provider-side custom DKIM, an aligned return path, a repaired key record, a disabled stale sender or a deliberately separated subdomain.
Stop rollout when any critical route lacks an aligned pass, an unexplained source could plausibly be legitimate, report coverage drops unexpectedly, DNS responses are inconsistent, or support cannot reproduce a failure. Escalate repeated signature changes, complex forwarding, delegated DNS uncertainty and public-suffix boundary questions to an email authentication specialist. Escalate business-risk decisions to the domain owner, not just the DNS operator.
Keep reject as an operated control
Reaching reject is not the end of ownership. Review reports on a proportionate rhythm, verify new services before launch, remove retired authorisations and test after provider or DNS migrations. Keep named owners for the record, reporting mailbox, parser account and emergency decision. Alerts without an owner merely defer the incident.
Define ordinary variation and alert thresholds. A single failed message from an obviously unauthorised source may need no intervention. A new aligned source, a sharp rise in legitimate failure, lost reporting, changed delegation or failure of a business-critical route does. Document which event pauses sending, which event triggers rollback consideration and who can approve either action.
Review access to aggregate data and delete exports when their operational retention period ends. Avoid placing full reports in broad support tickets. Finally, re-run the route matrix at least after a sender is added, a DKIM key changes, a domain is acquired or a report processor changes. Reject remains safe when the inventory and evidence stay current, not because the TXT record has remained untouched.
Reaching reject is the start of operating a control, not the end of the project. A provider or DNS change can break an aligned route you had forgotten about, which is why periodic blocklist and sending-health checks belong in the same rhythm as your report reviews.
Sources and further reading
- RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
- Google: About DMARC reports