Blog · Dmarc
Why ARC Failures Appear After a Mail Server Migration
Why mail server migration breaks the ARC chain
When you migrate to a new mail server, one of the things that can break silently is ARC validation on forwarded mail. You may not notice it immediately. The messages still arrive. But forwarding partners, mailing list operators, and internal redirect systems that depend on ARC may start seeing validation failures where none existed before.
This is not a configuration error on your part. It is an expected consequence of how ARC works.
ARC (Authentication Results Certification) builds a chain of signed authentication results as a message passes through forwarding hops. Each intermediate server in the forwarding path applies its own ARC seal, which is a cryptographic signature tied to that specific server's identity. When the chain reaches its destination, the receiving server can verify that the original authentication results were intact when the message left the first forwarding hop.
When you migrate your mail server, the server's identity changes. The new MTA is different hardware, a different OS installation, or a different software configuration. Any ARC seals it applies going forward are tied to this new identity.
The problem most commonly surfaces when you receive forwarded mail from partners who forwarded it through a service that applied ARC seals before the message reached your old infrastructure. Those seals were verified by your old server. After migration, your new server may not recognise or cannot verify those existing seals because they were applied by infrastructure that no longer matches your current setup.
The result is an ARC fail header on mail that was previously passing. This is also where monitoring matters: without a tool watching your DMARC aggregate reports, you may not see this happening until a partner flags it. With DMARCFlow, you would catch the spike in ARC-related failures within the first report cycle after migration, giving you a chance to respond before it affects more forwarding relationships.
The fix is usually straightforward once you know what to look for.
What an ARC fail header looks like after migration
When ARC validation fails, the receiving server adds an ARC fail result to the message headers. Here is an annotated example of what you might see on a forwarded message after a migration:
Arc-Authentication-Results: i=1; mx.example recipient.com;
arc=fail;
dmarc=fail (p=reject) header.from=sender.com
Arc-Seal: s=1; a=rsa-sha256; t=1234567890;
d=mail.old-server.example.com;
cv=fail;
Look for two things in these headers. First, the Arc-Seal block. The d= field shows which server applied the seal. If that server identity does not match your current infrastructure, the downstream receiver may not be able to verify it. In a migration scenario, you will often see d= values pointing to the old server hostname or old domain that was retired.
Second, the cv= (chain validation) tag. A cv=fail value means the chain of ARC seals could not be verified. This is the most common ARC failure you will see after migration.
Not all ARC fail codes indicate a migration problem. Some indicate that a receiver does not support ARC at all. But when the failing seal d= field points to infrastructure that has been replaced or decommissioned, the cause is almost always a migration that interrupted the chain.
What to check on your new mail server
Before assuming the failure is on the forwarding partner side, verify your own server is correctly applying ARC seals to outgoing forwarded mail.
First, confirm ARC signing is enabled on your MTA. Most modern MTAs support ARC but it is not always on by default. In Postfix, look for milter_protocol and ensure an ARC-capable milter is configured. In Exchange Online, ARC signing is managed by Microsoft's infrastructure, but you can verify it is working by checking message headers on forwarded messages you receive from your own domain.
Second, verify your DKIM configuration is still valid after migration. A common migration mistake is copying SPF records but forgetting to copy DKIM selector records. If DKIM breaks during migration, ARC chain continuity will fail as a side effect because DKIM is part of the authentication results that ARC certifies.
Third, check whether your new server is signing outbound messages with the correct domain in the d= field of ARC seals. If your old server used a different hostname in its ARC seals than your new server, downstream receivers may treat them as separate signing entities and reject the chain.
Fourth, if you run a forwarding service or mailing list on your own infrastructure, make sure that service is applying ARC seals as messages pass through. Migration often reconfigures these services without preserving the ARC signing configuration.
How to fix or work around ARC failures after migration
The most direct fix depends on where in the chain the failure is occurring.
If the failure is in mail you are receiving from forwarding partners - meaning their ARC seals are failing when they hit your new server - the issue is usually that your new server is stricter about ARC validation than the old one, or the forwarding partner's server is still applying seals with references to your old infrastructure. In this case, ask the forwarding partner to clear any cached ARC state and re-send a test message. Their system may have stored references to your old server's identity that no longer resolve.
If the failure is in mail you are sending to forwarding partners who verify ARC, your new server may not be applying seals that the forwarding partner's system can verify. Check your outbound ARC signing configuration and ensure the d= domain in your ARC seals resolves correctly and matches your sending domain.
For forwarding services running on your own infrastructure, reconfigure the forwarding service to apply fresh ARC seals after migration. Some forwarding software needs a configuration change to sign outbound mail with the new server identity.
As a short-term workaround while you rebuild the ARC chain, SRS (Sender Rewriting Scheme) can serve as a fallback for forwarded mail. SRS modifies the envelope sender address so that SPF passes through the forwarding path. It does not replace ARC but it handles the SPF leg of the forwarding problem independently. Note that SRS is a workaround, not a permanent solution, and it does not help with DKIM alignment issues.
Some organisations temporarily allow-list known forwarding partners in their DMARC policy during migration. This requires knowing which partners forward your mail and is a configuration change on your side. It should be temporary because it reduces your DMARC enforcement posture.
Migration checklist: email authentication before you cut over
Before you switch DNS to point MX records at your new server, run through this checklist to avoid ARC and DMARC surprises post-migration.
1. Send a test message through each of your main forwarding paths and check the headers on the received copy. Note which ARC seals are present and which servers are signing them. This gives you a baseline to compare against after migration.
2. On the new server, verify ARC signing is active by sending a test message to a forwarding service you control and checking the outbound ARC headers.
3. Confirm DKIM selector records are published and resolve correctly. Query selector._domainkey.yourdomain.com via DNS and verify you get a valid DKIM record.
4. Verify SPF includes all IP ranges from which your new server will send mail. If the new server sends from a different IP range than the old one, update your SPF record before cutover.
5. Send test messages through your own forwarding or aliasing services and confirm they still arrive with passing ARC validation after the new server processes them.
6. Set up DMARC aggregate report monitoring before cutover so you catch any sudden spike in authentication failures within hours of the migration. DMARCFlow can receive and normalise these reports and alert you to ARC-related failures as soon as they appear. Without monitoring in place, you may not notice forwarding problems until a partner reports them days later.
7. After cutover, monitor forwarding partner feedback for a few days. If partners report new ARC failures, the baseline headers from step 1 give you a reference point for comparison.
Frequently asked questions
Does every mail server migration cause ARC failures?
Not always. If the migration only changes the server software version without changing the signing identity that appears in ARC headers, most forwarding paths continue working normally. Failures are most likely when the migration changes the MTA hostname, the domain used in ARC seal d= fields, or when the new server has stricter ARC validation settings than the old one.
Can I prevent ARC chain breakage during migration?
You can reduce the risk by preserving the MTA hostname and domain identity across the migration if your MTA software allows it. Some organisations run both old and new servers in parallel for a short period so forwarding partners can update their ARC caches gradually. If you control the forwarding infrastructure, you can pre-stage ARC seals with the new server identity before cutover.
My forwarding partners say their ARC validation is failing. Is it my fault?
It may not be either party's fault. If your migration changed the server identity that appears in ARC headers, forwarding partners who cached the old seals may need to clear their ARC state and re-validate. Ask them to send a fresh test message after clearing any cached ARC chain data on their side. If the failure persists, compare the ARC headers on the failing message against the baseline headers you captured before migration.
Does ARC retirement affect this scenario?
ARC is being updated as part of the dmarcbis standard track (RFC 9989 and related documents). DKIM2 is expected to handle forwarding authentication differently. For now, ARC remains deployed and relevant, particularly for mailing lists and forwarding services. If you are managing a migration, ARC still matters and getting the migration right prevents problems that will persist until the ARC retirement transition is complete. The expected timeline for that transition is years, not months.
Where does DMARCFlow fit in a mail server migration?
Monitoring is the main connection. After migration, you need to watch DMARC aggregate reports for spikes in authentication failures, including ARC-related failures from forwarding partners. DMARCFlow can aggregate these reports and surface failures that would otherwise require manually parsing XML files. If you are managing a migration without a monitoring tool, you may not notice forwarding problems until a partner reports them.