# How to change MX records without losing email

URL: https://iblockspam.com/blog/change-mx-records-without-losing-email
Last updated: 2026-10-09
Published: 2026-10-09
Topic: Switching & migration
Author: iBlockSpam Team

> A cutover checklist for MX changes: lower TTL, stage the new destination, keep the old server accepting mail, verify with headers and roll back cleanly.

## Short answer

Lower the MX TTL a day ahead, set up and test the new destination before touching DNS, then switch MX in one edit. Keep the old server accepting mail until the old TTL has expired and its queue is empty. Verify with headers from several outside senders, and keep the old records written down for rollback.

Changing MX records is a one-line DNS edit, but mail flow depends on caches, queues and server settings you don't see in that edit. This checklist keeps both the old and new destinations working during the change, so nothing bounces and nothing is dropped.

## Why can an MX change lose email?

When a sending server delivers to your domain, it looks up your MX records, sorts them by preference (lowest number first) and tries each one in turn ([RFC 5321, section 5.1](https://www.rfc-editor.org/rfc/rfc5321#section-5.1)). Resolvers cache the answer for the record's TTL ([RFC 1035](https://www.rfc-editor.org/rfc/rfc1035)). So for a while after the change, some senders deliver to the new MX and some still use the old one.

That overlap is harmless when both destinations accept and deliver mail. Problems come from:

- The old server being switched off, or told to reject the domain, too early.
- The new destination not yet knowing about the domain or its mailboxes.
- Lockdown rules (on Microsoft 365, Google Workspace or a firewall) applied before mail has moved.
- A typo in the new MX host, which can send mail nowhere at all.

Temporary failures (4xx) are less dangerous. RFC 5321 says senders should keep retrying, and that the give-up time "generally needs to be at least 4-5 days" ([section 4.5.4.1](https://www.rfc-editor.org/rfc/rfc5321#section-4.5.4.1)). Permanent failures (5xx) bounce immediately.

## What should you do before the change?

1. **Write down the current records.** Copy the exact MX hosts, priorities and TTLs, plus SPF, DMARC and any autodiscover records. This is your rollback plan.

2. **Lower the TTL.** Set the MX TTL to 300 seconds. Do it at least one full old-TTL period ahead (if the old TTL was 86400, a day ahead).

3. **Stage the new destination.** Add the domain at the new service, confirm the delivery target (your mailbox server) and send a test through it directly if the service allows.

4. **Check the mailbox side.** The final mail server must accept mail from the new path. On Microsoft 365, create the Partner inbound connector and Enhanced Filtering, but don't restrict it yet. On Google Workspace, add the inbound gateway IPs. On cPanel, set Email Routing to **Local Mail Exchanger**.

5. **List direct senders.** Apps, scanners and websites that deliver straight to the old server or tenant need a plan before any lockdown.

6. **Pick a quiet window.** Avoid month-end and other busy periods, and make sure someone can watch for an hour after.

## How do you make the switch?

1. **Edit MX in a single change.** Replace the old MX set with the new hosts and priorities. Avoid stepwise edits that leave the zone in a half-changed state.

2. **Don't leave the old MX listed.** A backup MX that skips the filter becomes the route spammers use. Keep the old server accepting mail instead of listing it.

3. **Never publish a null MX by mistake.** An MX of `0 .` tells the world your domain accepts no mail ([RFC 7505](https://www.rfc-editor.org/rfc/rfc7505)). Some DNS panels create it when a field is left empty.

4. **Check propagation.** Query the authoritative name servers first, then public resolvers. Our [MX Lookup](https://iblockspam.com/tools/mx-lookup) shows the public answer.

5. **Watch both sides.** Mail will arrive through both paths until the old TTL has expired. That's expected.

## How do you verify the cutover?

| Check | How | What good looks like |
| --- | --- | --- |
| Public MX | [MX Lookup](https://iblockspam.com/tools/mx-lookup) | Only the new hosts, correct priorities |
| Delivery path | Headers from 2–3 outside providers in the [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer) | The hop before your mail server is the new service |
| Authentication | `Authentication-Results` header | SPF and DMARC judged against the original sender, not the gateway |
| Old server | Its logs or message trace | Inbound traffic dropping to zero after the old TTL |
| Bounces | Ask a few contacts, check postmaster | No new non-delivery reports |
| Overall | [Email Health Check](https://iblockspam.com/tools/email-health-check) | No new warnings |

An MX lookup only shows where mail should go. It can't prove mail is filtered. The headers and logs are the evidence.

## What are the platform-specific steps?

The MX edit is the same everywhere: you change it at your DNS host. What differs is how the mailbox platform behind the filter must be told to trust the new path. Do these steps before the MX change, and leave every lockdown option off until the cutover is finished.

### Microsoft 365

Microsoft's guidance for this setup is explicit: "Your domain's MX record must point to your third-party service provider", and your SPF record keeps the standard Microsoft 365 value unless you also send outbound mail through the service ([Microsoft Learn](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/manage-mail-flow-using-third-party-cloud)).

1. **Find your delivery host.** The filtering service delivers to your tenant's own host name, such as `contoso-com.mail.protection.outlook.com`. It's the MX value Microsoft 365 shows for your domain; copy it from your notes before you change anything.
2. **Create a Partner inbound connector** for mail from the filtering service, identified by its certificate or IP addresses. Don't turn on the restriction to that certificate or those IPs yet.
3. **Turn on Enhanced Filtering for Connectors** for that connector, in the Microsoft Defender portal under **Email & Collaboration** > **Policies & Rules** > **Threat policies** > **Enhanced filtering**. Microsoft calls it "highly recommended", because without it every message appears to come from the filter's IP address ([Microsoft Learn](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/use-connectors-to-configure-mail-flow/enhanced-filtering-for-connectors)). Microsoft suggests testing it on a small set of users first, then applying it to the whole organization.
4. **Change MX** at your DNS host.
5. **Lock down later.** Once the old TTL has expired, set the connector to reject mail that didn't come from the filtering service.

Our [Microsoft 365 setup guide](https://iblockspam.com/blog/microsoft-365-third-party-spam-filter-enhanced-filtering) walks through each screen, and the [Microsoft 365 platform page](https://iblockspam.com/platforms/microsoft-365) lists the iBlockSpam-specific values.

### Google Workspace

Google's MX value is `smtp.google.com` with priority 1 for domains set up since 2023; older domains may still use the `aspmx` hosts, which Google still supports ([Google Workspace Admin Help](https://knowledge.workspace.google.com/admin/domains/set-up-mx-records-for-google-workspace)). Record whichever you have before you replace it.

1. In the Admin console, go to **Apps** > **Google Workspace** > **Gmail** > **Spam, Phishing and Malware**, select the top-level organization and edit **Inbound gateway**.
2. Add the gateway IP addresses and turn on **Automatically detect external IP**, so Gmail checks SPF against the real sender rather than the gateway.
3. Leave **Reject all mail not from gateway IPs** off for now.
4. Save. Google says gateway changes can take up to 24 hours to apply, so do this a day before the MX change ([Google Workspace Admin Help](https://knowledge.workspace.google.com/admin/gmail/advanced/set-up-an-inbound-mail-gateway)).
5. Change MX, wait for the old TTL to expire, send a test from outside and confirm it passed through the gateway. Then turn on the reject option.

Step-by-step screens are in our [Google Workspace inbound gateway guide](https://iblockspam.com/blog/google-workspace-inbound-gateway-setup), and the [Google Workspace platform page](https://iblockspam.com/platforms/google-workspace) covers the iBlockSpam values.

### cPanel/WHM

On cPanel the MX change and the routing setting live in the same account, and they interact.

1. **Set Email Routing first.** In cPanel, open **Email** > **Email Routing** and choose **Local Mail Exchanger**. cPanel's documentation says that with this setting "the server will always accept mail for the domain", and recommends it when a gateway filters your mail ([cPanel Docs](https://docs.cpanel.net/cpanel/email/email-routing/)).
2. **Avoid Remote Mail Exchanger.** With that setting the server doesn't accept mail for the domain locally and forwards it to the lowest-numbered MX, which would now be the filter, so mail the filter hands back to your server never reaches local mailboxes.
3. **Edit MX in the Zone Editor** (**Domains** > **Zone Editor** > **Manage**), but only if your server is the authoritative DNS host. If the domain uses external name servers, edit MX there instead.
4. **Check the queue** in **WHM** > **Email** > **Mail Queue Manager** before and after the change.

The [cPanel/WHM setup guide](https://iblockspam.com/blog/external-spam-filter-cpanel-whm) covers aliases, catch-alls and firewall rules, and the [cPanel/WHM platform page](https://iblockspam.com/platforms/cpanel-whm) lists our settings.

### Comparing the three platforms

| Platform | Trust the new path | Lockdown, after cutover |
| --- | --- | --- |
| Microsoft 365 | Partner inbound connector plus Enhanced Filtering for Connectors | Restrict the connector to the filter's certificate or IPs |
| Google Workspace | Inbound gateway with the filter's IPs | **Reject all mail not from gateway IPs** |
| cPanel/WHM | Email Routing set to **Local Mail Exchanger** | Firewall port 25 to the filter's IPs |

## When should you lock down the old path?

Only after the old TTL has expired and the old server's logs show no more inbound internet mail. Then apply the platform lockdown: a restricted Partner connector in Microsoft 365, **Reject all mail not from gateway IPs** in Google Workspace, or a port 25 restriction on your own server. See [Block direct-to-tenant bypass](https://iblockspam.com/blog/block-direct-to-tenant-bypass).

## What does a cutover-day timeline look like?

A typical change, with an old MX TTL of one hour:

1. **T minus 1 day:** lower the MX TTL to 300 seconds. Confirm the new value is served by the authoritative name servers.
2. **T minus 2 hours:** final checks. The new destination accepts a test message and delivers it to a real mailbox. The mailbox platform trusts the new path.
3. **T:** change MX. Note the exact time.
4. **T plus 5 minutes:** send tests from two or three outside providers. Some may still go the old way. That's fine.
5. **T plus 1 hour:** the old one-hour TTL has expired everywhere that respects TTLs. Most inbound traffic should now arrive through the new path.
6. **T plus 1 day:** check the old server's logs. A trickle from senders retrying deferred mail is normal; steady traffic suggests a stale cache or a sender ignoring MX.
7. **T plus 2 to 7 days:** apply lockdowns, restore a normal TTL, and decommission the old path.

## What about mail that is already queued?

Messages that senders deferred before the change will be retried later. Each retry repeats the MX lookup, so most land at the new destination. Messages your old server had already accepted, but not yet delivered to mailboxes, stay in its queue. Before switching anything off, check that its queue is empty. On cPanel/WHM, use **WHM » Email » Mail Queue Manager**; on Exchange Server, use Queue Viewer or `Get-Queue`.

## How do you roll back?

Rollback is the cutover in reverse, and the order matters.

1. **Remove lockdowns first.** If the old destination rejects direct mail, reversing MX will cause bounces.
2. **Restore the old MX records** from your notes, with a short TTL.
3. **Keep the new service active** until the TTL expires and its queue has drained. It will keep delivering mail that was already routed to it.
4. **Restore the normal TTL** (for example 3600) once things are stable.

## What are the common risks?

- **Long TTLs you forgot to lower.** A 24-hour TTL means up to a day of mixed routing.
- **Stale caches at large providers.** Some resolvers may hold records longer than the TTL suggests. Keep the overlap generous.
- **Subdomains and aliases.** Each domain or subdomain that receives mail has its own MX. Change all of them.
- **Changing SPF by reflex.** Inbound filtering doesn't require an SPF change. Edit SPF only if outbound mail changes.
- **Registrar vs DNS host confusion.** Edit the zone at the provider that is authoritative for the domain, which may not be your registrar. On Cloudflare, keep the mail hostname DNS only, as shown in our [Cloudflare email records guide](https://iblockspam.com/blog/add-dmarc-spf-dkim-records-cloudflare).

## How iBlockSpam helps

The iBlockSpam setup wizard shows your current DNS next to the target records, so you can see the exact change before you make it, and it gives you the rollback steps for your domain. During and after the cutover, if your mail server is unreachable, iBlockSpam holds mail for up to 5 days and delivers it when the server returns. Domain monitoring then alerts you if MX, SPF or DMARC records change unexpectedly (weekly on Protect, daily on Plus). The DNS edit itself stays in your hands, at your DNS host.

## Next steps

1. Write down your current MX, SPF and DMARC records today, and lower the MX TTL a day before the change.
2. Set up the platform side first: the connector in Microsoft 365, the inbound gateway in Google Workspace, or Email Routing on cPanel.
3. Check the public answer with the free [MX Lookup](https://iblockspam.com/tools/mx-lookup), and confirm the delivery path with the [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer).
4. Moving from another filter? The [guided cutover plan](https://iblockspam.com/migrate) and the other [migration guides](https://iblockspam.com/blog/topic/migration) cover the full switch.

Related: if the MX change is part of moving to a new filter, [how to switch spam filter providers](https://iblockspam.com/blog/switch-spam-filter-provider) covers the overlap period and quarantine hand-over.

## Frequently asked questions

### How long does an MX change take?

As long as resolvers cache the old record, which is set by its TTL. If the old TTL was 3600 seconds, expect up to an hour of mixed routing after the change. Lowering the TTL a day ahead shortens that window.

### Can mail be lost during the switch?

Mail is lost when a sender reaches a server that rejects it permanently, or accepts it and drops it. If both old and new destinations accept and deliver mail during the overlap, the change is safe. Temporary failures are retried by senders.

### Should I keep the old server as a backup MX?

Not after the cutover when you add a spam filter. Senders may use any MX listed, and spammers target low-priority MX hosts to avoid filtering. Keep the old server accepting mail during the overlap without listing it.

### Does changing MX affect sending or SPF?

No. MX controls inbound mail only. SPF lists the servers that send for your domain, so change it only if your outbound path changes.

## Sources

- [RFC 5321: Simple Mail Transfer Protocol (sections 4.5.4.1 and 5.1)](https://www.rfc-editor.org/rfc/rfc5321)
- [RFC 1035: Domain names, implementation and specification](https://www.rfc-editor.org/rfc/rfc1035)
- [RFC 7505: A "Null MX" No Service Resource Record](https://www.rfc-editor.org/rfc/rfc7505)
- [Microsoft Learn: Manage mail flow using a third-party cloud service](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/manage-mail-flow-using-third-party-cloud)
- [Google Workspace Admin Help: Set up an inbound mail gateway](https://knowledge.workspace.google.com/admin/gmail/advanced/set-up-an-inbound-mail-gateway)
- [Microsoft Learn: Enhanced Filtering for Connectors in Exchange Online](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/use-connectors-to-configure-mail-flow/enhanced-filtering-for-connectors)
- [cPanel Docs: Email Routing](https://docs.cpanel.net/cpanel/email/email-routing/)

## Free tools for this guide

- [MX Lookup](https://iblockspam.com/tools/mx-lookup): See where your mail is delivered, spot unfiltered backup MX and broken hosts.
- [Email Health Check](https://iblockspam.com/tools/email-health-check): Grade your domain's MX, SPF, DKIM, DMARC and transport security in one scan.
- [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer): Trace hops and authentication results — runs entirely in your browser.
- [SPF Checker](https://iblockspam.com/tools/spf-checker): Count real DNS lookups, find PermErrors, loops and risky "all" settings.

---

Source: iBlockSpam, https://iblockspam.com/blog/change-mx-records-without-losing-email (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt