Migrate from EasyDMARC without a reporting gap

Step 2: Add the second reporting address

The rua tag takes a comma-separated list of addresses (RFC 9989, section 4.7), so both tools can receive the same aggregate reports. In Palisade, the domain's Manage DMARC page shows the generated record to copy (Palisade docs).

When you manage the TXT record yourself, keep every tag and add the second address after the first:

_dmarc.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:abc123@rua.easydmarc.com,mailto:your-palisade-address@reports.example"

The addresses above are placeholders. Copy the real ones from each tool.

When _dmarc is a CNAME into EasyDMARC, the TXT record lives in EasyDMARC's zone, so you cannot edit it at your DNS provider. You have two options:

1. Add Palisade's address inside EasyDMARC. Its Managed DMARC page says you "Configure RUA, RUF, fo, ri from the same UI" as the rest of the record. EasyDMARC's help center describes the policy controls on the Managed DMARC page under Managed Solutions (EasyDMARC help).
2. Replace the CNAME with a TXT record you control. Copy the current policy exactly from dig +short TXT _dmarc.example.com, add the second address, delete the CNAME, and publish the TXT record in one change.

Reports sent to an address on another domain need that domain's permission (RFC 9990, section 4). EasyDMARC's Managed DMARC page makes the same point about external rua destinations. If no reports reach Palisade after two days, confirm the address was copied exactly, then contact Palisade support.

Step 3: Compare both tools for about 30 days

Aggregate reports usually arrive once a day from each mailbox provider, so a month gives you enough days to see every regular sender, including monthly billing and newsletter runs. During the overlap:

• Confirm both tools list the same sending sources and roughly the same message counts.
• Compare pass and fail rates for each sender. A large gap points to a parsing or identification difference worth understanding before you switch.
• Save any EasyDMARC history you need to keep, if your plan offers an export. Do not assume another tool can import it.
• Leave the policy alone. If a policy change is due, make it before or after the move, not during it.

Step 4: Swap the hosted records, then cancel

Move one hosted record at a time, starting with _dmarc, and keep EasyDMARC active until each replacement resolves.

1. DMARC. Replace the _dmarc CNAME with the new provider's hosted record or your own TXT record. Keep the same policy tags, including any pct: receivers that still honour pct will apply the policy to all mail if you drop it. In Palisade, hosted DMARC is a CNAME delegation, and a diff preview shows what changes before you apply it (Palisade hosted DMARC docs).
2. SPF. Replace the EasySPF include with the full list of senders it covered, or with the new provider's hosted SPF include. Check the result stays under the 10-lookup limit.
3. MTA-STS. Repoint the mta-sts host first. Wait until https://mta-sts.example.com/.well-known/mta-sts.txt serves the new policy with a valid certificate, and check its mx lines match your current MX records. Some hosts, Palisade included, only issue that certificate after the CNAME points to them. Then repoint _mta-sts, which changes the id. RFC 8461 asks for the HTTPS policy to be updated before the TXT record (RFC 8461, section 8.1).
4. BIMI. Set up the logo record at the new provider, then repoint the default._bimi CNAME in one change.
5. TLS reporting. Delete the _smtp._tls CNAME and publish the new provider's v=TLSRPTv1; rua=... TXT record in the same change. With Palisade, TLS reporting is a TXT record in your own zone, not a CNAME.
6. DKIM. If _domainkey is delegated to EasyDMARC, removing that NS record removes every selector under it at once. If the new home is another provider's delegated zone, publish each live selector there first, then switch the NS delegation in one change; Palisade's hosted DKIM is also a _domainkey NS delegation, so a move to Palisade works this way. If the new home is your own zone, remove the NS record and add each selector in the same change, recreated exactly as it is now (a TXT key, or a CNAME where the sender publishes its key that way). Keep EasyDMARC active until the old NS record's TTL has passed. No DNS query lists every selector, so build the list first from the DKIM selectors in the aggregate reports collected during the overlap, EasyDMARC's Managed DKIM selector list and each sender's setup docs. A missed selector fails DKIM for that sender (Palisade hosted DKIM docs).
7. Verify, then cancel. Run the lookups from Step 1 again. When nothing returns easydmarc.pro, remove EasyDMARC's addresses from rua and ruf and cancel on your schedule.

What changes for an MSP moving many client domains

The method is the same for every client domain, so an MSP can batch it. Group domains by what EasyDMARC hosts: domains with a TXT record you control need only the rua edit, while domains with a _dmarc CNAME need either the change inside EasyDMARC or a record swap. Run the 30-day overlap for a whole group at once, and move the hosted records group by group.

For the general provider-change checklist, including rollback records and change approvals, see the DMARC provider migration guide, and for DMARC basics the DMARC learning hub. For how EasyDMARC and Palisade compare on price and MSP terms, see the EasyDMARC alternative comparison. For what EasyDMARC charges and what changed in V3, see EasyDMARC pricing explained and the EasyDMARC review.

Related EasyDMARC guides

• EasyDMARC alternative for MSPs: Palisade compared
• EasyDMARC pricing: what the MSP and business plans publish
• EasyDMARC review: what V3 changed and who it fits
• DMARC reporting service: EasyDMARC vs PowerDMARC vs Palisade
• EasyDMARC vs dmarcian compared
• Valimail vs EasyDMARC compared