How to Move Email Hosting Separately From Your Website

To move email hosting without moving your website, you change only the DNS records that control mail delivery and leave the records that point to your web server untouched. The website keeps resolving to the same address because its A or AAAA records never change, while mail starts flowing to the new provider through new MX records and a new SPF policy.

The important mental model is that "your domain" is not one thing. It is a zone file full of records, and different record types answer different questions. Web traffic asks "where is the HTTP server?" Mail traffic asks "where is the SMTP server?" Those are separate questions with separate answers, and you can rewrite one answer without touching the other. The rest of this article is about doing that rewrite carefully, in the right order, so that no mail bounces and no web request fails.

Which records control mail, and which control the website

Your web host almost certainly told you to create an A record for the bare domain and a CNAME for www. Those two are the website. If you are moving email hosting without moving the website, you do not edit them at all. Write them down before you start, so you can confirm later that they are byte for byte identical.

Mail is controlled by a small set of record types. The MX records say which hostnames accept mail for the domain, and each one carries a preference number. Lower numbers are tried first. The TXT record at the root, or at a subdomain like _dmarc, carries SPF and DMARC policy. A CNAME or TXT record at a selector name such as selector1._domainkey carries a DKIM public key. The autodiscover and autoconfig names help mail clients configure themselves, and they are optional but convenient.

There is one trap worth stating plainly: an MX record must point at a hostname, never at a bare IP address. If your new provider gives you an IP and tells you to put it in an MX record, something is wrong with their instructions, because the record type does not permit it.

Start by reading the current zone

Before changing anything, capture the current state. Run a query against an authoritative nameserver rather than a caching resolver, so you see what the zone actually contains rather than what someone's resolver remembers.

dig +noall +answer example.com MX
dig +noall +answer example.com TXT
dig +noall +answer www.example.com A

The output shape you are looking for is a set of lines, each with a name, a TTL, a class, a type and the record data. The MX answer will show a preference number and a hostname. The TXT answer will show one or more quoted strings, which is where SPF lives. Save all of this to a file. When something breaks later, you will want to know exactly what the zone looked like before you touched it.

Pay attention to the TTL values in that output. A TTL is the number of seconds a resolver is allowed to cache the record. If your MX TTL is currently a day, then lowering it now, well before the cutover, is the single most useful preparation step you can take. A short TTL means your mistake is visible for minutes rather than hours, and your fix propagates just as quickly.

Lower the TTL before you change anything

Change the MX and SPF TTLs to something small, and wait for the old, long TTL to expire everywhere. If you skip the waiting, you will change the record and then watch a resolver somewhere keep serving the old value, which makes debugging confusing. During this window the records still point at your old provider, so mail is unaffected.

While you wait, set up the mailboxes on the new side. Create the accounts, and if the new provider supports it, start an initial sync or migration from the old server over IMAP. This matters because MX records only control delivery of new mail. They do nothing about the messages already sitting in your existing mailboxes. Those have to be copied separately, and copying them before the cutover means the final delta is small.

Cutting over the MX records

When the new mailboxes exist and the TTL has expired, replace the MX records. Delete the old ones and add the new ones in the same edit if your DNS interface allows it, so there is no window where the domain has no mail exchanger at all. Publish the SPF record that the new provider specifies, and add their DKIM key at the selector they give you.

A typical post-change zone looks roughly like this, though the exact values are yours to get from your provider:

example.com.     300  IN  MX   10 mail.provider-a.example.
example.com.     300  IN  TXT  "v=spf1 include:spf.provider-a.example -all"
sel1._domainkey  300  IN  CNAME sel1.provider-a.example.
www.example.com. 3600 IN  A    203.0.113.10

Note what did not change: the A record for www. That is the whole point. The website is still served from the same address by the same host, and nothing about the HTTP path is aware that mail moved.

If you were previously sending mail through your web host's server and your application uses that server as a relay, you have a second job. Applications that call sendmail or connect to localhost:25 will keep working only if the local MTA still relays, and it may now be relaying to a provider that no longer accepts mail for your domain. The fix is usually to point the application at the new provider's submission port with authentication. Look for a setting like SMTP_HOST, smtp_host or a mail configuration block in your application's environment file, and change the host, port and credentials together.

SMTP_HOST=mail.provider-a.example
SMTP_PORT=587
[email protected]
SMTP_TLS=starttls

Port 587 with STARTTLS is the conventional submission port. Port 25 is for server to server delivery and many networks block it for client use, which is why an application that worked on the old host may fail on the new one for reasons that have nothing to do with DNS.

Verifying the change and watching the headers

After the records are live, query them again and confirm the answers. Then send a test message from an outside account to an address on your domain, and read the full headers of the received message. The Received header is added by each server that handles the message, with the most recent hop at the top. If the topmost Received header names your new provider, delivery is going where you intended.

Send a message outward too, and check the Authentication-Results header on the copy that arrives. It reports the outcome of SPF, DKIM and DMARC checks. A passing result on all three is what you want. If DKIM fails, the selector name or the key value is wrong. If SPF fails, the include statement is missing a sending host. Do not leave the old provider's include in the record forever, but leaving it in briefly during the transition is harmless and avoids breaking anything still sending through the old path.

Keep the old mailboxes reachable for a while after the cutover. Mail sent to your domain by someone whose resolver still has the old MX cached will be delivered to the old server, and you want that message to land somewhere a human can find it rather than bounce. Once the TTL has fully expired everywhere and a few days of test mail have arrived cleanly, you can decommission the old service.

What to do next

Write down the current A, CNAME, MX, TXT and DKIM records and keep that file somewhere you can find it. Lower the TTLs and wait. Set up the new mailboxes and copy the old mail across before you touch MX. Change the MX, SPF and DKIM records together, then verify with a query and a real message whose headers you actually read. If you do those things in that order, the website never notices, and the worst case is a mail delay you can measure in minutes.