Reading business email setup with a sceptical eye

Setting up email on your own domain is easy. The wrong order is what makes it hard, and that order causes most of the trouble.

Authentication gets configured after mail is already flowing. A cutover happens before anyone finds the systems that send as the domain. A catch-all address enabled for convenience becomes a spam magnet nobody can switch off.

This is the sequence, with the reason each step comes where it does.

What to take away

Phase 1: decisions to make before you touch DNS

None of these are technical, and all of them are hard to change later.

Choose the service before touching DNS. Hosted business email options include Microsoft 365, Google Workspace, Fastmail, and Zoho Mail; this guide covers the setup sequence rather than comparing product features.

The address format. First name only, first and last, initial and surname, something else. Pick one and write it down, including what happens when two people collide and what happens to contractors. Every business card, signature, form, and external contact will encode this choice.

Which addresses are people and which are roles. A role address (inquiries, accounts, support), belongs to a function, not a person. Deciding this up front matters because role addresses need a different mechanism from personal ones, and retrofitting is disruptive to whoever has been receiving that mail personally.

Who owns the domain registration. Not the email service, and not the same thing as the hosting arrangement underneath it. The domain itself. If it sits in a personal account belonging to someone who once built the website, fix that before you build anything on top of it. Losing control of the domain means losing control of the mail, permanently and completely.

Whether you are migrating or starting fresh. If mail already exists somewhere, the setup sequence changes: you will need a period where both systems are reachable, and you will need to decide what happens to mail sent to the old system after the switch.

Phase 2: inventory everything that sends as your domain

Do this before the cutover, because after it these are the things that break silently.

Walk the list:

Any item on this list that sends as your domain must be authorized, or its mail may be rejected once you tighten authentication. The list may be longer than anyone's first guess, which is why it belongs before the DNS work rather than after.

Phase 3: DNS, in the right order

MX records direct inbound mail to your provider. Changing them is the switch itself.

Before you change anything, lower the time-to-live on the existing records. TTL tells the rest of the internet how long to cache your DNS, and lowering it on the day of the change achieves nothing: the old, long value is already cached everywhere. Lower it well in advance, make the change, confirm it, then raise it back.

Do not run two sets of MX records for the same domain during a transition. Mail will be delivered to both, and neither mailbox will be complete. If you need a period of overlap, arrange it as deliberate forwarding from one system to the other, in one direction only, and check that nothing forwards back: a mail loop between two systems generates a great deal of traffic very quickly.

Set up the mailboxes at the destination before the MX change, so that mail has somewhere to land the moment it starts arriving.

Phase 4: authentication, in three steps

SPF, DKIM, and DMARC determine whether recipients can verify mail sent using your domain. Configure them in that order: DMARC builds on the other two.

SPF is a single DNS record listing which servers are allowed to send mail for your domain. Two rules trip people up: you may only have one SPF record for a domain, publishing a second breaks both, and the record has a strict limit on how many DNS lookups it is allowed to trigger during evaluation. Every third-party sender you include consumes part of that budget, and exceeding it makes the whole record fail rather than fail gracefully. This is the reason Phase 2 exists: you need the full sender list before you can build a valid record, and adding senders one at a time is how a domain silently exceeds the limit.

DKIM attaches a cryptographic signature to outgoing mail, with the matching public key published in DNS. Your provider generates the key pair and tells you what to publish. The thing to check afterwards is that signing is actually enabled for the domain, not merely available: publishing the key without switching signing on is a common half-finished state.

SPF is specified in RFC 7208, DKIM in RFC 6376, and DMARC in RFC 7489. For operational guidance, consult DMARC.org and the Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG). These are published mechanisms, not vendor features; read the relevant guidance before publishing records.

DMARC ties the other two to the address recipients actually see, and tells receiving systems what to do when a message fails. Publish it in this order:

Skipping straight to a strict policy is how an organization discovers its invoicing system was never authorized: invoices start being rejected.

Phase 5: mailboxes, aliases, and shared addresses

Three different mechanisms, frequently confused:

Before choosing between them, decide what each role address is for, because a shared mailbox tends to become a record of decisions whether or not anyone intended that. The National Archives and Records Administration's email management guidance is a useful frame for deciding which addresses carry obligations and which do not.

Choose deliberately. Most of the "nobody replied to the customer" problems in small businesses trace back to a role address that was set up as a distribution list because it was the free option.

Two more decisions here:

Avoid a catch-all that accepts mail to any address at your domain. It looks helpful and it guarantees you receive every piece of spam addressed to a guessed name, forever. Explicit addresses that bounce cleanly are better for you and better for legitimate senders who mistyped.

Decide the leaver policy now. When someone goes, does their address bounce, forward to a colleague, or become a shared mailbox someone monitors? Deciding at the point of a departure produces improvised forwarding rules that outlive everyone's memory of them.

Phase 6: client access and connected applications

Configure how people and systems actually reach the mailbox.

For people, prefer whatever modern sign-in the provider supports over storing a password in a mail client, and enforce a second factor from the start rather than as a later project. Retrofitting multi-factor authentication onto an organization that has been without it is far harder than starting with it.

For systems, give each automated connection its own identity and record it in a connection register: a spreadsheet or shared document listing the service, purpose, owner, account identity, and recovery contact.

If your CRM reads a mailbox with a named employee's credentials, the integration breaks the day that employee leaves, silently, at a moment nobody connects to the departure.

Give every automated connection an account that belongs to the function, not the person.

Phase 7: the checks that come after

Do not consider the setup finished at cutover. Check each of these afterwards:

Do not schedule a cutover for a Friday, or immediately before a period when the people who understand the setup are away. When a problem appears, having those people available makes diagnosis and recovery more manageable.

Where to read next

The category overview covers why the domain rather than the mailbox is the thing you are really buying. Administrative accounts, the break-glass account, and the leaver checklist all belong in the administration layer rather than in the mail product, and settling them there means this setup only has to be done once.

Common questions

How long does this actually take?

The DNS and authentication work follows a defined sequence once the decisions are made. Phase 2, the inventory of everything that sends as your domain, can require input from other people about systems they set up years ago, so start it before the DNS work.

Can we skip DMARC at first and add it later?

You can publish it in a monitoring position from day one, which costs nothing and tells you who is sending as your domain. What you should not do is move it straight to a rejecting position without watching the reports first, because that is how a payroll system quietly stops reaching anyone.

Should shared addresses be mailboxes or distribution lists?

If a reply is expected, use something where everyone can see what has been answered. Distribution lists fail here in a predictable way: either three people answer or nobody does, and neither is visible until a customer complains.

What is the most commonly forgotten step?

The infrequent senders from the inventory. They may not send during the initial observation period, so they can fail later, by which point nobody connects the failure to the change.