Migrating from another DMARC provider

21 June 2026 · 14 min read

Switching DMARC providers feels riskier than it is, because the thing you are moving is not your mail, it is a set of DNS records and a reporting destination. Done in the wrong order, a migration can leave you with a window where neither the old provider nor the new one is collecting your aggregate reports, or worse, with two records fighting over the same hostname so that receivers ignore both. Done in the right order, the changeover is invisible: your policy stays exactly where it is, your mail keeps flowing, and the only difference is which platform parses the reports the world is already sending you.

This guide is the careful version. It assumes you currently use another DMARC monitoring or enforcement service (the usual names: Valimail, Dmarcian, Postmark, EasyDMARC, OnDMARC/Red Sift, PowerDMARC, Agari, or a self-hosted parser) and you want to move that work to DMARC Engine without a single day of lost coverage. We will export what you already have, line up the new configuration so it is ready before anything changes, re-point the rua reporting address, switch any delegated records over, and then verify, with evidence rather than hope, that nothing dropped through the gap. Throughout, the principle is the same: never lower your policy to migrate, and never change two things at once that you cannot independently roll back.

What actually moves, and what does not

It helps to be precise about the scope, because half the anxiety around a DMARC migration comes from imagining that mail itself is in play. It is not.

A DMARC provider does three things for you, and only the first is genuinely "yours" in DNS:

It receives your aggregate (RUA) reports, and sometimes failure (RUF) reports, at a mailbox the provider controls. Your DMARC record names that mailbox in its rua= tag. This is the part that points at the old provider today and must point at the new one tomorrow.
It parses those XML reports into a dashboard so you can see who is sending as your domain, whether they pass SPF and DKIM, and whether they align. This is entirely on the provider's side; nothing in your DNS references it.
It may host some of your records by delegation, typically the _dmarc TXT record itself, your SPF include, your MTA-STS policy, or your BIMI record, served through CNAMEs that point into the provider's zone so they can manage changes for you.

Items 1 and 3 are the only things published in your DNS, so they are the only things a migration touches. Your MX records do not change. Your mailbox provider (Google Workspace, Microsoft 365, Zoho, Fastmail, whatever you run) does not change. Your DKIM signing keys stay with whoever signs your mail, because DMARC Engine does not relay or sign your messages; we are a DNS and reporting service, not a mail gateway. If you want the longer version of why keeping your provider is the whole point, see /docs/keep-my-provider and the /products/dmarc overview.

The reporting data does not migrate either, in the literal sense. Aggregate reports are sent fresh by receivers every day; once your rua points at DMARC Engine, the next reporting cycle (usually within 24 hours) starts filling the new dashboard. Your old provider's historical charts stay with the old provider, which is exactly why the export step below matters.

Before you touch anything: export your current state

The single most common migration mistake is treating the old provider as if it will still be there next month. The moment you stop paying, the dashboard and its history usually vanish. Capture everything first, while you still have access.

Pull these from your existing provider and your live DNS:

Your current DMARC record, verbatim. Run dig +short TXT _dmarc.yourdomain.com (or nslookup -type=TXT _dmarc.yourdomain.com on Windows) and save the exact string. This is your source of truth for policy, alignment mode and reporting addresses. Do not trust the provider's "your record should be" suggestion; read what is actually published, because the two sometimes differ.
The policy and all tags. Note p=, any sp= subdomain policy, pct= if present, adkim=/aspf= alignment modes, fo= failure-reporting options, and every address in rua= and ruf=. If you are already at p=quarantine or p=reject, write that down in bold for yourself: you are migrating an enforced domain, and the rule is that the policy value does not change during the move.
Your verified, passing sending sources. Export or screenshot the list of legitimate senders the old dashboard shows passing alignment: your mailbox provider, your marketing platform, your CRM, your billing and ticketing systems. This becomes your acceptance checklist on the new side. You are not migrating to discover new problems; you are migrating to confirm the same green list reappears.
Any delegated records. Check whether your _dmarc, SPF, MTA-STS or BIMI records are CNAMEs pointing into the old provider's domain rather than plain TXT records you control. Run dig +short CNAME _dmarc.yourdomain.com, dig +short CNAME _mta-sts.yourdomain.com and dig +short TXT default._bimi.yourdomain.com. If any of these return a CNAME pointing at the old vendor, that record is theirs to serve and will need a deliberate cut-over, not just a rua swap.
A few raw aggregate reports. If the old provider lets you download the underlying XML, grab a week or two of it. You can feed these straight into our free DMARC report analyzer to keep eyes on your sending sources during the changeover, independent of either dashboard.

Save all of this somewhere outside the old provider's account. Once it is captured, you have removed the only irreversible risk in the whole exercise: losing visibility into what "normal" looks like for your domain.

Stage the new side before changing DNS

Set up DMARC Engine fully before you alter a single public record. Nothing you do in this stage is visible to the internet or to receivers, so there is no risk and no rush. The goal is to have the new platform completely ready, so that the actual cut-over is one small, reversible DNS edit.

In DMARC Engine, add the domain and let it read your existing published records. It will show you your current _dmarc record, your SPF chain, and the DKIM selectors it can find, and it will flag anything inconsistent. Because you are migrating rather than starting cold, you want the new configuration to mirror your current enforced state, not reset it. Confirm that:

The policy DMARC Engine is prepared to publish matches what you have live today. If you are at p=reject, you stay at p=reject. Migration is not a reason to revisit your enforcement journey; that comes later, if at all. For background on how the staged journey works for new domains, see /docs/the-enforcement-journey, but treat it as context, not instructions, for an already-enforced domain.
The new rua address DMARC Engine assigns you is noted down. This is the value you will add to your DMARC record. It is a mailbox on our side, dedicated to your account, that receives and parses the XML.
Your known-good sending sources from the export step are recognised. The platform's view of your SPF includes and DKIM selectors should account for every legitimate sender on your list. If something is missing here, fix it now, while you are still purely in read-only mode, not after you have re-pointed reporting.

If you intend to use hosted delegation for SPF flattening, MTA-STS or BIMI, prepare those CNAME targets now too, but do not publish them yet. You want the target zones populated and ready so that when you flip the CNAME, it resolves immediately. The mechanics of delegated, automatically maintained records are covered in /docs/delegating-your-dns and, for the SPF case specifically, /docs/how-spf-flattening-works.

Re-pointing the rua address with no gap

This is the heart of the migration, and the safe way to do it is to run both providers in parallel for a short overlap rather than cutting one off before the other is live.

The DMARC rua= tag accepts a comma-separated list of destinations. You are allowed to send your aggregate reports to more than one address at once. Use that.

Step one: add DMARC Engine alongside the old provider. Edit your live _dmarc TXT record so the rua lists both the old reporting mailbox and the new one. Keep everything else identical. For example, if your live record is:

v=DMARC1; p=reject; rua=mailto:oldprovider-token@old-vendor.example; sp=reject; adkim=s; aspf=s

you change only the rua to:

v=DMARC1; p=reject; rua=mailto:oldprovider-token@old-vendor.example, mailto:your-token@dmarcengine.com; sp=reject; adkim=s; aspf=s

Note what did not move: p=reject, sp=reject, the strict alignment modes. The policy is untouched, so receivers behave exactly as before and your mail flow is unaffected. The only change is that the next cycle of aggregate reports goes to two places instead of one.

There is one cross-domain wrinkle worth knowing. When a receiver sends reports to a rua address whose domain differs from the domain being reported on, it first checks for an external destination authorisation record at yourdomain.com._report._dmarc.<destination-domain>. DMARC Engine publishes the matching authorisation for its own report domain automatically, so reports flow without you doing anything extra. If your old provider required you to publish such a record for them, leave it in place during the overlap; you will remove it only when you decommission them.

Step two: wait for one or two full reporting cycles. Receivers batch aggregate reports, typically once per day per source. Give it 24 to 72 hours. During this window both dashboards should be filling with the same data, which is precisely the confirmation you want: identical sending sources, identical pass and fail counts, in both the old tool and DMARC Engine. If the two disagree, you have found a problem to understand before you cut over, not after.

Step three: remove the old provider from the rua. Once DMARC Engine is showing complete, correct reports that match what the old provider showed, edit the record one final time and drop the old destination:

v=DMARC1; p=reject; rua=mailto:your-token@dmarcengine.com; sp=reject; adkim=s; aspf=s

Because you overlapped, there was never a moment when zero providers were collecting reports. That is the no-gap guarantee, and it costs you nothing but a couple of days of patience.

If you also use ruf= failure reporting, treat it the same way: add the new destination alongside the old, overlap, then remove. Most domains can leave ruf off entirely, since aggregate data is enough to drive the enforcement journey and failure reports carry message fragments with privacy implications, but if you rely on it, migrate it with the same overlap discipline.

Switching delegated records

If your audit found CNAMEs pointing into the old vendor's zone, those need a deliberate cut-over because they are records the old provider actively serves. The risk here is different from the rua swap: a delegated record is a live part of your authentication, so the order matters.

Handle each delegated record on its own, never in a batch, and verify each before moving to the next.

Delegated _dmarc (the policy record itself). Some providers manage your entire DMARC record via CNAME so they can change rua without you editing DNS. To migrate, you replace the CNAME with either a plain TXT record you control (carrying the exact policy and the new DMARC Engine rua) or a CNAME pointing to DMARC Engine's hosted DMARC target. The instant you do this, the old provider can no longer alter your policy, which is the point. Confirm with dig +short TXT _dmarc.yourdomain.com that the resolved record carries your enforced policy and the new reporting address. Hosted DMARC mechanics are described in /docs/hosted-dmarc.
Delegated SPF / flattening. If your SPF record is a CNAME or include into the old vendor's flattening service, swap it to DMARC Engine's hosted SPF target only after confirming the new target already resolves to a record covering every sender on your export list. SPF is unforgiving: a momentary gap can cause legitimate mail to soft-fail. Validate the live result with the SPF checker before and after the swap, and read /docs/hosted-spf for how the maintained include stays under the ten-lookup limit.
Delegated MTA-STS. The MTA-STS policy is served over HTTPS and referenced by _mta-sts TXT plus a CNAME for the policy host. Cut these over together to DMARC Engine's targets, then confirm the policy file resolves with the MTA-STS checker. Setup detail lives in /docs/mta-sts-setup.
Delegated BIMI. Re-point default._bimi.yourdomain.com to the new target once your logo (SVG) and, if you use one, your VMC certificate are in place on the DMARC Engine side. Verify with the BIMI checker. BIMI only displays when you are at enforcement anyway, so there is no deliverability risk in the swap itself, only a cosmetic one if the logo is missing.

For each of these, the safe pattern is identical: make sure the new target resolves correctly first, then flip the CNAME, then immediately re-check with the relevant free tool. Because DNS changes are atomic per record, you can roll any single one back in seconds by restoring the previous value if a checker shows something wrong.

Verifying there was no gap in coverage

Migration is not finished when the records are changed; it is finished when you have evidence that coverage was continuous. Gather that evidence deliberately.

Confirm the policy never moved. The whole exercise should have left p=, sp= and your alignment modes exactly as they were. Re-read the live record and compare it character by character against the verbatim copy you saved during export. The only intended difference is the rua (and possibly ruf) destination. Anything else changing is a mistake to undo. The free DMARC checker parses the live record and flags syntax problems, and check that DMARC is working end to end walks through the three independent things "working" actually means.

