DMARC Migration Guide

When migrating DMARC platforms, it is important that you understand the current configuration applied by the current DMARC platform. A properly planned migration ensures your email continues flowing smoothly while strengthening authentication and reporting. This guide walks through each phase of switching DMARC providers (and associated DNS-level configurations).

Overview

This guide covers the following:

• Planning and inventory
• Evaluation and preparation
• Parallel setup
• DNS update sequencing
• Testing and monitoring
• Cutover execution
• Post-migration review

Following this process ensures alignment with best practices and allows you to leverage automation tips to guarantee zero downtime, maintain deliverability, and maximize reporting and enforcement.

1. Planning and Inventory

This first phase ensures that you have a full understanding of each of the relevant areas of the current setup.

Inventory Domains and Records

Catalog every domain involved. For each domain, gather the following current DNS records:

DNS Record	Expected Record Type	How to Identify
DMARC	TXT or CNAME	Contains _dmarc in the hostname
SPF	TXT	Begins with v=spf1 in the value section
DKIM	TXT or CNAME	Contains _domainkey in the hostname
BIMI	TXT	Begins with v=BIMI1 in the value section
MTA-STS	TXT	Contains _mta-sts in the hostname
TLS-RPT	TXT	Contains _tls-rpt in the hostname

Document existing DMARC enforcement (p=none/quarantine/reject) and reporting addresses (rua/ruf). A complete inventory up front is critical – "create an inventory of the settings at your existing protection service first" before making changes.

For large environments, use scripting or DNS export tools to automate this data collection.

Identify Sending Sources

• List all mail senders (on-premises servers, cloud services, marketing platforms, etc.) and their current SPF includes or DKIM keys for each domain
• Check any subdomains or third-party delegations
• Validate your inventory by using existing DMARC reports or outbound email logs

Review Current Reporting Flows

• Note where DMARC aggregate/failure reports and TLS-RPT reports are sent (email addresses)
• Plan to maintain visibility by transitioning these to the new DMARC Manager platform
• DMARC records can list multiple reporting URIs (comma-separated) to simultaneously send data to both old and new systems

Set Baseline Performance

Before changes, record current email metrics (bounce rates, spam complaints, deliverability) and DMARC compliance levels. This lets you verify post-migration improvements and ensure no regressions.

2. Evaluation and Preparation

The evaluation and preparation phase ensures that you are prepared to rollback should it be required. For smaller environments, all of the below may not be necessary, so use your discretion.

Backup Existing DNS Records

• Export or save your zone files
• Retain copies of all current records for DMARC, SPF, DKIM selectors, MTA-STS, TLS-RPT, etc.

Catalogue New Target DNS Entries

Open DMARC Manager and capture the new target settings for each domain. Ensure that you have the new records required from DMARC manager for each domain (if covered in the legacy platform):

• DMARC
• SPF
• DKIM
• MTA-STS
• TLS-RPT
• BIMI

Example: An example of where to find the setup instructions for DMARC. The other settings can be found by simply switching to the relevant standards settings tab.

Stakeholder Roles

Assign responsibilities. Define who updates DNS, who configures the new DMARC Manager, who monitors the reports, and who handles rollback if something fails. For example, IT operations might handle DNS changes, while security teams review reports. Clear roles and communication channels are key.

Risk Assessment and Scheduling

• Identify risks (e.g., temporary misconfiguration causing bounces) and plan mitigation
• Consider migrating during low-traffic windows or in phases by domain group
• For large domain counts, batch the migration (e.g., 100 domains at a time) to limit impact

Prepare the New Environment

• Have your team familiarize themselves with the new platform's interface/API
• Collect any information needed (new public DKIM keys, SPF include values, reporting addresses, MTA-STS endpoints)
• Ensure you have access to DNS for the new DMARC Manager's records
• Note any required DNS CNAME or TXT entries provided

Lower DNS TTLs

• A few days before changes, reduce the TTLs on key records (DMARC, SPF, DKIM, MTA-STS, TLS-RPT) to something low (e.g., 300–3600 seconds)
• This minimizes propagation delays during cutover
• Remember to restore higher TTLs after stabilization

Role Delegation and Documentation

• Document every planned change and prepare step-by-step runbooks
• For each domain (or template of domains), note the exact DNS edits and sequence
• Maintain audit-ready change logs so you can demonstrate compliance and what changed when

