Guide · Business email · South Africa

Business email migration: a practical SME checklist

Moving email affects customers, suppliers, staff, websites, invoices and the devices people use between meetings. This guide helps an owner or operations lead plan the work in plain language, spot the risks and make the cutover verifiable.

For South African small and medium businesses · Technical guidance reviewed

Start here

The short version

Before anyone changes an MX record, make sure these questions have an answer. If an answer is unknown, it is a discovery task—not a reason to guess.

  1. 1Who owns the domain, DNS account and destination email tenant, and who can approve a change?
  2. 2Which mailboxes, aliases, shared addresses, forwards, devices and automated senders exist today?
  3. 3Which data must move: mail, folders, contacts, calendars, tasks, archives, signatures or only new mail?
  4. 4What is the staff communication, cutover window, overlap plan and route for urgent support?
  5. 5Have SPF, DKIM and DMARC been planned around every legitimate sender for the domain?
  6. 6Who will test customer replies, website forms, invoices, mobile access and shared inboxes after the change?

A useful mental model

Email is a business system, not just an inbox

A mailbox is where a person reads messages. The wider email system also includes the domain, registrar, DNS, sending services, shared addresses, contacts, calendars, archives, devices and the rules people follow. A migration that only copies visible messages can still leave an important business function behind.

In a small team, one person may be the director, bookkeeper and administrator. Another may answer sales enquiries from a phone. The plan needs to fit those realities: who approves a DNS change, who knows the website sends mail, and who can test a customer reply?

Good migration decisions are visible

  • A named decision-maker: someone can approve timing, scope and changes.
  • A current-state list: nobody relies on one person’s memory of every address and sender.
  • A written cutover: staff know what to do and when to stop using the old system.
  • A test record: send, receive, replies, devices and business systems are checked.

Step 1 · Discovery

Build an inventory before choosing a date

Use a simple spreadsheet or document. The goal is not bureaucracy; it is to make hidden dependencies discussable while the old system still works.

People and addresses

  • Every person’s mailbox and licence need
  • Aliases, distribution lists and shared inboxes
  • Forwarding rules, delegates and send-as permissions
  • Leavers, dormant accounts and addresses customers still use

Domain and accounts

  • Registrar, DNS host and current MX/TXT records
  • Current email provider, admin account and renewal details
  • Domain verification and recovery email or phone
  • Any subdomains that send or receive mail

Data and history

  • Mailbox sizes, folders and archive locations
  • Contacts, calendars, tasks and shared calendars
  • Retention or export requirements agreed by the business
  • Any local PST, OST, webmail or backup copies

Senders and devices

  • Website contact forms and transactional mail
  • Accounting, CRM, newsletter and booking tools
  • Phones, Outlook profiles, browser sessions and tablets
  • Printers, scanners, apps and integrations using SMTP

Do not confuse an address with a mailbox

A person’s mailbox, an alias, a shared inbox such as sales@, a forwarding rule and a group can behave differently. Record what each address is for, who needs access, where replies should go and whether it sends mail externally.

Step 2 · Data and destination

Decide what “migrated” means

Mail, contacts, calendars, tasks, signatures and archives do not all move in the same way. Write down what is required for each person and what will be exported, recreated, left in place or retained as a reference.

Mail folders

Decide whether historical mail is copied, archived, exported or kept temporarily in the source. Record the expected date range and folder coverage.

Calendars and contacts

Check the provider-specific path. Do not assume an IMAP copy includes collaboration data, shared calendars, contacts or tasks.

Local and shared data

Find PST/OST files, local downloads, shared drives and team archives. Assign an owner before a device is wiped or an old service is cancelled.

Important limitation: IMAP-based migration generally covers email folders, not every collaboration object. Microsoft’s official guidance says IMAP migration does not migrate contacts, calendar items or tasks, and requires destination mailboxes to be created separately. Check the destination provider’s current migration path for your source and data types before committing to a date.

Read Microsoft Learn’s mailbox migration overview ↗