Confirm reports are arriving at the new home. Within one full reporting cycle of dropping the old provider, DMARC Engine should be receiving fresh aggregate reports. If 48 hours pass with nothing, the most likely causes are a typo in the rua token, a missing external-destination authorisation (only relevant if you are not using our default report domain), or a stale record still cached. Re-check the published record and give DNS time to propagate; the DNS propagation checker shows whether resolvers worldwide see your new value yet.

Reconcile sending sources against your export. Open the DMARC Engine dashboard and compare its list of senders and their pass/fail/align status against the known-good list you exported from the old provider. They should match. A source that passed on the old dashboard and now appears failing usually means a delegated record cut-over went wrong (most often SPF), not a real authentication failure, so investigate the record before you panic about the sender. The DKIM checker and SPF checker let you validate any individual selector or include directly.

Watch through one quarantine/reject cycle. If you are at enforcement, the truest test is simply that legitimate mail keeps being delivered after the migration. Spot-check that internal and external recipients are still receiving from every system on your sender list (newsletters, invoices, transactional notifications, ticket replies). No bounces, no sudden spam-foldering, no support tickets about missing mail means the policy genuinely did not move and alignment genuinely held.

Decommission the old provider last. Only after all of the above checks pass should you cancel the old account. At that point, remove any external-destination authorisation record you published for them (yourdomain.com._report._dmarc.<old-vendor-domain> if it exists), and delete any leftover CNAMEs that still point into their zone. Leaving orphaned authorisation or CNAME records does no harm to mail flow, but it is tidy to remove them, and an old rua destination left in place would keep feeding a dashboard you no longer read.

A clean migration checklist

Run top to bottom; do not skip the overlap.

Export the live DMARC record verbatim, every tag, the sender list, any delegated CNAMEs, and a sample of raw XML.
Stage the domain in DMARC Engine in read-only mode; confirm the prepared policy matches your live enforced state and note the new rua token.
Overlap by adding the new rua alongside the old, changing nothing else, and wait one to two reporting cycles.
Reconcile the two dashboards; confirm identical sources and counts.
Cut over by removing the old rua, leaving only DMARC Engine.
Switch delegated records one at a time (DMARC, SPF, MTA-STS, BIMI), verifying each with its checker before the next.
Verify the policy never moved, reports are arriving, sources match the export, and mail is still delivered.
Decommission the old provider and remove orphaned authorisation and CNAME records.

Common ways migrations go wrong

A short list of the failure modes worth pre-empting, all of which the staged approach above avoids:

Lowering the policy "to be safe" during the move. Dropping from p=reject to p=none to migrate reopens the spoofing window for no benefit, since the policy is irrelevant to where reports are sent. Leave it alone.
Cutting reporting before the new side is confirmed. Removing the old rua on day one, before DMARC Engine has shown a complete report, creates exactly the coverage gap you are trying to avoid. Overlap first.
Two DMARC records at the same host. Publishing a second _dmarc TXT record instead of editing the existing one means receivers find more than one policy record and ignore all of them. There must be exactly one DMARC record per host. Always edit in place.
Cutting a delegated SPF record before the new target resolves. SPF gaps cause soft fails on live mail. Confirm the target resolves with the SPF checker before flipping the CNAME.
Forgetting the external-destination authorisation when not using our default report domain. If reports never arrive, this is the first thing to check.
Cancelling the old account too early. Keep it until every verification passes; it is cheap insurance and your only fallback if something looks wrong.

Migrating providers is, at heart, a DNS edit and a patient overlap. Capture your current state so you can never lose visibility, stage the new platform fully before anything public changes, add the new reporting destination alongside the old one and only remove the old once the new one has proven itself, cut delegated records over one careful step at a time, and verify with the free tools that your policy never moved and your senders never dropped. Do it in that order and the migration is genuinely invisible to your mail. When you are ready to start, add your domain in the dashboard at app.dmarcengine.com, and keep the DMARC checker, SPF checker and report analyzer open in another tab so you are watching real evidence the whole way through. For anything that needs a definition along the way, the /glossary and the platform requirements page fill in the gaps.