How to move domain email to another provider safely

Moving the mail on your own domain to a new host is mostly DNS work, done in the right order. Do it in the wrong order and mail bounces or lands in the old inbox for days. Done right, nobody who writes to you notices anything, and you keep every old message.

How do you move domain email to another provider?

To move domain email to another provider, lower your DNS TTL first, add and verify the domain at the new host, recreate every address and alias, and copy your old mail across. Then point the MX records at the new host, update SPF, DKIM and DMARC, keep the old account open for a few days, test, and cancel last.

Why you keep your address when you change hosts

An address like you@yourcompany.com has two owners in practice. You own the domain, because you registered it. The email host only runs the mailbox. Your domain's DNS records tell the rest of the internet which host to deliver to, so changing host means editing those records, not changing your address.

That split is also why the move needs care. DNS answers are cached for a set time, so for a while some senders reach the new host and some still reach the old one. Every step below is built around that window.

The order at a glance

"Your DNS host" is wherever your domain's records live, often the registrar where you bought it.

Step 1: Lower your TTL a day or more before the switch

Every DNS record has a TTL (time to live), the number of seconds other servers may cache it. Google's DNS basics page gives the key detail: a change to a record with a TTL of 86400 seconds "will take up to 24 hours to go into effect", and a new, shorter TTL only takes effect after the old period expires.

So the timing works like this:

1. Look up the current TTL on your MX records at your DNS host.
2. Change it to 300 seconds (5 minutes). Google suggests 300 when you may need to change or revert a record quickly.
3. Wait at least as long as the old TTL. If it was 86400, wait a full day.

Now, when you change the MX in step 5, the internet catches up in minutes instead of hours. Cloudflare's TTL reference adds one caveat: a local DNS cache can take longer than the TTL to update, so treat 5 minutes as the floor, not a promise. Once everything works, Google recommends setting the TTL back to 86400.

Step 2: Add your domain at the new host and verify it

Every serious host asks you to prove you own the domain before it accepts mail for it. The usual method is a TXT record: the host gives you a unique value, you add it at your DNS host, and the host checks for it. Google's TXT verification page is a typical example of the flow.

This record does not touch mail delivery, so you can add it days ahead.

Step 3: Recreate every address and alias first

Before mail starts arriving at the new host, every address on the domain needs a home there. Microsoft's Microsoft 365 DNS guide tells admins to "add users and set up mailboxes" before updating the MX record "to ensure that email continues to work without interruption."

Make a list from the old host before you start:

• Every mailbox (you@, a partner, a shared inbox)
• Every alias that delivers into a mailbox (info@, hello@, billing@)
• Any forwarding rules
• Whether a catch-all is on, so mail to unknown addresses on your domain still reaches you

Then recreate the same set on the new host. A forgotten alias means bounces a week after the move.

Step 4: Copy your old mail across

Changing the MX record moves new mail only. Microsoft says it plainly on the same page: when you update the MX record, new email goes to the new host, and "any existing email stays at your previous email host."

So the history needs its own trip. Check your old host's settings for an export option first. Look for downloads in MBOX, EML or PST, the standard mailbox formats. If your old mail lives in a Google or Microsoft account, our guides cover the exact screens:

• Google: the Takeout export in our guide to switching from Gmail
• Microsoft: our walkthrough on exporting emails from Outlook to a .pst file

You can run the export before the switch and a second, smaller one after, to catch anything that arrived at the old host during the overlap.

Step 5: Switch the MX records

The MX records are the switch. At your DNS host:

1. Add the MX record or records your new host gives you, with the priority it specifies.
2. Remove the old host's MX records.

Do not leave the old ones in place "just in case." Google's MX setup page says to "remove any other MX records" because your email "might not work correctly if you keep old or incorrect MX records." Microsoft allows one alternative, setting the old MX to a lower priority (a higher number), but removing it is cleaner.

Google warns that MX changes can take up to 72 hours to take effect everywhere. With the TTL lowered in step 1, most of the internet follows in minutes.

Step 6: Update SPF, DKIM and DMARC

These three records decide whether mail you send from the new host is trusted. Get them wrong and your replies land in spam.

SPF. SPF lists the servers allowed to send for your domain, in one TXT record that starts with v=spf1. One record, not two. The SPF standard, RFC 7208, says a domain "MUST NOT have multiple records," and a receiver that finds more than one returns an error (permerror). Google's SPF page puts it as "each domain must have its own SPF record."

During the move, edit the existing record instead of adding a second one. If the old host is still sending, both can sit in one record, like Google's own example:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

