DMARC deployment checklist
Publish a DMARC record, review reports, and move to enforcement.
1. Make a list of legitimate senders
Start with the services your organisation actually uses: staff email, marketing platforms, support desks, invoices, website forms, and automated applications. Include less frequent systems such as monthly billing or annual notices.
For each sender, record the person responsible, the visible From domain, and where SPF and DKIM are configured. Include subdomains and domains that should never send email.
2. Check the existing DNS configuration
Review the current SPF and DMARC records before making changes. Do not publish a second SPF policy or a second DMARC record at the same name to add a new service. Update the appropriate existing configuration.
Enable DKIM in each sending service and publish the public DNS records that service provides. Keep private signing keys out of tickets, public tools, and DNS.
Send a real test message from each service. Confirm that its authentication results align with the visible From domain; a valid-looking DNS record alone is insufficient.
3. Set up a report destination
Choose a reporting service or a mailbox and parser you manage. Use the report address issued for your domain. If reports are sent to another organisation’s domain, external-destination authorisation may be required.
A basic monitoring record might look like this:
Name: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
This is an illustration, not a record to copy unchanged. Replace the domain and destination with a real, configured reporting address. Confirm how your DNS provider handles the record name; some interfaces append your domain automatically.
4. Observe and investigate
Allow enough time to see your normal sending cycle. A few quiet days may miss an important monthly process. Reports arrive according to receiver behaviour, so investigate missing coverage instead of assuming no reports means no problems.
Separate observations into known legitimate senders, services needing investigation, and unauthorised sources. Fix authentication and alignment for legitimate mail. Do not add an unfamiliar IP to SPF simply because it appears in a report.
5. Move toward enforcement
Use the evidence you have gathered to decide when to request quarantine and then rejection. Test important sending flows before each change and monitor both reports and delivery issues afterwards. Keep a documented rollback route for legitimate mail that unexpectedly breaks.
The 2026 DMARC specification removes the legacy pct tag. Do not rely on it as a universal rollout control. Plan changes using your domains, subdomains, sending inventory, and the capabilities of the systems involved.
6. Keep the deployment maintained
- Review new sending services before they go live.
- Retire unused SPF authorisations and obsolete keys deliberately.
- Monitor report delivery and authentication changes.
- Revisit policies for subdomains and non-sending domains.
- Give someone responsibility for investigating unexpected failures.
DMARC is an ongoing operational process. Choose a review cadence that fits your mail volume and the rate at which your systems change.
Sources
Sources reviewed .