SMTP relay migration planning for growing teams

What a relay migration actually involves

On the surface, migrating an SMTP relay looks simple: update some credentials in your applications, change an MX or submission hostname, and you are done. In practice, the change affects three layers simultaneously, each with its own failure modes.

The first layer is configuration. Every application that submits mail to the old relay has to learn about the new one. For a small team this might mean updating a single environment variable; for a growing team it usually means tracking down eight or twelve applications that nobody owns anymore, some with credentials hard-coded into configuration files dating back three years.

The second layer is network identity. The new relay sends from different IPs, often from different network ranges, often with different PTR records and HELO hostnames. Inbox providers will see a fundamentally different sender when the mail starts flowing through the new path. Your SPF records, your DKIM keys, and your DMARC alignment all have to account for that shift before any mail moves.

The third layer is reputation. The old relay's IPs had a reputation history that took months to build. The new relay's IPs either inherit something from previous use or start from zero. Either way, the inbox providers you send to will treat the new path as an unknown entity for some period of time, and that treatment is where avoidable deliverability damage happens if the migration is done carelessly. The underlying mechanics of how inbox providers track and score senders are covered in sender reputation fundamentals.

The right reasons to migrate, and the wrong ones

Before committing to the operational cost of a migration, the team should be explicit about what is driving it. The right reasons produce better outcomes; the wrong ones produce migrations that fail to solve the underlying problem because the problem was not actually relay-related.

The pattern that catches teams: they are unhappy with deliverability, they blame the relay, they migrate, and the deliverability problem follows them to the new provider because the actual cause was list hygiene or content-driven complaints. Migration fixes infrastructure problems; it does not fix program problems. Identifying which category the actual issue falls into is the first job, and it should happen before migration planning begins.

Taking inventory before anything moves

The single most overlooked step in a relay migration is the pre-migration inventory. Teams assume they know what sends through the current relay; teams are reliably wrong about this. The inventory discovers services nobody has touched in three years, hardcoded credentials in forgotten repositories, and integrations that were set up by people who have since left. Finding these during planning is cheap; finding them during cutover is expensive.

The inventory that actually catches things

1. Query the current relay's logs for a full month. Extract unique authentication credentials, source IPs, sending domains, and sample From addresses. Every credential is a sender; every sender is a thing that needs to know about the new relay.
2. Map each credential to an owning application or team. Some will be obvious. Some will require detective work. Any credential that cannot be traced to a known sender is either an abandoned service or a compromised credential — both need investigation, not migration.
3. Catalog every sending domain and its current DNS records. SPF includes, DKIM selectors, DMARC policies, MX records for reply handling. Each is a thing that has to be checked and possibly updated as part of the migration.
4. Measure current volumes per application. Peak daily, typical daily, burst patterns. This informs how you warm up the new relay's IPs and how much dual-running capacity you need.
5. Document every authentication method in use. SMTP AUTH with username/password, IP-based allowlisting, mTLS, API keys for vendor-specific variants. Each method has to be supported by the new relay or explicitly migrated to a different method.
6. Identify legacy and third-party senders that depend on the relay. Scanners, ERP systems, billing platforms, monitoring tools, vendor integrations. These are the ones that nobody wants to touch, and they are the ones most likely to break during cutover.

The five-phase plan that avoids surprises

A relay migration runs cleanly when it follows a predictable phase structure with explicit exit criteria at each phase. Phases that bleed into each other produce the kind of confusion where nobody is sure whether something has been done or not.

The total runway for a properly executed migration is thus eight to sixteen weeks. Teams that compress this to two weeks usually make it work, but they trade deliverability risk for calendar speed. Teams that try to do it in a weekend produce exactly the kind of migration that generates support tickets for months afterward.

Who owns each phase

Phase ownership matters because migrations touch multiple teams and the handoff points are where things slip. The operations team typically owns Phases 2, 4, and 5. Application teams own their own updates in Phase 4. Deliverability owns Phase 3 (and participates in Phase 4). Security should review Phases 1 and 2 for credential handling. Product and support should know Phase 4 is happening so they can connect dashboard dips to a known cause rather than investigating as an incident.