Step 3 · Ownership

Keep the keys with the business

The domain registrar, DNS account and email tenant are business infrastructure. A consultant or staff member may configure them, but the business should know where they are, which email receives recovery notices and who can approve a sensitive change.

Use named accounts where the provider supports them. Keep admin access separate from ordinary mail access. Review old supplier access after handover. Store recovery information in the business’s chosen secure method rather than in an unprotected document or a departing employee’s inbox.

Ownership checklist

  • The business can sign in to the registrar and DNS host.
  • A named authorised admin owns the destination tenant.
  • Recovery details go to a monitored business-controlled address.
  • Billing, renewals and licence responsibility are recorded.
  • Supplier or former staff access is reviewed after handover.

Step 4 · DNS and authentication

Treat DNS as a controlled change

The place where the domain is registered, the place where DNS is managed and the place where mail is hosted may be three different accounts. Confirm each one. An MX record tells other mail systems where to deliver mail; TXT records are used for domain verification and sender-authentication controls.

MX

Directs incoming mail to the servers hosting the domain’s mailboxes. A cutover changes where new messages are delivered; it does not copy old mail by itself.

TXT

Carries text used for domain verification and email-authentication policies such as SPF and DMARC. Existing TXT records must be read before adding or replacing anything.

CNAME / provider records

Some platforms use provider-specific records for DKIM selectors, autodiscover or service verification. Use the destination provider’s current values.

TTL and timing

DNS caches mean different networks may observe a change at different times. Record the planned window and keep an agreed support overlap.

Do not copy a provider’s example records into a real domain without checking the exact destination, existing senders and DNS host format. A record that is correct for one provider or domain can be wrong for another.

SPF · DKIM · DMARC

Authentication should describe your real senders

A mailbox provider is often not the only system that sends as your domain. List the website, invoicing platform, CRM, newsletter service, scanner, relay and any other approved sender before changing policy.

SPF

Sender Policy Framework publishes which hosts are authorised to use a domain in the envelope-from or HELO identity. Keep one coherent SPF policy and include every approved sending service.

Google Workspace: set up SPF ↗
DKIM

DomainKeys Identified Mail uses a private signing key and a public DNS key. Receiving systems use the public key to verify the signature; the selector and provider record must match.

Google Workspace: set up DKIM ↗
DMARC

Domain-based Message Authentication, Reporting, and Conformance lets a domain publish policy and receive reports. It relies on aligned SPF or DKIM results, so it should follow a real sender inventory.

Google Workspace: recommended DMARC rollout ↗

Rollout caution: DMARC enforcement can affect legitimate mail that is not correctly authenticated or aligned. Google’s guidance recommends setting up SPF and DKIM first, monitoring reports, then increasing enforcement gradually when the sending picture is understood. Use that as a planning principle, not as permission to publish a policy without checking your own mail streams.

Read the DMARC RFC at the RFC Editor ↗

Step 5 · People and devices

Plan the device cutover, not just the DNS cutover

A new mailbox can be working on the server while a phone still checks the old account. Give each person a short, specific instruction and record which devices and apps have been updated.

Desktop mail

Update Outlook, Apple Mail or another client, remove the old profile only after data and access have been checked, and confirm the correct From address.

Phones and tablets

Add the new account, confirm notifications and test on the connection staff actually use. Check that old cached accounts do not keep sending.

Browsers and access

Test the webmail sign-in, MFA or recovery route, saved bookmarks and any shared-device sign-out practice.

Devices and apps

Update scanners, printers, website forms, accounting tools and integrations that send mail. Confirm the sender is included in authentication.

Printers, scanners, website forms and other apps may use their own SMTP settings. Google’s official device/app guidance notes that senders need to be accounted for in the domain’s SPF configuration. Include them in discovery rather than assuming “email” means only Outlook or Gmail.

Google Workspace: send mail from a device or app ↗

Step 6 · Cutover

Use a small runbook on the day

