What Happens to a Shared IP's Email Deliverability Reputation When You Switch CDN Providers?
Usually nothing, because your CDN doesn't send your email. A CDN proxies web traffic, so switching providers changes the IP addresses your website resolves to, not the IPs your mail leaves from. Your sending reputation lives with your mail provider's IPs and your domain, and neither one moves when your CDN does.
The trouble starts when the migration touches email by accident. Moving nameservers can quietly drop your mail records, mail sent from your web server can land on a cold IP, and leaving a CDN that also forwards your mail sends it out from new addresses. Those are the cases that hurt email deliverability, and every one of them is preventable.
How Shared IP Addresses Accumulate Sender Reputation Over Time
"Shared IP" means two very different things here, and mixing them up is where most of the worry comes from.
On an email provider's shared IP address, everyone's behavior adds up. Google puts it plainly: the activity of any sender on a shared IP affects the reputation of all senders on it. Mailbox providers build that IP reputation from sending volume and consistency, bounces, spam complaints and hits on spam traps, which are addresses that exist only to catch careless senders.
Your domain earns its own reputation too. Gmail can reject or slow down mail because of a low-reputation sending IP or a low-reputation sending domain, and it reports the two separately. So even a perfect IP can't rescue a domain that's been sending junk.
On a shared pool, you also don't control much. Amazon SES says that on shared IPs your sender reputation is managed by SES and can't be isolated from other senders. That sounds scary, but it's also why a CDN switch can't touch it.
What Changes to Your IP Address When You Switch CDN Providers
Most teams switch CDNs over performance or bandwidth costs, and almost none of that touches mail. Here's what actually moves:
CDNs only proxy web hostnames. Cloudflare, for example, proxies A, AAAA and CNAME records over web ports, and its docs say SMTP, IMAP and POP3 don't work through its standard HTTP proxy. Your MX records and TXT records stay DNS-only. With a CNAME-based CDN like Amazon CloudFront, you only repoint web hostnames, so your mail records never move at all.
The big exception is DNS hosting. Cloudflare's standard setup asks you to move your nameservers to it, and its CNAME setup is limited to Business and Enterprise plans. I'd treat that nameserver move as the riskiest moment for your mail.
Why Email Deliverability Drops After a CDN-Driven IP Change
If email breaks after a CDN move, I'd bet against the IP change being the culprit. The real causes are these:
- Records lost in a nameserver move. Cloudflare's own docs admit its quick scan doesn't catch every record and can miss custom DKIM selectors. Lose SPF or DKIM, and Gmail starts returning 550 5.7.26 for unauthenticated mail, while Outlook can reject high-volume senders with 550 5.7.515.
- SPF that leans on your website. If your web server sends mail and your SPF record uses the "a" mechanism, proxying the domain makes "a" resolve to the CDN's IPs, and SPF fails.
- Mail sent from the origin. Re-host or rotate the origin and that mail now leaves from an IP with no history and no PTR record. Gmail rejects mail from IPs without one.
- Leaving a CDN that handled your mail. Cloudflare Email Routing only works on Cloudflare DNS, and disabling it removes the MX, SPF and DKIM records it added.
There's a security side too. Running mail on the same server as your website leaks the origin IP through bounces and headers, which is one of the security risks for CDN operations that hiding behind a CDN is supposed to prevent.
How Long IP Warming Takes After a Shared IP Address Changes
If you send through a shared pool, you don't warm anything. Pool IPs can change at any time anyway, and providers like SendGrid and Amazon SES say shared-pool senders need no warm-up.
IP warming matters when mail now leaves from a dedicated IP or your own server:
Until then, every email spam filter treats you like a stranger. Mailgun says all mail from an unknown IP is initially suspicious. Expect greylisting, where servers answer with a temporary 4xx error and wait to see if you retry, along with Gmail rate limits if you ramp too fast. Start with engaged recipients and grow slowly. I'd plan around the slow end of these ranges, since mailbox providers don't care about your migration deadline.
How to Protect Email Deliverability When a CDN Migration Is Unavoidable
Treat email as a separate workstream inside the migration:
- Export your full DNS zone before moving nameservers, then compare it record by record after the move, DKIM selectors included.
- Keep every mail record DNS-only, and never put a CNAME on a name that also needs MX or TXT records.
- Rewrite SPF to name your real senders, using provider includes or explicit IPs instead of mechanisms that look up your web host.
- Move mail off your web origin, or set a PTR record and warm the new IP before sending at full volume.
- If your old CDN forwarded mail, add the new provider's records first and switch off forwarding last.
- Watch bounces for 5.7.26 or 5.7.515 for a few weeks, and keep spam complaints under Gmail's 0.10% target for bulk senders. The compliance dashboard in Google Postmaster Tools shows whether you still meet its bulk sender rules.