TTL strategy: the timing layer that controls everything

DNS caches everywhere between your authoritative servers and the recipients that deliver to your domains. The TTL value on each record determines how long those caches are valid, and consequently how long a DNS change takes to propagate globally. For a migration, TTL strategy is the lever that lets you move traffic quickly when everything goes right and recover quickly if something goes wrong.

The common mistake: lowering TTL on cutover day itself. Resolvers that had already cached the old TTL value will respect that TTL before they even learn about the new lower value. A TTL change ten minutes before a DNS cutover gives you none of the control you thought you had. The change has to be in place for at least the old TTL duration before you get fast propagation on subsequent changes.

dig verification# Before lowering TTL — verify current value
dig +noall +answer MX example.com
# example.com. 3600 IN MX 10 relay-old.example.com.

# After lowering TTL to 300 — confirm authoritative returns 300
dig +noall +answer @ns1.yourdns.com MX example.com
# example.com. 300 IN MX 10 relay-old.example.com.

# Check multiple resolvers to confirm propagation
for ns in 8.8.8.8 1.1.1.1 9.9.9.9 208.67.222.222; do
  echo "=== $ns ==="
  dig +noall +answer @$ns MX example.com
done

Running old and new in parallel

The cleanest relay migrations run both the old and new relays simultaneously during the cutover window. This eliminates the big-bang failure mode where everything flips at once and nobody knows which piece broke. Parallel operation lets you move traffic progressively and observe each step.

Three patterns for parallel operation

The credential-based split is usually the easiest to reason about and the safest to roll back. Each application's cutover is a single deployment of new SMTP credentials; if something goes wrong with a specific application, you revert that one application without affecting others. This is the pattern that almost always works for relay migrations of any complexity.

The progressive migration sequence

1. Week 1: lowest-stakes internal senders. Cron jobs, internal reports, monitoring alerts. If anything breaks, you have time to fix without customer impact.
2. Week 2: high-volume but forgiving workloads. Marketing sends go through the new relay. Volume builds new relay reputation; failures are recoverable.
3. Week 3: transactional mail. Password resets, receipts, notifications. Moved after the new relay has proven itself on lower-stakes traffic.
4. Week 4: legacy and third-party integrations. ERP, billing systems, scanners. These are the hardest to move and benefit most from a thoroughly validated new relay by this point.

Authentication parity: SPF, DKIM, DMARC on the new relay

Authentication is where migrations silently fail. The mail keeps flowing, the logs show 250-OK on outbound, and deliverability slowly degrades because SPF doesn't include the new relay's IPs, or DKIM is signing with a selector that isn't published, or DMARC alignment is breaking in a way the team doesn't notice until someone reports that Gmail is sending everything to spam.

The parity checklist for every sending domain

DNS parity per sending domain# --- Before migration: current SPF (old relay only) ---
example.com.  IN  TXT  "v=spf1 include:spf.oldrelay.com ~all"

# --- During parallel phase: SPF authorizes BOTH relays ---
example.com.  IN  TXT  "v=spf1 include:spf.oldrelay.com include:spf.newrelay.com ~all"

# --- Post-migration: SPF authorizes NEW relay only ---
example.com.  IN  TXT  "v=spf1 include:spf.newrelay.com ~all"

# --- DKIM: new selector published BEFORE new relay starts signing ---
ahk2022._domainkey.example.com.  IN  CNAME  ahk2022.dkim.newrelay.com.

# --- DMARC: tighten only AFTER parity is verified ---
_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
# Observation mode during migration
# Tighten to p=quarantine only after 14+ days of clean aggregate reports

The four authentication questions to answer for every domain

