How does changing ESPs and domains affect sender reputation and email deliverability?
Michael Ko
Co-founder & CEO, Suped
Published 30 Jul 2025
Updated 22 May 2026
9 min read
Summarize with
Yes, changing ESPs and changing domains affects sender reputation and email deliverability. An ESP change changes infrastructure signals such as IPs, bounce processing, DKIM selectors, link tracking, and headers. A domain change changes the identity signals mailbox providers have already learned, especially the visible From domain, DKIM domain, Return-Path domain, and sending subdomain.
The practical answer is simple: if your current domain has good reputation, keep the visible sending domain when you switch ESPs unless there is a strong brand or compliance reason to change it. If you must change the domain as well, treat it as a new reputation build. Some brand recognition and recipient engagement will carry over, but mailbox providers still need new evidence that the new domain and new sending infrastructure deserve inbox placement.
- ESP change: expect short-term filtering changes because IPs, headers, bounce paths, and sending cadence change.
- Domain change: expect a larger reset because mailbox providers see a new identity and need fresh reputation data.
- Both together: plan for a temporary dip, often one to several weeks, depending on volume, engagement, and complaint rate.
- Safer path: move the ESP first, stabilize results, then change the domain only if the business case is worth it.
What changes when you move ESPs
I treat an ESP migration as an infrastructure migration before I treat it as a marketing project. The content can look the same to a subscriber, but the message can look very different to a mailbox provider. New IP pools, new envelope sender domains, new DKIM keys, new tracking domains, and new List-Unsubscribe handling all add change.
That does not mean the move is risky by default. It means the migration needs clean setup and controlled volume. Before the first production send, I want to know which domains appear in the visible From address, DKIM signature, Return-Path, bounce MX, unsubscribe header, and tracked links.
Amazon Route 53 hosted zone showing DNS records used in an ESP migration.
|
|
|
|---|---|---|
IP | Pool or dedicated IP | Needs new sending history |
From | Visible domain | High reputation weight |
DKIM | Signing domain | Affects DMARC pass |
Bounce | Return-Path | Controls suppression |
Links | Tracking host | Breaks old clicks if removed |
Main identity and infrastructure signals affected by an ESP migration.
What reputation carries over
Reputation does not transfer as a single score. Mailbox providers build reputation across several signals. Some of those signals stay stable when you move ESPs, while others reset immediately.
If you keep the same visible From domain and the same general sending pattern, your established domain reputation helps. If you keep the same audience and send to people who open, click, reply, and avoid spam complaints, your engagement history helps. If you change to a fresh domain, a fresh subdomain, and a fresh ESP at the same time, the new identity starts with little direct history.
How much reputation usually carries over
Approximate signal continuity during common migration patterns.
Carried signal
Fresh signal
Do not change identity to hide a problem
A new domain does not fix poor consent, weak engagement, high spam complaints, or stale lists. It delays the same problem until mailbox providers collect enough new negative signals. Fix the sending practice first, then migrate.
Staged move or hard cut
There are two workable migration patterns. A staged move reduces change at each step. A hard cut finishes faster, but it concentrates risk. I prefer the staged move unless the old setup blocks the business, the brand has changed, or the sending domain must be replaced for a clear reason.
Staged move
Use this when the existing domain has decent reputation and the team can keep both platforms active for a short overlap.
- Lower shock: keep the visible From domain and change ESP infrastructure first.
- Cleaner bounce flow: give the new ESP its own Return-Path subdomain.
- Better rollback: leave the old ESP open for unsubscribe and bounce processing.
Hard cut
Use this when the old domain or platform cannot stay in place, or the rebrand needs one clean launch date.
- Higher shock: new ESP and new domain both need fresh trust signals.
- Shorter project: one launch window avoids running two migrations.
- Tighter control: start with engaged recipients and expand only when results hold.
A five-step ESP migration path from keeping the From domain to expanding volume.
How to set up sending domains
You usually do not need to buy a new domain for marketing mail. A subdomain of the main brand domain is enough, and it is cleaner for subscribers. For example, marketing on e.example.com and transactional mail on example.com or t.example.com keeps the brand connection while giving each mailstream room to build its own reputation.
I avoid cousin domains for normal opt-in mail. A cousin domain teaches recipients that the brand sends mail from unrelated domains, which makes impersonation easier to believe. A separate domain belongs only in exceptional cases, such as isolating a legally approved but high-risk outreach program away from corporate and opt-in mail.
Example domain layouttext
Marketing From: marketing@e.example.com Marketing DKIM d=: e.example.com Marketing Return-Path: bounces.e.example.com Transactional From: orders@example.com Transactional DKIM d=: example.com Transactional Return-Path: t.example.com
The Return-Path deserves special attention. If the current Return-Path domain has MX records that point to the old ESP, only that ESP will process bounces correctly. During overlap, the new ESP should get its own bounce subdomain so suppression data does not split or disappear.
Example DNS recordsdns
_dmarc.e.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com" s1._domainkey.e.example.com CNAME s1.domainkey.esp.example.net bounces.e.example.com CNAME bounce.esp.example.net track.e.example.com CNAME track.esp.example.net
Before sending, run a domain health check on the old domain, the new sending subdomain, and the bounce subdomain. A valid TXT record is only the starting point. The goal is a message that passes SPF or DKIM, passes DMARC, and routes bounces and unsubscribes to the right system.
Migration checklist
A clean migration is mostly sequencing. The biggest problems I see are not exotic filtering decisions. They are missed automated campaigns, old unsubscribe links, untested DKIM, and DNS changes made while mail is still in flight.
- Inventory domains: list the visible From, DKIM, Return-Path, link tracking, image, and unsubscribe hosts.
- Prepare DNS: add SPF, DKIM, DMARC, bounce, and tracking records before production sending.
- Keep overlap: leave the old ESP active long enough to process late bounces and unsubscribe requests.
- Start engaged: send first to recent openers, recent buyers, active users, and people with clear consent.
- Hold stale lists: do not reintroduce old inactive segments during the first reputation build.
- Test real mail: send a live campaign sample and inspect headers, authentication results, and spam placement.
For the last step, send a test email from the new ESP after DNS is live. I want to see the actual headers because DNS checks alone do not prove the ESP is signing the message and using the expected envelope sender.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
Keep old links alive
If the old ESP hosted tracked links or unsubscribe links, do not remove those DNS records immediately. Keep them working for at least 30 days, and longer when your legal or operational process needs it.
Blocklists and blacklists during migration
Separate subdomains reduce operational blast radius, but they do not create perfect isolation. A blocklist (blacklist), mailbox provider, or corporate filter can judge the subdomain, parent domain, link domain, IP, message content, brand text, or a combination of those signals.
That is why transactional and marketing mail should be separated by purpose. True transactional mail, such as password resets, order confirmations, and account notices, has different engagement and complaint patterns than promotional mail. Mixing the two makes diagnosis harder and increases the chance that a marketing issue affects critical user mail.
Do not use extra domains to spread risk
Using several domains to avoid filtering is not a reputation strategy. It trains subscribers to accept unrelated brand domains and gives mailbox providers more reasons to distrust the mailstream.
During and after the move, I monitor domain and IP listings with blocklist monitoring. A blacklist event is easier to handle when it is tied to a date, domain, IP, campaign, and sending source instead of discovered weeks later through a revenue drop.
How Suped fits into the workflow
Suped is strongest as the overall DMARC platform for this migration workflow because it connects the signals that usually get checked in separate places. In one view, Suped can show whether the new ESP is authenticating, whether unknown sources still send as the domain, and whether policy changes are safe.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
The concrete workflow is straightforward: add the old domain and new subdomain, turn on DMARC monitoring, confirm the new ESP appears as an authorized source, then use issue detection and fix steps when SPF, DKIM, or DMARC fails. Hosted SPF helps when the DNS lookup count is close to the limit, and Hosted DMARC helps stage policy changes without repeating manual DNS edits.
For MSPs and teams with many brands, the multi-tenant dashboard matters because migrations rarely happen for one domain only. Suped also brings real-time alerts, Hosted MTA-STS, SPF flattening, and reputation monitoring into the same operational view, which is what I want during a period where small authentication mistakes can look like sudden deliverability failure.
When to keep the old domain
Keep the old visible From domain when it has good engagement, low complaints, clean authentication, and subscribers recognize it. In that case, change the ESP underneath it. Use a new Return-Path subdomain for the new provider, add new DKIM selectors, and warm sending volume.
Change the visible domain when the brand has changed, the old domain creates user confusion, the old setup ties critical DNS to a provider you are leaving, or the current naming no longer fits the mailstream. If you need a deeper migration plan, compare this with how to diagnose migration drops and whether you can keep the same sending domain across more than one ESP.
- Keep it: when reputation is healthy and the domain name still makes sense to subscribers.
- Stage it: when you need the new ESP now but can delay the visible domain change.
- Replace it: when the old domain is confusing, constrained, or no longer tied to the brand.
- Isolate it: when a high-risk mailstream must not share reputation with customer or corporate mail.
Views from the trenches
Best practices
Keep the visible From domain when reputation is healthy and brand clarity stays intact.
Give the new ESP its own bounce subdomain so suppression processing stays reliable.
Leave old tracking and unsubscribe hosts live long enough for late clicks and requests.
Common pitfalls
Changing ESP, domain, DKIM, bounce host, and links together creates avoidable filter shock.
Moving MX records before final sends finish can break bounce handling and suppressions.
Using cousin domains for normal opt-in mail weakens brand trust and complicates DMARC.
Expert tips
Use unique DKIM selectors so old and new providers can be prepared without collision.
Start migration volume with recent engaged users, then expand only when metrics hold.
Separate transactional and marketing mail by purpose, not by random domain purchases.
Marketer from Email Geeks says changing the ESP and domain together creates short-term pain, so the team should plan for a fresh trust build.
2022-02-03 - Email Geeks
Expert from Email Geeks says keeping a strong visible From domain while adding a new Return-Path subdomain is often the cleaner transition.
2022-02-03 - Email Geeks
The practical answer
Changing ESPs affects deliverability because the sending infrastructure changes. Changing domains affects deliverability more because the sending identity changes. Doing both at once is workable, but it means mailbox providers need to relearn both who you are and how your new mail behaves.
My default recommendation is to keep the trusted visible domain, move the ESP with a dedicated bounce subdomain, warm the new setup with engaged recipients, and keep the old ESP alive for late bounces and unsubscribe requests. If the domain must change, make the change deliberately, monitor every authentication result, and do not let stale lists define the new reputation.
