Business email setup: a practical setup guide for 2027

Setting up email on your own domain is not difficult. Setting it up in the wrong order is, and that is how most of the trouble happens: authentication configured after mail is already flowing, a cutover done before anyone found the systems that send as the domain, a catch-all address enabled for convenience that turns into a spam magnet nobody can switch off.

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

What to take away

• Do this before the cutover, because after it these are the things that break silently.
• MX records direct inbound mail to your provider.
• Configure how people and systems actually reach the mailbox.
• Do not consider the setup finished at cutover.

Phase 1: decisions to make before you touch DNS

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

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:

• The contact form on your website.
• Invoicing, accounting, and payroll systems that email documents to customers or staff.
• Your CRM, help desk, or booking system.
• Marketing or newsletter tools.
• Scheduled reports from anything internal.
• Office hardware: scanners and copiers that email documents to people.
• Anything a developer set up to send transactional mail.

Each of these is a sender that must be authorized, or its mail will start being rejected once you tighten authentication. This list is invariably longer than anyone's first guess, which is exactly 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

These three records decide whether your mail is believed. They are also the most common cause of a business quietly losing the ability to reach its customers.

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.

These three are not vendor features, they are published mechanisms, and the reference description of how they fit together is the standards body's guide to trustworthy email. Read the sections on each record before you publish anything, because a broken record is worse than an absent one.

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:

1. Start with the policy that takes no action, and with reporting addresses set. This changes nothing about delivery and starts producing reports about who is sending as your domain.
2. Read the reports for long enough to cover your slowest monthly process. Payroll, invoicing, and quarterly mailings are the senders most likely to be missing from your list, because they had not run yet when you took the inventory.
3. Authorize everything legitimate that the reports reveal.
4. Only then tighten the policy, and tighten it in stages rather than in one move.

Skipping straight to a strict policy is how an organization discovers its invoicing system was never authorized: by having a month of invoices 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 guidance on managing email is a useful frame for deciding which addresses carry obligations and which do not.

• An alias is an extra address that delivers into an existing mailbox. Cheap, usually free, invisible to the recipient. Good for variations on a personal address, and for a role address handled by exactly one person.
• A distribution address fans a message out to several individual mailboxes. Everyone gets a copy, nobody can see whether anyone else has replied. This is fine for announcements and bad for anything that needs a response, because either everyone answers or nobody does.
• A shared mailbox is a single mailbox several people open and work in together. Replies come from the shared address, and everyone can see what has been answered. This is what a real inquiries or support address needs.

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, the connection needs its own identity, registered in whatever connection register you keep. If your CRM reads a mailbox using a named employee's credentials, that integration will break the day the employee leaves, and it will break 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 these in the days and weeks afterwards:

• Send and receive in both directions with an outside address. Both directions, because inbound and outbound fail for entirely different reasons.
• Read the authentication reports. They will show senders you missed. This is expected, not a failure.
• Confirm calendar availability works across the team, and with anyone outside the organization you regularly schedule with. Cross-system free/busy is a common casualty of a switch.
• Test the spam quarantine. Find out where filtered mail goes, who can release it, and whether anyone is told it exists. A quarantine nobody checks is a place legitimate mail goes to die.
• Check every sender from Phase 2 has actually sent something since the change. The monthly and quarterly ones need a deliberate test rather than a wait.
• Confirm mobile access for whoever depends on it, on their actual device.
• Verify signatures and any automatic replies survived, particularly for shared addresses.

Do not schedule a cutover for a Friday, and do not schedule one immediately before a period when the people who understand the setup are away. Almost every problem in this list is a twenty-minute fix on a Tuesday and a weekend on a Friday.

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 is an afternoon. Phase 2, the inventory of everything that sends as your domain, is what takes a week, because it depends on other people answering questions about systems they set up years ago.

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 monthly and quarterly senders from the inventory. They do not send during the week you are watching, so they fail four weeks later, and by then nobody connects the failure to the change.