Once the old account no longer sends, remove its include:. This keeps you clear of the other SPF trap. RFC 7208 limits each check to 10 terms that cause DNS lookups (include, a, mx, ptr, exists and redirect), and nested includes count too. Old includes left behind from past hosts are a common way domains go over the limit and fail SPF entirely.

DKIM. DKIM signs your outgoing mail with a key published in DNS under a name like selector._domainkey. Google's DKIM page uses google._domainkey as the default. Each host uses its own selector, so the new host's DKIM record sits next to the old one without conflict. Add the new one, then delete the old host's record once it stops sending.

DMARC. Your DMARC record lives at _dmarc.yourdomain.com and is not tied to a host, so it usually stays. Check the policy before you switch, though. Under RFC 9989, the current DMARC standard published in May 2026, a message passes DMARC if SPF or DKIM aligns with your domain. If your policy is p=quarantine or p=reject, the new host's SPF and DKIM must be working before you send anything from it, or receivers may junk or refuse your mail. The RFC also says domains at p=reject must sign with DKIM rather than lean on SPF alone. Google suggests letting SPF and DKIM authenticate for 48 hours before you tighten DMARC. If you have no DMARC record at all, add one with p=none, which the RFC describes as offering "no expression of preference," and tighten it later.

Step 7: Keep the old account open during the overlap

For a while after the switch, some servers still hold the old MX record in cache and deliver to the old host. Keep the old account paid and reachable for at least a few days, longer if your TTL was high or you skipped step 1. Check the old inbox daily. When it goes quiet, run that last small export from step 4 and import it.

Step 8: Test before you cancel

Do not wait and hope. You can see what the rest of the internet sees from a terminal. On a Mac or Linux:

• dig +short MX yourdomain.com shows the mail servers the world gets for your domain
• dig +short TXT yourdomain.com shows your SPF record (check there is exactly one line starting with v=spf1)
• dig +short TXT _dmarc.yourdomain.com shows your DMARC record

On Windows, nslookup -type=mx yourdomain.com does the same for MX.

Then send real mail both ways:

1. From a personal account at another provider, write to each address and alias on your domain.
2. Reply from the new host to that personal account.
3. Open the received message's headers and look for spf=pass, dkim=pass and dmarc=pass. Our email header analyzer reads these for you, and our guide to reading email headers explains each line.

Step 9: Cancel the old host last

Cancel only when the old inbox has been empty for several days, every test passes, and your final export is imported. Then remove the old host's leftover DNS records: its DKIM record, its include: in SPF, and any verification TXT records it asked for. Finally, set your TTL back to a normal value.

Frequently asked questions

Will I lose emails when I change email hosts? Not if you follow the order. New mail is never lost when the new mailboxes exist before the MX change and the old account stays open during the overlap. Old mail stays at the old host until you copy it, so export it before you cancel.

How long does it take to move domain email? The hands-on work is an afternoon. The waiting is set by your TTL. With it lowered to 300 seconds a day ahead, the switch itself takes effect in minutes for most senders, though Google allows up to 72 hours for MX changes everywhere.

Do I need to transfer my domain to the new email host? No. The domain can stay at the same registrar. You only edit its DNS records. Moving the domain registration is a separate job and is not needed to change email hosts.

Will my website go down when I change email providers? It shouldn't. Websites use A, AAAA or CNAME records, and an email move changes MX and TXT records. Leave the other records alone. One exception: if you move your whole DNS to a new DNS host, copy every record across first.

Do people need my new email address? No. Your address stays exactly the same. Only the server behind it changes, so nobody has to update anything.

Moving your domain to Secria

If you are moving to Secria, custom domains come with Mail Plus ($3.99 a month, up to 3 domains) and Pro ($9.99 a month, up to 10 domains, VPN included), with no business plan needed. Open domain settings, enter your domain, and Secria gives you a TXT record to prove you own it. Then add the MX, SPF, DKIM and DMARC records Secria shows. Each has a copy button, and Secria checks them for you. Give verification 5 to 15 minutes, sometimes longer.

You can set up aliases on your domain and a catch-all address per domain, which covers step 3. For step 4, go to Settings, then Import & export, then "Bring mail in." It accepts MBOX, EML, PST and .zip files, encrypts your mail in your browser before upload, and keeps the original dates. Import is on every plan. Your mailbox is protected with ML-KEM-1024 together with X25519, tracking pixels are removed automatically and senders never see your IP address, and Secria shows no ads and never mines your mail. See pricing or create an account to start the move.