The operational cost of getting authentication parity wrong is significant: degraded inbox placement that takes weeks to recover, spam folder placement for some recipients, DMARC failures showing up in aggregate reports that should have been clean. The cost of getting it right is a couple of hours per domain of careful DNS editing and a verification pass with a test send. The tradeoff is strictly in favor of taking the time. For the deeper treatment of how to keep authentication coordinated across multiple domains — which is exactly what a migration across an organization's sending surface requires — see authentication alignment and policy review for multi-domain senders.

Cutover day: the choreography

Even with weeks of careful preparation, cutover day has its own rhythm. A run-book that handles the sequence and the verification steps is the difference between a smooth flip and a scramble. Below is the choreography that works.

1. T minus 2 hours: team assembly. Ops team, deliverability, at least one representative from each application team with a stake. On a call or in a chat room that stays open for the full window.
2. T minus 1 hour: final verification. New relay is receiving test sends successfully. Authentication is green on the new relay per all test domains. Current traffic through the old relay is nominal.
3. T minus 30 minutes: traffic freeze on non-critical senders. Pause scheduled campaigns, batch jobs, anything that can be delayed briefly. This reduces the cutover blast radius.
4. T=0: primary DNS change. Update MX and relay-pointing records to new relay. With 300-second TTL, global propagation takes 5-15 minutes.
5. T+5 min: verification wave. Test sends from multiple external senders to domains you control. Confirm mail routes through new relay. Check authentication headers.
6. T+15 min: application cutover. Applications that hold credentials for the old relay switch to new relay credentials. Staged deploys by application team.
7. T+30 min: resume scheduled traffic. Campaigns, batch jobs, monitoring alerts resume their normal schedule through the new relay.
8. T+1 hour: first health check. Delivery rate, bounce rate, deferral rate, authentication pass rate, old relay traffic volume. Any of these off-baseline triggers investigation.
9. T+4 hours: secondary health check. Same metrics; also check Google Postmaster Tools and Microsoft SNDS for early signals.
10. T+24 hours: first real assessment. The daily-cadence metrics have had time to move. If everything is green, the cutover is considered successful and the team can stand down from active monitoring.

Verification that goes beyond "seems fine"

The single most common post-migration claim is "it seems to be working." The single most common follow-up three weeks later is "actually there was a problem we didn't notice." Thorough verification closes this gap by checking each layer explicitly rather than relying on the absence of complaints.

Rollback: planning for the worst responsibly

Every good migration plan includes a rollback plan, and every good team hopes never to use it. The rollback is the safety net that makes risk-taking during the migration acceptable. Having it documented and rehearsed before the cutover — not improvised during an incident — is what separates teams that recover quickly from teams that extend an outage through uncertainty.

The three rollback tiers

1. Partial rollback: revert a single application. If a specific application is failing after cutover, revert only that application's credentials to the old relay. The rest of the migration continues. Fast and low-impact; this is the right response to ~70% of post-migration issues.
2. DNS-level rollback: revert MX records. If the broader cutover is producing unacceptable delivery problems, revert MX records to the old relay. With 300-second TTL in place, this propagates in minutes. Requires the old relay to still be operational, which is why Phase 5 decommissioning is the last phase.
3. Full rollback: all traffic back on old relay. Both DNS and application credentials revert. The migration is paused. Root cause investigation happens while service is stable on the old path; a second cutover attempt is scheduled after findings are addressed.

Post-migration: the two weeks that matter

The cutover is not the end of the migration. The two weeks after are when latent issues surface: reputation drift from the new IPs not quite matching the old ones, integrations that were broken for days before anyone noticed, DMARC aggregate reports showing unexpected sources, deliverability dips at specific providers that didn't show up immediately. The team that stays engaged during this period catches these things; the team that moves on to the next project discovers them later when the cost is higher.

The daily check for the first ten days

If any of these metrics deviate from baseline by more than a small amount, the team investigates before the trend consolidates. A one-day spike in spam rate might be noise; three days of elevated spam rate is a reputation event in progress. The daily cadence catches the difference; the weekly-only cadence does not.

What to decommission, and when

Week 1 post-cutover: nothing. Keep the old relay fully operational; it is your rollback option.

Week 2 post-cutover: if all metrics are stable, stop sending test traffic to the old relay but keep the subscription active. Verify the old relay has seen no production mail for seven consecutive days.

Week 3 post-cutover: contact the old relay vendor and schedule the account closure. Most vendors have a notice period; align the closure date with your current billing cycle.

Week 4 post-cutover: old relay account closed. Archive any accounting logs you need to retain. Remove the old relay's SPF include from all your domains. Update documentation to remove references to the old relay. Final state verified; migration officially complete.

Frequently asked questions

How long should the whole migration take?

Eight to sixteen weeks is the realistic range for a mid-sized deployment. Compressed schedules (four to six weeks) are possible if the team is experienced and the current relay is a pure pain point. Under four weeks is not responsible for production workloads.

Do we need to warm up the new relay's IPs if the current relay also used shared IPs?

If the new relay uses shared IPs with an established reputation, you skip most of the IP warmup. If the new relay assigns you dedicated IPs, you need the full four-to-eight week warmup for those IPs regardless of what the old relay was using.

Should we change our sending domain during the migration?

No. Change one variable at a time. If the migration goes wrong, you want the ability to diagnose whether the issue is with the new relay or with your domain reputation, and changing both at once makes that diagnosis impossible.

What if an application's owner is unavailable during the migration window?

Don't migrate that application. Wait for the owner. A forced migration of an ownerless application is how previously-working integrations break, and the breakage is invisible until someone notices missing mail weeks later.

How do we handle an application that's on a vendor's managed platform and can't be migrated to our new relay?

Two options: either accept that the application will continue using the vendor's email service (and document that fact so it doesn't create confusion during future audits), or negotiate with the vendor to add support for custom SMTP credentials. Most major vendors support this; smaller vendors sometimes do not.

Should we migrate during a freeze period (end of year, major release, etc.)?

No. Change freeze periods exist for a reason. Schedule the migration for a period when the surrounding business environment is stable and the team has bandwidth to respond to issues.

What if we need to migrate urgently (security incident, vendor breach, etc.)?

Emergency migrations do happen. The compressed version of this process: skip the warmup phase (accept some deliverability risk), compress the parallel phase to 48 hours, use heavily shortened TTLs, and plan for a week of active firefighting post-cutover. The normal process is strictly better; the emergency version is what you do when the choice is between imperfect migration and ongoing risk exposure.

Closing perspective

A relay migration is change management more than it is engineering work. The technical steps — updating DNS, rotating credentials, verifying authentication — are individually straightforward. What makes migrations succeed or fail is whether the team treats them as production changes with the discipline that applies to other production changes: inventory, planning, staged rollout, active monitoring, rollback planning, post-mortem review. Teams that apply that discipline have uneventful migrations. Teams that don't have interesting ones, and interesting is the wrong adjective for anything that touches customer-facing email delivery.

The economic case for doing this carefully is worth restating. A weekend migration that goes wrong costs multiple weeks of engineering time to recover from, plus whatever deliverability damage accrues during the recovery window. A planned eight-to-sixteen week migration costs several engineer-weeks across its duration but produces a clean outcome with no lingering issues. The first path looks faster on paper; the second is almost always faster in total.

There is also an organizational angle. Migrations that go well build institutional confidence and documentation that pays off on future changes. Migrations that go poorly produce the opposite: team distrust of the infrastructure, reluctance to change anything else, and patterns of working-around-the-migration-scars that compound over time. The investment in doing the first migration well pays for itself across the next several.

For teams starting their first relay migration, the shortest honest advice is: start the inventory this week, whether or not you've decided to migrate. Knowing what sends through your current relay is useful regardless of whether you change providers. If the inventory reveals something surprising, you have time to address it. If it confirms everything is as expected, you have a clean starting point for the migration plan. The inventory is the one step that never gets wasted, and it is the one step that most teams skip.