What an MX change does
Prepare the new mail route and preserve the old one during the overlap, then change MX at the authoritative DNS provider.
MX chooses inbound mail hosts; it does not move old messages, create accounts or set outgoing clients. Prepare the new destination before changing it, and retain the old route during the previous TTL where providers permit. Otherwise senders may reach an unready or cached destination.
This procedure applies to a change of inbound mail provider for example.com. It does not assume that Novasean operates the mailbox or controls the domain’s DNS. Use the receiving provider’s exact MX hostnames and priorities; the names below are examples only.
Prepare both mail routes
- List all addresses and aliases that currently receive mail, including shared and automated mailboxes. Confirm that the new provider has created them and can accept mail for the domain.
- Export or preserve mail that must move from the old service using its supported migration method. DNS does not copy mailbox contents.
- Record current MX records, priorities, TTL and the authoritative DNS provider. Also inventory SPF, DKIM, DMARC and any provider verification records. Changing the whole DNS provider requires carrying unrelated web and mail records across.
- Arrange an overlap period with the old provider if possible, and make sure somebody can inspect delivery and bounce reports at both ends.
Where the DNS provider permits, lowering the MX TTL well before the cutover can shorten the later cache window. This only helps after caches holding the previous TTL have expired; it is not an instant flush.
Publish the intended MX set
At the authoritative DNS provider, replace the old MX set for the correct owner name with the complete set supplied by the new mail provider. Preserve each target and priority exactly. Lower numeric priority is preferred by SMTP senders; multiple equal-priority targets may be used for load distribution. Do not add the new provider’s MX behind the old one as an improvised safety net. A lower-priority backup host must be designed to relay or queue for the same mail system; an unrelated old host can accept and strand messages.
An MX target should be a hostname with suitable address records, not a raw IP address or a CNAME alias. For illustration, example.com MX 10 mail.example.com describes a target name; its actual value must come from the receiving provider. If the DNS panel asks for a relative name, inspect its final preview to avoid mail.example.com.example.com.
Update sending records as a separate task
Inbound routing and outbound authentication are distinct. If staff or applications will send through the new provider, amend the domain’s one SPF policy to cover authorised senders, publish the provider’s DKIM selector and check DMARC alignment. Do not delete an old sender from SPF until it has stopped sending. Existing DMARC reports and sample message headers help identify all active sources. The related SPF and DKIM guides cover those changes in detail.
Changing MX alone usually does not require changing the website A or AAAA record. If the old provider also hosts DNS, make sure the authoritative zone is still available after its mail subscription ends.
Check public DNS and actual delivery
Run dig MX example.com +short and query one delegated authoritative nameserver directly with dig @ns1.provider.example example.com MX +noall +answer. Replace the illustrative server name. Confirm all intended targets, priorities and address records. Then send test messages from at least two independent external senders to representative addresses and aliases. Verify arrival in the new mailbox, check headers or provider logs where available, and send replies to confirm outgoing configuration separately. Test a nonexistent recipient only if the provider’s handling is understood; do not infer successful delivery from an SMTP submission notice alone.
Send from an external mailbox to a unique test subject before and after the cutover; arrival at the new mailbox and a trace through the intended MX are stronger evidence than the MX lookup alone.
During the cache period, inspect both old and new mailboxes and their bounce reports. A sender that receives a temporary SMTP failure may retry according to its own policy; do not promise a fixed delivery time. Preserve a migration log of last messages seen at each provider.
If messages do not arrive
If authoritative MX answers are wrong, restore the saved set or correct the intended targets at the live DNS provider. If answers are right but the new service rejects mail, check domain verification, recipient creation and provider logs before changing DNS again. If the new service is unavailable, a rollback to the old MX set is useful only while that old service still accepts all required recipients; cached new answers may continue to reach the failing service for a while. Ask both providers to trace a sample message using sender, recipient, timestamp and message ID. Never send passwords or full private message contents as a first diagnostic step.
Common questions
Can I keep both providers’ MX records? Only when they are deliberately configured to handle the same domain and delivery flow. Priority is not a migration switch.
Does changing MX move historical mail? No. Migrate or export existing mail separately.
Why is mail still arriving at the old provider? A sending server may still hold the previous MX answer. Keep overlap monitoring until the observed transition is complete.
Does a new MX answer mean old mail cannot arrive? No. Senders may still use cached routes, so keep the previous destination available during overlap.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.