Most email moves that go wrong do not go wrong at the switch. They go wrong a week earlier, when nobody wrote down that accounts@ forwards to two people, or a month later, when someone cancels the old subscription and an archive folder goes with it.

The switch itself is a few DNS changes and takes minutes. Everything that makes it safe happens around it. This is the order we work in when we move a business from one email provider to another, whether that is from Microsoft 365, Google Workspace, a web host's mail or an old server in the comms cupboard. It is written for a small business doing it themselves, or checking the work of whoever is doing it for them.

Why mail goes missing in a move

Email is delivered by looking up your domain. When someone sends to you@yourbusiness.com.au, their mail server asks the internet's directory, DNS, where mail for that domain should go. The answer is your MX record (mail exchanger). Change the MX record and new mail starts going to the new provider.

Three things make that less clean than it sounds:

  • Servers remember old answers. Each DNS record carries a TTL, a "remember this for" time. A sender that looked up your domain this morning may keep using the old answer until that time runs out.
  • Old mail does not move by itself. Changing the MX record only changes where new mail goes. Years of existing mail, folders, calendars and contacts stay where they are until something copies them.
  • Other systems send as you. Your website's contact form, your invoicing software, the office scanner and your newsletter tool all send mail that says it is from your domain. If they are not allowed for in the new setup, their mail starts landing in spam or bouncing.

Each step below deals with one of those.

Step 1: list everything you have

Before touching anything, write down what exists today. A spreadsheet is fine. This list becomes your plan for the new provider and your test sheet afterwards.

  • Mailboxes. Every real person who signs in. Include people who have left but whose mail you still need. Departed staff mailboxes are the ones most often forgotten.
  • Aliases. Extra addresses that deliver into someone's mailbox, such as jane@ also receiving j.smith@.
  • Shared addresses and groups. sales@, accounts@, info@. Note who receives each one, and whether people reply as that address.
  • Forwarding rules and auto-replies. Forwards to personal addresses, out-of-office messages, rules that file mail into folders. These live in the old system and do not usually come across.
  • Calendars. Personal calendars, shared calendars, room or vehicle bookings, and anyone who manages someone else's diary.
  • Contacts. Personal contacts and any shared address book.
  • Mailbox sizes. Big mailboxes take longer to copy. Knowing the largest one tells you how early to start.
  • Local archives. Mail stored only on one computer, in an Outlook PST file or a local folder. A server-to-server copy will not see it.
  • Everything else that sends as your domain. Website forms, accounting and invoicing software, CRM, booking systems, newsletter platforms, printers and scanners, alarm panels. Ask the people who use them.

Keep what you are required to keep

Email often holds business records: quotes, invoices, approvals, contracts. The ATO generally expects business records to be kept for five years. Treat the mail archive as a record, not clutter, and do not let the move become the moment it is quietly thrown away.

Step 2: find out who controls your DNS

You cannot move email without changing DNS records, so find out early who can. For a .com.au or .au domain, the domain is registered through an accredited registrar, but the DNS records might be managed somewhere else entirely: your web host, a previous IT provider, or the person who built your website years ago.

Log in and confirm you can see and edit the records before you plan a date. Note the current MX, SPF and any DKIM or DMARC records, and take a screenshot of the whole zone. If something goes wrong, that screenshot is how you put it back.

If nobody knows the login, sort that out first. Recovering access to a domain can take days, and it is not something you want to discover on cutover night.

Step 3: lower the TTL a few days ahead

The TTL on your MX record decides how long the rest of the internet keeps sending to the old provider after you change it. Many records sit at one hour, and some at a full day.

A few days before the switch, lower the TTL on the MX record (and on SPF and any mail-related records you will change) to around 300 seconds, which is five minutes. The trick is timing: the new, shorter TTL only takes effect once the old one has expired everywhere. If the old TTL was a day, lower it at least a day before the switch. Two or three days is a comfortable margin.

After the move has settled, put the TTL back up to an hour or more.

Step 4: copy the mail before the switch

Set up the new mailboxes, aliases and shared addresses from your list, then start copying existing mail across while the old system is still live. Nobody notices, because their mail is still arriving where it always has.

How you copy depends on where you are coming from:

  • Provider to provider. Most migrations use a tool that signs in to both the old and new mailbox and copies folder by folder, using the standard protocol all mail systems speak (IMAP). It can be run more than once and only copies what is new each time, which is exactly what you want.
  • From Microsoft 365 or Google Workspace. Both can be copied this way, but they often need a setting changed first, or an admin step to allow the copy tool to sign in, especially where multi-factor sign-in is on. Check this for one mailbox before planning the rest.
  • Calendars and contacts. These are not mail and are often copied separately, either by the migration tool or by exporting calendars (.ics files) and contacts (.vcf files) and importing them at the other end.
  • Local archives. Upload these into the new mailbox, usually by opening the archive in a mail app connected to the new account and moving the folders across.

Start this a few days ahead for anything large. A mailbox with fifteen years of attachments can take many hours, and some providers slow down bulk copying on purpose.

Step 5: the cutover

Pick a quiet time when someone will be around the next morning. A weekday afternoon or evening works well. Avoid the last days of the month, BAS week, or the day before a big tender closes.

At the cutover:

  1. Change the MX records to the new provider's values, and remove the old ones. Leaving an old MX record in place means some mail keeps going to the old system.
  2. Update the SPF record so it allows the new provider (more on this below).
  3. Add the new provider's DKIM record and any setup records they ask for, such as the ones that let phones and Outlook find the new server automatically. Remove the old provider's equivalents, or Outlook may keep finding the old account.
  4. Send test messages to each address from an outside account, such as a personal mobile, and confirm they arrive in the new mailbox. Reply to them and check the reply arrives too.

With a five-minute TTL, most senders follow the change within minutes. A few hold on longer. That is fine, because the old mailbox is still open.

Step 6: copy again after the switch

For a while after the cutover, some messages still land in the old mailbox: senders with stubborn caches, mail that was already queued, or someone who sent from a phone still set up on the old account.

Run the copy again the next day, and once more a few days later. Because it only copies what is new, each pass is quick, and it sweeps up anything that arrived late. This second pass is the difference between "we think we got everything" and knowing you did.

Step 7: set up phones and computers

Every phone, tablet and computer that had the old account needs the new one. Plan for this, because it is the part staff notice.

  • Add the new account before removing the old one. That way nobody is without mail for an afternoon.
  • Then remove the old account. Two accounts with the same address on one phone causes confusion about where a reply was sent from, and it keeps old calendars showing.
  • Outlook on Windows often works best with a fresh profile rather than editing the existing one. Old cached settings are a common reason Outlook keeps connecting to the old provider.
  • Check calendars and contacts on each phone, not just mail. They are separate settings, and on some phones they are switched off by default for a new account.
  • Re-create signatures, rules and out-of-office replies. These rarely come across with the mail.

Write a one-page guide for staff with screenshots for iPhone, Android and Outlook. It saves a lot of interruptions on the first morning.

Step 8: keep the old account for a while

Do not cancel the old service the day after the switch. Keep it for at least two to four weeks. In that time:

  • run the last copy pass,
  • check a sample of old messages, folders and attachments in the new mailboxes,
  • confirm calendars still show recurring meetings correctly, and
  • make sure nobody is still signing in to the old account out of habit.

Only then cancel. With most cloud mail services, cancelling starts the clock on deleting everything in the account, and getting it back afterwards is often impossible.

One calendar detail worth knowing: a recurring meeting you organised before the move may lose its connection to the attendees. People still have it in their calendars, but changes you make from the new account may not reach them. For important recurring meetings, it is often simplest to send a fresh invite from the new account.

Making sure your mail lands in the inbox

Receiving mail is half the job. The other half is making sure mail you send is trusted. The large mailbox providers, including Gmail, Yahoo and Outlook.com, now expect business mail to prove it really came from the domain it claims. Three DNS records do that.

RecordWhat it doesWhat to do in a move
SPFA list of the services allowed to send mail for your domainAdd the new provider. Keep every other sender you still use. Remove the old provider once nothing sends through it.
DKIMA digital signature on each message, checked against a public key in your DNSPublish the new provider's key and turn signing on. Your other sending tools have their own DKIM setup too.
DMARCTells receivers what to do with mail that fails the checks, and sends you reportsIf you have one, check it will not reject your own mail during the move. If you do not, add one in report-only mode.

A few rules catch people out:

  • Only one SPF record. A domain with two SPF records fails SPF entirely. Add the new provider to the existing record rather than creating a second one.
  • SPF has a lookup limit. Each "include" in an SPF record can trigger more lookups, and receivers stop checking after ten. A record that has collected every tool you have ever tried can quietly break. Clear out services you no longer use.
  • Every sending tool needs to be allowed. This is where the list from step 1 pays off. Each system that sends as your domain needs to be in SPF, have its own DKIM set up, or be changed to send through your new mailbox.
  • Start DMARC gently. A DMARC policy of p=none only collects reports. Read them for a few weeks, fix anything that fails, then tighten it to quarantine and finally reject. Going straight to reject during a move is a good way to block your own invoices.

Once these are in place, send a test message to a Gmail or Outlook.com address and look at the message details. You want to see SPF, DKIM and DMARC all marked as passed.

The mistakes we see most often

Cancelling the old account too early. The most expensive mistake, because it cannot be undone. Wait until the final copy is done and checked.

Forgetting the shared addresses. accounts@ and sales@ were set up years ago, nobody remembers they exist, and they stop working on the day of the move. Customers' remittances go nowhere.

Leaving the old MX record in place. Some mail keeps going to the old system for as long as it stays there, sometimes for months, unnoticed.

Not lowering the TTL, or lowering it too late. The move then takes a day to settle instead of minutes, and mail splits between two systems for that whole day.

Breaking the website contact form. The form sent as your domain through the old provider. After the move it fails quietly, and nobody notices the enquiries have stopped.

Two SPF records. Someone adds a new record instead of editing the old one, and every message you send now fails the check.

Missing local archives. The person who keeps ten years of client correspondence in a PST file on their laptop discovers it was never on the server, after the laptop is replaced.

The checklist

Moving business email, in order

  1. List every mailbox, alias, shared address, forward, calendar and contact book.
  2. List every system that sends mail as your domain.
  3. Find local archive files on every computer.
  4. Confirm you can log in to your DNS, and screenshot the current records.
  5. Set up the new mailboxes, aliases and shared addresses.
  6. Lower the TTL on mail records to about five minutes, at least a day ahead.
  7. Copy existing mail, calendars and contacts while the old system is live.
  8. At cutover: change MX, update SPF, add DKIM and the device setup records, remove the old provider's records.
  9. Send and reply to test messages for every address.
  10. Set up phones and computers: new account on, old account off.
  11. Run the copy again the next day, and a few days later.
  12. Update every other sending system, and check SPF, DKIM and DMARC all pass.
  13. Keep the old account for two to four weeks, check a sample, then cancel.
  14. Put the TTL back up, and move DMARC towards a stricter policy once reports are clean.

None of these steps is difficult on its own. What makes a move go smoothly is doing them in this order, and not skipping the boring ones at the start. If you would rather hand the whole thing over, NGN now hosts business email in Australia, and we move your mailboxes, calendars and contacts across for you as part of the setup. Or get in touch and we can look at your current setup first.

Frequently asked questions

Question not here? Ask an engineer →

How long does it take to move business email to a new provider?

For a small business, the hands-on work is usually a day or two spread over about a week. Most of that time is waiting: lowering the DNS TTL a few days ahead, letting the first copy of old mail run, and keeping the old account open for a few weeks afterwards as a safety net. The switch itself takes minutes.

Can emails go missing while the MX records change?

They should not, as long as both the old and the new mailboxes stay active during the changeover. For a short time some senders still deliver to the old provider because they remember the old MX record. Nothing bounces, it just lands in the old mailbox. A second copy pass after the switch picks those messages up and moves them across.

Why lower the DNS TTL before an email migration?

The TTL (time to live) tells other servers how long they may remember your DNS records. If it is set to a day, some senders keep using your old provider for up to a day after you change it. Lowering it to around five minutes, at least one full old TTL before the switch, means the change takes effect almost everywhere within minutes.

Do SPF, DKIM and DMARC need changing when you switch email providers?

Yes. SPF has to list the new provider, DKIM has to be set up with the new provider's key, and DMARC should be checked so it does not start rejecting your own mail. Also check every other system that sends as your domain, such as your website, invoicing and newsletter tools. Large mailbox providers now expect all three, and mail without them is far more likely to land in spam.

How long should a business keep its old email account after migrating?

Keep it for at least two to four weeks after the switch, and longer if anyone relies on very old archives. Run a final copy, confirm a sample of old messages, calendars and contacts made it across, and only then cancel. Cancelling a cloud mail subscription usually starts the deletion of everything in it.

Does an email migration copy mail that is only stored on my computer?

Not usually. A provider-to-provider copy moves what is on the server. Mail kept only in a local archive file on one computer, such as an Outlook PST file or an old "On My Mac" folder, is not on the server and has to be uploaded or imported separately. Check every computer for local archives before you start.