How to migrate from Valimail 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 generates the record to copy; take the rua address from it (Palisade docs).

When _dmarc is delegated to Valimail by NS or CNAME, the record is served from Valimail, so you cannot edit it at your DNS provider. Valimail's help center says the domain's configuration page in Enforce has a section for adding additional aggregate report (RUA) addresses (Valimail help center, checked 13 November 2026). Add Palisade's address there and leave everything else as it is.

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:dmarc_agg@vali.email,mailto:your-palisade-address@reports.example"

The Palisade address above is a placeholder. Copy the real one from the record Palisade generates.

Reports sent to an address on another domain need that domain's permission (RFC 9990, section 4). If no reports reach Palisade after two days, check 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 sender that Valimail authorizes through its SPF macro and that your new SPF record will need to name.
• Export or screenshot what you need from Valimail. Its offboarding guide asks you to capture every enabled service and netblock, for every domain and subdomain (Valimail help center).
• Leave the policy alone. If a policy change is due, make it before or after the move, not during it.

Step 4: Copy out what Valimail holds, then swap the records

Valimail's own offboarding guide gives the order: capture the enabled services, recreate the DKIM keys, publish an SPF record, then stop pointing DKIM and DMARC to Valimail. It warns that these DNS steps "must be performed in a timely manner or you could run the risk of deliverability issues" (Valimail help center). Keep Valimail active until each replacement resolves.

1. DKIM keys first. Copy every DKIM key you have configured in Valimail, for every domain and subdomain. If the new home is another provider's delegated zone, add each selector there first; Palisade's hosted DKIM is also a _domainkey NS delegation, so a move to Palisade works this way (Palisade hosted DKIM docs). Then switch the _domainkey NS record in one change. If the new home is your own zone, remove the NS record and add every selector in the same change: while _domainkey is delegated, selectors under it in your zone do not resolve, and some DNS hosts refuse to create them. No DNS query lists every selector, so check your list against the selectors in the aggregate reports you collected during the overlap. A missed selector fails DKIM for that sender.
2. SPF. Build a real SPF record from the services and netblocks you captured, or use the new provider's hosted SPF include, and check it stays under the 10-lookup limit. Then replace the Valimail macro record. Valimail notes that if the macro is removed and nothing else is in the record, SPF fails and DMARC can pass only on DKIM (Valimail help center). In Palisade, hosted SPF is a single include, and you copy every existing mechanism into it before you publish (Palisade hosted SPF docs).
3. DMARC. Copy the current policy exactly from dig +short TXT _dmarc.example.com. Then, in one change, remove the _dmarc NS record (or CNAME) and publish the new provider's hosted record or your own TXT record. A name delegated by NS cannot also hold records in your zone, so the two cannot overlap. 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, and a diff preview shows what changes before you apply it (Palisade hosted DMARC docs).
4. MTA-STS and TLS reporting. If Valimail hosts MTA-STS, repoint the mta-sts host first and wait until https://mta-sts.example.com/.well-known/mta-sts.txt serves the new policy with a valid certificate and the right mx lines. Then repoint _mta-sts, which changes the id (RFC 8461, section 8.1). Replace the _smtp._tls CNAME with 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.
5. BIMI. If your BIMI record loads its logo or certificate from amplify.valimail.com, as Valimail's own default._bimi record did when checked with dig on 13 November 2026, host both files at the new provider before you change default._bimi.
6. Verify, then cancel. Run the lookups from Step 1 again. When no NS, CNAME or SPF record points to vali.email and only the rua address remains, remove Valimail's address from rua and ruf, tell Valimail support the steps are done, and cancel on your schedule. If you want to keep the free Monitor product, the offboarding guide says to skip removing the DMARC delegation. To move DMARC anyway and keep Monitor, leave Valimail's rua address in the record you publish.

A switch from Valimail that stops halfway

One unfinished move is easy to miss: two addresses left in rua for months. Both tools keep receiving reports, the old contract renews, and nobody owns the last step because the new tool already looks like it works. If dig +short TXT _dmarc.example.com still shows vali.email next to your new provider long after the overlap, the switch did not finish. Either complete Step 4 or decide on purpose to keep Valimail as the second reader.

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 Valimail hosts: domains with a TXT record need only the rua edit, while domains with NS delegations need the DKIM and sender export first. Run the 30-day overlap for a whole group at once, and move the delegations group by group. Valimail's MSP products are sold per domain through Pax8 (Valimail MSP page), so check how each client's Pax8 subscription renews before you cancel.

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 Valimail and Palisade compare on price and MSP terms, see the Valimail alternative comparison. For what Valimail publishes about price and product, see Valimail pricing and the Valimail review.