The exact sequence depends on the providers, but the responsibilities should be clear. Keep a copy available to the person answering staff questions.

  1. 1

    Brief

    Send the final instructions, confirm the owner and freeze unplanned account or DNS changes.

  2. 2

    Prepare

    Create or verify destination accounts, authentication records, devices and test addresses.

  3. 3

    Change

    Apply the approved DNS and provider changes, recording the time and exact values.

  4. 4

    Watch

    Run tests, answer staff questions, monitor expected mail streams and keep the agreed source overlap.

Tell staff

When to use the new sign-in, whether a password reset is expected, how to add the account to a phone, and where to report a missing message or failed send.

Do not promise instant propagation

DNS caches and provider processing take time. Keep the old service available for the agreed overlap or recovery period, and define who watches for late delivery and what “done” means.

Step 7 · Testing

Test the journeys your business actually uses

A green-looking admin console is not the same as a tested customer journey. Ask someone to perform each check and record the result, time and any follow-up.

TestWhat to verifyOwner
External receiveSend from an unrelated mailbox to a migrated address and confirm delivery to the destination.Operations
External send and replySend to an external recipient, reply to it and check the visible From address, reply-to and attachment.A mailbox user
Shared addressesTest delivery, access and reply behaviour for sales@, accounts@, info@ or other shared workflows.Team lead
Website and formsSubmit a real or controlled enquiry and confirm the notification, sender authentication and reply path.Website owner
Finance and systemsTest invoices, receipts, CRM notifications, newsletters and any other system listed in discovery.System owner
Mobile and desktopOpen, send, reply, search and attach from the devices staff use every day.Each device owner
AuthenticationInspect representative headers or provider reports for SPF, DKIM and DMARC results after the change.Email admin

Risk register

Name the likely failure before it happens

Most migration risks are manageable when they are visible early. This is a starting register; add the details that are specific to your domain and team.

A forgotten sender fails

What it looks like: A website, scanner or accounting system still sends through the old provider or appears in a recipient’s spam folder.

Reduce it by: Inventory senders, update their credentials or relay settings and test a real message after cutover.

The wrong person owns recovery

What it looks like: A recovery code or provider alert goes to a former employee, personal address or mailbox that is being migrated.

Reduce it by: Move recovery to a monitored business-controlled address and record the authorised owner before cutover.

Old and new mail are confused

What it looks like: A phone or desktop continues to check the old account, or staff keep replying from the old system.

Reduce it by: Give each user a device checklist and a clear stop-using-the-old-service time.

Data expectations are wrong

What it looks like: People assume contacts, calendars, tasks, archives or local files moved because some email folders did.

Reduce it by: Define data-by-data outcomes and test or export each required type.

Authentication is incomplete

What it looks like: Messages from legitimate tools fail SPF, DKIM or DMARC after the provider change.

Reduce it by: List every sender, publish the provider’s exact records and roll policy changes out with observation.

DNS timing surprises the team

What it looks like: Some networks deliver to the new service while another path still reaches the old service for a while.

Reduce it by: Schedule support overlap, document the change time and monitor both paths as agreed.

Step 8 · Handover

Finish with a usable record

A migration is not complete when the new inbox opens once. It is complete when the business knows what changed, how to operate it and what remains to watch.

Keep secrets in a secure password or access-management tool. The handover document can describe where access is held and who owns it without placing passwords in a shared email thread.

Handover pack

  • Final mailbox, alias, shared address and licence list.
  • Domain, DNS and provider ownership with named contacts.
  • The date and values of DNS and authentication changes.
  • Device, website and third-party sender status.
  • Test results, known issues and follow-up dates.
  • A safe route for account recovery and future access reviews.

Primary technical references

Read the provider and standards documentation

Provider screens and exact records change. These official sources explain the underlying steps and constraints; use the current instructions for your chosen destination and DNS host.

Need a second pair of hands?

Arlow helps South African SMEs discover the current setup, plan the migration, coordinate the cutover and verify the result. The work is scoped around your providers, people and systems.

Explore business email migration