Moving mail servers between clouds without losing deliverability

Moving a mail server is straightforward technically and easy to get wrong for deliverability. Mailbox providers judge your mail partly on the sending IP’s history, and new addresses start with none. This article sets out how to plan the move, keep authentication aligned and protect your reputation while you do it.

Why mail is different from other workloads

A web server can change IP address with a DNS update and nobody notices. A mail server can’t. Receiving systems build a reputation for each sending IP from its volume, bounce rates, complaints and blocklist history, and they treat unfamiliar addresses with caution.

That leaves two broad options:

• Keep your existing IPs by bringing them to the new cloud through BYOIP, so their reputation comes with you.
• Move to new IPs and warm them up gradually while the old addresses carry most of the traffic.

Domain reputation matters as well, and it moves with you either way, provided authentication stays consistent.

Before choosing, check the target cloud’s policy on outbound SMTP. Many providers restrict port 25 by default or require a request before you can send directly, so build any approval into the plan.

Option 1: keep your addresses with BYOIP

If your mail servers already send from a block you hold, BYOIP is the most direct way to preserve reputation. AWS, Azure, Google Cloud and OVHcloud all support it, and the smallest prefix each accepts is a /24, so you need at least that much space of your own.

Points to plan for:

• Lead time. Provisioning is not instant; on Google Cloud it takes weeks. Start the registry work, including the ROA for the new provider’s ASN and its validation record, well ahead of the cutover.
• One cutover. A /24 should be announced from one place at a time. Once the announcement moves, old servers stop receiving traffic on those addresses, so plan a single window or keep a second /24 for parallel running.
• Reverse DNS. Confirm whether you keep running the zone or the provider takes it over, and that PTR records will be correct the moment traffic shifts.
• Reputation check. BYOIP preserves a bad reputation as faithfully as a good one. Check the block against blocklists and resolve listings before the move.

Option 2: warm up new addresses

If you are moving to provider-assigned addresses, plan a warm-up period rather than a hard switch. Mailbox providers notice a sudden jump in volume from an address they have never seen.

1. Configure the new servers with full authentication and correct PTR records before sending anything.
2. Start with a small share of traffic, ideally mail to engaged recipients who open and reply.
3. Increase volume step by step, watching deferrals, bounces and complaints at each stage.
4. Slow down or pause if a major mailbox provider starts deferring or filtering your mail.
5. Keep the old servers sending the remainder until the new addresses handle full volume cleanly.

There is no universal schedule. The right pace depends on your volumes and on how recipients respond, so let the data set the speed rather than a fixed calendar.

Keep authentication aligned throughout

Authentication that drifts during a move is an avoidable cause of rejected and filtered mail. Work through each layer:

• PTR. Each sending IP needs a PTR record that resolves to a hostname, and that hostname should resolve back to the same IP. Match it to the name the server uses in its HELO/EHLO greeting.
• SPF. Add the new IPs to your SPF record before the first message leaves the new servers, and keep the old ones until the move is finished. Watch the DNS lookup limit if you rely on includes.
• DKIM. Move the existing keys and selectors with the configuration, or publish a new selector in DNS before the new servers start signing. Don’t retire an old selector while mail signed with it may still be in transit.
• DMARC. Confirm that SPF or DKIM still aligns with the header From domain. Use aggregate reports to spot sending sources that start failing after the move.

Lower the TTLs on records you plan to change well in advance, so any correction takes effect quickly. Raise them again once the new setup is stable.

Monitor after the cutover

Deliverability problems can surface days after a move rather than minutes. For the first weeks:

• Read bounce and deferral messages for reputation-related responses.
• Check your sending IPs against the main blocklists every day.
• Review DMARC aggregate reports for unexpected failures.
• Use the postmaster tools that large mailbox providers offer, where available, to follow reputation and spam rates.
• Keep the old environment ready to take traffic back until you are confident in the new one.

How TACS can help

TACS can bring your sending block to a new provider through BYOIP, with ROAs, validation records and reverse DNS prepared in advance. Before and after the move, an IP security audit shows where your addresses stand, and our blacklist delisting service deals with any listings that appear.