The DMARC Deployment Checklist

Why a Checklist, Not Just a Guide

Guides explain concepts; checklists ensure nothing gets skipped under time pressure. A DMARC rollout has enough independently moving pieces — SPF, DKIM, multiple sending sources, staged policy changes, stakeholder communication — that a concrete, ordered list of concrete completion criteria is worth more than another conceptual explanation of why staging matters. This checklist assumes you already understand the why, covered in the companion guides linked throughout, and focuses purely on the what and when.

Phase 1: Prerequisites

Phase 2: Monitor-Only Deployment

Phase 3: Staged Enforcement

Phase 4: Full Enforcement

Phase 5: Ongoing Maintenance

Detailed Sub-Checklist: The Inventory Step

Assigning explicit owners to each inventory sub-item, rather than leaving the entire inventory as one undifferentiated task for whoever's running the DMARC project, meaningfully increases the odds of actually catching every source before enforcement begins.

Detailed Sub-Checklist: Verifying Readiness for Each Enforcement Increase

What "Done" Looks Like at the End of This Checklist

A completed DMARC deployment, by this checklist's standard, means: p=reject is live and stable, every known sending source passes alignment consistently, subdomain policy has been deliberately reviewed rather than left to unconsidered default inheritance, ongoing report review is scheduled as a recurring task rather than having quietly stopped once enforcement was reached, and the process for onboarding a new sending source going forward is documented and understood by whoever will need to follow it next. This is a meaningfully higher bar than simply "a DMARC record exists" — it's a durable, maintained authentication posture rather than a one-time configuration change.

Using This Checklist as a Template for Future Domains

Once one domain has been through this full process successfully, the checklist itself becomes a reusable asset for any additional domain the organization later needs to onboard — a newly registered brand domain, an acquired company's domain, or a domain previously overlooked. The specific inventory findings won't transfer directly since each domain's sending sources may differ, but the phase structure, sub-checklist items, and realistic timeline expectations carry over directly, meaningfully shortening the learning curve for each subsequent domain compared to the first one.

Keeping the Checklist Itself Up to Date

As your own organization's email infrastructure evolves, this checklist should evolve with it — adding sub-items relevant to tools or processes specific to your environment, removing ones that no longer apply. Treating it as a living document owned by whoever manages email authentication, rather than a static reference followed once and then forgotten, keeps it useful for the ongoing maintenance phase and for any future domain that goes through the same process.

A Final Pre-Launch Sanity Check

Immediately before publishing any policy change, however small, run through one last quick pass: does the record's syntax validate cleanly, does the rua= address actually reach a mailbox someone monitors, has the change been communicated to anyone who needs to know, and is the rollback plan still accurate and ready if needed. This takes minutes and catches the specific category of error that comes from being deep in a multi-week process and losing track of a small but consequential detail along the way.

Related Reading in This Series

For the reasoning behind each phase, see Create a DMARC Record. For grounded recommendations on specific tag choices, read DMARC Best Practices. For full tag syntax reference, see DMARC Tags Explained. To build and verify records at each phase, use DMARC Record Generator and DMARC Lookup.