Going through a merger, rebrand, or domain change? Read this first\u00a0<\/strong><\/h3>\n\n\n\n\nKey takeaways \u2728<\/h3>\n\n- A rebrand is a <\/span>deliverability<\/span> event\u2014<\/span><\/span><\/strong>not just a design project.<\/span><\/span><\/li>\n
- Set up <\/span>SPF, DKIM, and DMARC <\/span><\/span><\/strong>on your new domain<\/span><\/span> correctly<\/span>, or your emails land in spam.<\/span><\/span><\/li>\n
- Warn subscribers early and clean your list first<\/span><\/span><\/strong> to protect<\/span><\/span> your new domain\u2019s reputation.<\/span><\/span><\/li>\n<\/ul>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\u00a0<\/p>\n
I\u2019ve walked more than one brand through this exact transition, and the pattern is always the same: everyone plans for the logo, the colors, and the new website, and almost no one plans for what happens to their sending domain.\u00a0<\/span>\u00a0<\/span><\/p>\nThat\u2019s the part that determines whether your subscribers keep hearing from you, or your next campaign lands in the spam folder. Get it wrong, and you can tank your sender reputation, spam folder placements, complaint spikes, phishing flags, and years of earned trust.<\/span>\u00a0<\/span><\/p>\nBut don\u2019t worry! Here\u2019s how to get it right.<\/span>\u00a0<\/span><\/p>\nFirst things first: what a rebrand won\u2019t fix\u00a0<\/strong><\/h3>\nFirst, figure out if the domain needs to change. If the brand name shifts but your website URL stays the same, your from-address can stay put too. But if the website domain is changing, your sending domain and from-address should move with it. When you shift, keep the sending domain as a subdomain of your new brand\u2019s root (e.g., mail.newbrand.com). Cousin or lookalike domains get flagged as phishing by filters and recipients alike. A new brand deserves a real domain, not a spoof of one.<\/span>\u00a0<\/span><\/p>\nThen, before doing any tactical work, level-set on what a rebrand can and can\u2019t do for your email program. If your current email program struggles with low engagement, high complaint rates, or spam-folder placement, a new domain won\u2019t magically fix it.\u00a0<\/span>\u00a0<\/span><\/p>\nMailbox providers identify the same sending patterns within days, and the new domain will land right where the old one did. Fix your sending practices and <\/span>deliverability<\/span><\/a> first, <\/span>then <\/span><\/i>rebrand.<\/span>\u00a0<\/span><\/p>\n\u00a0<\/span><\/p>\nGet your sending infrastructure right\u00a0<\/strong><\/h3>\nWhen you rebrand, don\u2019t make a hard domain cutover\u2014that\u2019s a mistake. You\u2019ll want your current brand referencing (or at least redirecting to) the new domain. That requires getting your email sending platform properly configured to send from the new domain.<\/span>\u00a0<\/span><\/p>\nYour sending platform will also require you to either delegate a subdomain or provide you with DNS records to publish. These are usually:<\/span>\u00a0<\/span><\/p>\n\n- A DKIM public key to be published at
._domainkey., either as a TXT or CNAME.<\/domain><\/selector><\/span>\u00a0<\/span><\/li>\n<\/ul>\n\n- A SPF record with the value like this \u201cv=spf1 include:your-esp-spf.com -all\u201d, but change the \u201cinclude:[value]\u201d to \u201cip4:[ip address]\u201d if you want to specify your dedicated IP address.<\/span>\u00a0<\/span><\/li>\n<\/ul>\n
\n- A DMARC record is also often provided to be published at _dmarc.
, usually with a default value of \u201cv=DMARC1; p=reject\u201d. Although it meets Google\u2019s bulk sender requirements, it will leave you blind to which sources are sending with your new domain, legitimate or otherwise.<\/domain><\/span> A DMARC record also needs to include a rua mailto: address so that aggregate reports are received. It should look like this: v=DMARC1; p=reject; t=y; fo=1; aspf=r; rua=mailto:dmarc_agg@dmarc.everest.email. The sender will often have an address too.<\/span><\/li>\n<\/ul>\n
Key takeaways \u2728<\/h3>\n\n- A rebrand is a <\/span>deliverability<\/span> event\u2014<\/span><\/span><\/strong>not just a design project.<\/span><\/span><\/li>\n
- Set up <\/span>SPF, DKIM, and DMARC <\/span><\/span><\/strong>on your new domain<\/span><\/span> correctly<\/span>, or your emails land in spam.<\/span><\/span><\/li>\n
- Warn subscribers early and clean your list first<\/span><\/span><\/strong> to protect<\/span><\/span> your new domain\u2019s reputation.<\/span><\/span><\/li>\n<\/ul>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\u00a0<\/p>\n
I\u2019ve walked more than one brand through this exact transition, and the pattern is always the same: everyone plans for the logo, the colors, and the new website, and almost no one plans for what happens to their sending domain.\u00a0<\/span>\u00a0<\/span><\/p>\nThat\u2019s the part that determines whether your subscribers keep hearing from you, or your next campaign lands in the spam folder. Get it wrong, and you can tank your sender reputation, spam folder placements, complaint spikes, phishing flags, and years of earned trust.<\/span>\u00a0<\/span><\/p>\nBut don\u2019t worry! Here\u2019s how to get it right.<\/span>\u00a0<\/span><\/p>\nFirst things first: what a rebrand won\u2019t fix\u00a0<\/strong><\/h3>\nFirst, figure out if the domain needs to change. If the brand name shifts but your website URL stays the same, your from-address can stay put too. But if the website domain is changing, your sending domain and from-address should move with it. When you shift, keep the sending domain as a subdomain of your new brand\u2019s root (e.g., mail.newbrand.com). Cousin or lookalike domains get flagged as phishing by filters and recipients alike. A new brand deserves a real domain, not a spoof of one.<\/span>\u00a0<\/span><\/p>\nThen, before doing any tactical work, level-set on what a rebrand can and can\u2019t do for your email program. If your current email program struggles with low engagement, high complaint rates, or spam-folder placement, a new domain won\u2019t magically fix it.\u00a0<\/span>\u00a0<\/span><\/p>\nMailbox providers identify the same sending patterns within days, and the new domain will land right where the old one did. Fix your sending practices and <\/span>deliverability<\/span><\/a> first, <\/span>then <\/span><\/i>rebrand.<\/span>\u00a0<\/span><\/p>\n\u00a0<\/span><\/p>\nGet your sending infrastructure right\u00a0<\/strong><\/h3>\nWhen you rebrand, don\u2019t make a hard domain cutover\u2014that\u2019s a mistake. You\u2019ll want your current brand referencing (or at least redirecting to) the new domain. That requires getting your email sending platform properly configured to send from the new domain.<\/span>\u00a0<\/span><\/p>\nYour sending platform will also require you to either delegate a subdomain or provide you with DNS records to publish. These are usually:<\/span>\u00a0<\/span><\/p>\n\n- A DKIM public key to be published at
._domainkey., either as a TXT or CNAME.<\/domain><\/selector><\/span>\u00a0<\/span><\/li>\n<\/ul>\n\n- A SPF record with the value like this \u201cv=spf1 include:your-esp-spf.com -all\u201d, but change the \u201cinclude:[value]\u201d to \u201cip4:[ip address]\u201d if you want to specify your dedicated IP address.<\/span>\u00a0<\/span><\/li>\n<\/ul>\n
\n- A DMARC record is also often provided to be published at _dmarc.
, usually with a default value of \u201cv=DMARC1; p=reject\u201d. Although it meets Google\u2019s bulk sender requirements, it will leave you blind to which sources are sending with your new domain, legitimate or otherwise.<\/domain><\/span> A DMARC record also needs to include a rua mailto: address so that aggregate reports are received. It should look like this: v=DMARC1; p=reject; t=y; fo=1; aspf=r; rua=mailto:dmarc_agg@dmarc.everest.email. The sender will often have an address too.<\/span><\/li>\n<\/ul>\n
\u00a0<\/p>\n
I\u2019ve walked more than one brand through this exact transition, and the pattern is always the same: everyone plans for the logo, the colors, and the new website, and almost no one plans for what happens to their sending domain.\u00a0<\/span>\u00a0<\/span><\/p>\n That\u2019s the part that determines whether your subscribers keep hearing from you, or your next campaign lands in the spam folder. Get it wrong, and you can tank your sender reputation, spam folder placements, complaint spikes, phishing flags, and years of earned trust.<\/span>\u00a0<\/span><\/p>\n But don\u2019t worry! Here\u2019s how to get it right.<\/span>\u00a0<\/span><\/p>\n First, figure out if the domain needs to change. If the brand name shifts but your website URL stays the same, your from-address can stay put too. But if the website domain is changing, your sending domain and from-address should move with it. When you shift, keep the sending domain as a subdomain of your new brand\u2019s root (e.g., mail.newbrand.com). Cousin or lookalike domains get flagged as phishing by filters and recipients alike. A new brand deserves a real domain, not a spoof of one.<\/span>\u00a0<\/span><\/p>\n Then, before doing any tactical work, level-set on what a rebrand can and can\u2019t do for your email program. If your current email program struggles with low engagement, high complaint rates, or spam-folder placement, a new domain won\u2019t magically fix it.\u00a0<\/span>\u00a0<\/span><\/p>\n Mailbox providers identify the same sending patterns within days, and the new domain will land right where the old one did. Fix your sending practices and <\/span>deliverability<\/span><\/a> first, <\/span>then <\/span><\/i>rebrand.<\/span>\u00a0<\/span><\/p>\n \u00a0<\/span><\/p>\n When you rebrand, don\u2019t make a hard domain cutover\u2014that\u2019s a mistake. You\u2019ll want your current brand referencing (or at least redirecting to) the new domain. That requires getting your email sending platform properly configured to send from the new domain.<\/span>\u00a0<\/span><\/p>\n Your sending platform will also require you to either delegate a subdomain or provide you with DNS records to publish. These are usually:<\/span>\u00a0<\/span><\/p>\nFirst things first: what a rebrand won\u2019t fix\u00a0<\/strong><\/h3>\n
Get your sending infrastructure right\u00a0<\/strong><\/h3>\n
\n
\n
\n
![\"\"](\"https:\/\/www.litmus.com\/wp-content\/uploads\/2026\/08\/Screenshot-2026-08-04-at-10.52.14-AM.png\"\/)
![\"\"](\"https:\/\/www.litmus.com\/wp-content\/uploads\/2026\/08\/Screenshot-2026-08-04-at-10.52.14-AM.png\")
\n<\/picture>\n \u00a0<\/span><\/p>\n