A rebrand replaces the one asset deliverability cannot: your domain's history. The parallel-running plan that carries trust from the old name to the new one.
A company rebrand comes with a checklist: new logo, new website, 301 redirects, updated social handles. Email gets one line on that checklist and deserves a project plan, because email is where the rebrand fights physics. The web has redirects that transfer authority; email has no equivalent. Your old domain's years of reputation, the complaint baselines, the engagement history, the per-recipient trust at every mailbox provider, are attached to a name you are about to stop using, and the new name starts as a stranger.
What transfers and what cannot
Nothing about domain reputation transfers. There is no redirect, no forwarding record, no provider process that moves history from olddomain.com to newdomain.com; the new domain earns its own standing from zero, exactly like any new identity. What does carry over is everything not attached to the name: your IPs and their reputation (if infrastructure stays put), your list and its engagement, your suppression records, and your operational practice. The rebrand migration is therefore a domain warming project wearing brand clothes, and the warming playbook applies with one addition: the old domain remains alive and useful throughout.
The sequence
Rebrand mail migration, end to end
- 1
Build the new domain's full stack early
Weeks before any announcement: SPF per subdomain, DKIM with fresh selectors, DMARC at p=none with reporting, subdomain architecture mirroring the old (mail., news., bounce domains), MTA-STS if you run it, dashboards registered. Let the DNS age quietly.
- 2
Start the drip before the announcement
Begin low-volume sending from the new domain to your most engaged segments, transactional first if product naming allows. The goal is weeks of clean history before volume needs to exist.
- 3
Announce, then migrate streams engaged-first
After launch, move streams to the new domain in warming-sized increments: engaged newsletter cohorts, then broader marketing, throttling on 4.7.x deferrals exactly as any ramp. The old domain keeps carrying whatever has not moved.
- 4
Bridge recognition in the inbox
Cold-start filtering is only half the risk; recipients who do not recognize the new name report it. Use a transition display name ("Newbrand, formerly Oldbrand"), announce the change in the last sends from the old domain, and expect a complaint bump anyway. Gate the early sends accordingly.
- 5
Keep the old domain authenticated forever-ish
The old domain stays fully authenticated, monitored via DMARC reports, and at enforcement for at least a year, then transitions to a locked-down non-sending posture (v=spf1 -all, p=reject, null MX on dead subdomains) permanently. Abandoned brand domains are phishing gold.
The details that bite
Mailbox forwarding: forwarding old-domain corporate addresses to new ones is necessary for humans and does nothing for sending identity; replies to old threads still work while your outbound builds the new name. Vendor sprawl: every SaaS tool that sends as you needs reconfiguration to the new domain, and the DMARC reports on the old domain are your census of what you forgot, which is a reason the old reporting stays on. List trust: recipients gave consent to the old brand; the consent travels with the relationship, but expectation-setting mail before the switch measurably reduces the unrecognized-sender complaints that otherwise tax the new domain's first months. And BIMI: the new domain needs its own DMARC enforcement history and certificate before logos return, so budget the visual continuity gap.
Timeline honesty
From first DNS to full migration with the new domain at stable reputation, plan two to four months, with the old domain in shrinking service throughout. Rushed versions of this migration are well documented in every deliverability community: full cutover at announcement, two weeks of deferrals and spam foldering during the highest-attention window a brand ever has, then a sheepish partial rollback. The parallel-running version is boring, which is the compliment infrastructure earns. Rebrands are rare enough that nobody builds the muscle; the physics are the same as every other migration in this archive, and the physics do not care about the launch party.
Frequently Asked Questions
Can we keep sending from the old domain forever instead?
Does forwarding old-domain mail to the new domain help reputation?
Should the new domain reuse the old DKIM keys?
What happens if we just abandon the old domain after a year?
Key Takeaways
- Domain reputation does not transfer; a rebrand starts the new name cold and warming physics govern the migration
- Build the new domain's full authentication stack weeks early and drip real mail before the announcement
- Migrate streams engaged-first over months of parallel running, with the old domain carrying the remainder
- Bridge recipient recognition deliberately; unrecognized-sender complaints are the rebrand-specific tax
- Keep the old domain registered and locked down permanently; abandoned brand domains are a phishing inheritance
Related articles
Half-Year Review: Email in the AI Inbox Era
Six months that rearranged the reading layer: Gemini in Gmail, Microsoft rejecting outright, DMARC finally a standard. What the first half of 2026 means for senders.
Deliverability Postmortems: Learning From Incidents
The incident is over, placement recovered, and the pressure to move on is enormous. The blameless postmortem practice that converts each incident into prevention.
Writing for AI Readers: Structure When Gemini Summarizes You
Five months of AI Overviews data shows opens up and clicks down: recipients read summaries. How to structure email so the model's version still does your job.