3. Parallel Configuration

While the old DMARC platform remains active, configure the new DMARC Manager in parallel so that both systems receive or validate email simultaneously. This "dual-write" phase avoids downtime or blind spots, and is applied to all relevant DNS entries.

Add Domains to the New DMARC Manager

1. Add all new domains in the DMARC Manager
2. Verify DNS ownership as required (e.g., via DNS TXT or email)

DMARC Configuration

1. Set the initial DMARC policy of the newly added domain to the current, published policy
2. Add the old DMARC platform's reporting addresses in DMARC Manager
3. Configure under 'Edit Settings' in the Domains Interface:
   • Add RUA address to the Aggregate Reports section
   • Add RUF address to the Failure Reports section

SPF Configuration

1. Update each domain's SPF TXT record on DMARC Manager to the current published SPF record
2. Ensure all includes appear in DMARC Manager
3. Verify the 'all' tag is set to the same policy (typically ~all)
4. Do not remove the old SPF includes in the legacy DMARC platform yet

DKIM Configuration

1. Add the DKIM keys to the new DMARC Manager's DKIM key management
2. Do not remove the old DKIM records yet

BIMI Configuration

1. Copy the certificate files over to DMARC manager
2. Copy the image file over to DMARC manager (use exact SVG)
3. Do not remove the old BIMI records yet

MTA-STS Configuration

If using MTA-STS, ensure the new DMARC Manager's MTA-STS policy mirrors the old one.

4. Record Update Sequencing

Proper sequencing of DNS changes minimizes risk. Follow this order:

1. Lower TTLs (done in Preparation)
2. Replace existing SPF with new SPF:
   • Follow DMARC Manager instructions
   • Verify syntax and lookup limits
   • Wait for DNS propagation (minutes to an hour)
3. Publish new DKIM key management entries:
   • Add new DKIM management NS records
   • Keep old DKIM records active for rollback
4. Replace existing DMARC record:
   • Use DMARC Manager record
   • Verify syntax (one DMARC TXT/CNAME per domain)
5. Replace existing BIMI record:
   • Remove old BIMI record
   • Add new BIMI NS records
6. Update MTA-STS DNS Record
7. Update TLS-RPT DNS TXT
8. Validation pause (24–48 hours)
9. Optional enforcement adjustment

Verification Steps

At each step, verify email authentication:

• SPF: Check authentication using tools or test emails
• DKIM: Send test messages and validate headers
• DMARC: Confirm split reporting between vendors

5. Testing and Monitoring

DMARC Reports

• Confirm both services receive reports
• Compare sample reports
• Verify legitimate email sources

Authentication Testing

• Send test emails from each source
• Verify SPF=pass and DKIM=pass
• Investigate any failures

MTA-STS Verification

• Use online MTA-STS checkers
• Test external domain email
• Check Google Workspace admin console (if applicable)

TLS-RPT Review

• Review reports after a few days
• Address any issues
• Confirm new vendor receives reports

Deliverability Monitoring

• Watch bounce rates
• Monitor spam reports
• Track user complaints

6. Cutover Execution

Once verified, perform the final cutover:

1. Remove old DKIM keys (after 48–72 hours)
2. Clean up SPF includes
3. Finalize DMARC record:

   v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100

4. Update MTA-STS configuration
5. Remove old TLS-RPT URI
6. Decommission old vendor

Note: Perform removals during maintenance windows with backup plans ready.

7. Post-Migration Review

Validation Checklist

• [ ] All domains report to DMARC Manager
• [ ] Only DMARC Manager records remain
• [ ] Verify with dig or DNS management interface

Performance Review

• Monitor email rejection rates
• Check DMARC compliance
• Compare pre/post migration metrics

Documentation

• Compile audit logs
• Document DNS changes
• Record cutover dates
• Save confirmation messages

Policy Enhancement

• Plan enforcement increases
• Move towards p=reject
• Regular SPF reviews

Conclusion

By meticulously inventorying, preparing, and running systems in parallel, you ensure zero downtime during the switchover. Multi-recipient reporting keeps deliverability and visibility uninterrupted. Finally, cleaning up old records and tightening policies completes the migration, leaving you with stronger email authentication and comprehensive monitoring under DMARC Manager.