Setting Up Business Email on Your Own Domain

How mail finds you: MX records

When someone sends a message to an address at your domain, their mail server looks up your domain's MX (mail exchanger) records in DNS to find out which server accepts mail for it. The email standard, RFC 5321, describes this lookup. If there are several MX records, they are tried in order of preference, with the lowest number tried first.

So the MX records decide where your mail goes, and they are separate from where your website is hosted. You can host the website with one company and email with another; the domain's DNS simply points each service to the right place. Our guide to domain names and DNS explains who controls those records.

Each provider tells you the exact records to add. For example, Google's help page on setting up MX records for Google Workspace gives a single MX value and says to remove any other MX records, because old or incorrect ones can stop email working. Microsoft's page on adding DNS records for Microsoft 365 lists an MX record plus an optional but recommended Autodiscover CNAME record, which lets email apps such as Outlook configure themselves.

Hosted email or the mail that comes with hosting

Many web hosting plans include mailboxes on your domain. The alternative is a dedicated email service, such as Google Workspace or Microsoft 365, that you connect to the domain with MX records. Both can work. The questions to ask either way:

• What happens if you change web host? Mailboxes included with hosting usually live on the same account as the website, so moving or closing that account affects email too. Our guide to moving a site to a new host covers this.
• Storage, apps and calendars: how much storage each mailbox gets, whether calendars and contacts sync to phones, and which apps are supported.
• Security: whether every account can use multifactor authentication, and who can reset passwords.
• Administration: how easily you can add and remove people, create shared addresses and keep a leaver's mail.
• Authentication records: whether the provider gives you the SPF and DKIM details you need (see below).

Whichever you choose, make sure the business owns the domain and the email admin account, not a former employee or a contractor. Our web hosting guide lists more questions to ask a host.

Aliases, shared mailboxes and groups

Most businesses want role addresses such as info@, sales@ or support@ alongside personal ones. There are three common ways to set them up, and the right one depends on who should read the mail.

• Alias: an extra address that delivers into one person's existing mailbox. Google's page on email aliases allows up to 30 per user at no extra cost and gives the example of a one-person business using info@, billing@ and sales@ that all land in one inbox. Microsoft's page on adding an email alias allows up to 400 per user, also without extra licences. Google notes that only one user can use an alias.
• Shared mailbox: a mailbox several people can open and send from. Microsoft's page about shared mailboxes suggests them for company information, support and reception addresses, and says a shared mailbox can store up to 50 GB without its own licence, though each person using it needs a licensed mailbox.
• Group or collaborative inbox: an address that delivers to several people. In Google Workspace, Groups for Business lets a group act as a Collaborative Inbox, so a team can share and track messages sent to one address.

A practical rule: use an alias when one person handles an address, and a shared mailbox or group when a team does, so the mail and its history do not leave with one person.

Authentication and the Gmail and Yahoo rules

Large mailbox providers now check that mail claiming to come from your domain is authorised. Yahoo's sender requirements say all senders must use SPF or DKIM at a minimum, keep their spam complaint rate below 0.3% and have valid forward and reverse DNS for their sending servers. Bulk senders must also set up both SPF and DKIM and publish a DMARC policy. Google's email sender guidelines set similar rules for Gmail.

For a small business sending everyday mail, the practical step is to add the SPF and DKIM records your email provider gives you, then a DMARC record, as soon as the mailboxes are set up. Our guide to SPF, DKIM and DMARC explains each record and a safe order to add them. If you also send newsletters, our email marketing rules guide covers consent and unsubscribes.

Switching provider without losing mail

Moving from hosting mail to a dedicated service, or between services, is mostly about timing. Google's page on avoiding issues when changing MX records and Microsoft's DNS page give the same core advice:

1. Create every mailbox, alias and group first. Microsoft says to add users before updating the MX record so email keeps working; Google says to create user accounts before changing MX records to avoid bounces.
2. Change the MX records when mail is quiet, such as an evening or weekend, and tell key contacts when it will happen and to resend anything that bounces.
3. Allow time for the change to spread. Google's pages say new MX records can take up to 48 to 72 hours to be recognised everywhere; until then, some mail still reaches the old provider. Keep the old mailboxes open during that window.
4. Move the old mail. Microsoft explains that once the MX record changes, new mail goes to the new service but existing mail stays with the previous host unless you migrate it. Most services can import from any IMAP mailbox: Microsoft's migration overview and Google's data import tool both support it. Microsoft notes that an IMAP migration moves mail folders only, not contacts, calendars or tasks, and that mail arriving at the old system after the migration is not copied.
5. Update the authentication records. Replace or extend SPF and DKIM for the new provider, and keep DMARC in place.
6. Close the old service last, once no mail is arriving there and everyone's old messages, contacts and calendars have been moved.

Email sent by your website

Contact forms, shop orders and password resets also send email from your domain. They should send through an authenticated service that your SPF and DKIM records cover, not an unconfigured web server, or they may fail the authentication checks above. Test every form after any email change, and see our guide to stopping contact form spam for the incoming side.

Checklist

• The business owns the domain and the email admin account, with multifactor authentication on.
• Only the new provider's MX records are published; old ones removed.
• Role addresses set up deliberately: aliases for one person, shared mailboxes or groups for a team.
• SPF, DKIM and DMARC records added for every service that sends as your domain, including the website.
• On a switch: mailboxes created first, change made at a quiet time, old mail migrated, old service kept until traffic stops.
• Website forms and order emails tested after any change.

Frequently asked questions

What is an MX record?

A DNS record on your domain that tells other mail servers which server accepts email for it. Your email provider gives you the values to add. If there are several MX records, the one with the lowest number is tried first.

Can my website and email be with different companies?

Yes. The website is reached through your domain's A or CNAME records and email through its MX records, so each can point to a different provider.

Should info@ be an alias or a shared mailbox?

If one person answers it, an alias that delivers into their mailbox is simplest. If a team answers it, use a shared mailbox or group so everyone sees the same messages and the history stays when people leave.

Will I lose email when I switch provider?

Not if you plan it: create all mailboxes first, change the MX records at a quiet time, keep the old mailboxes open while the change spreads (Google says up to 48 to 72 hours), and migrate old mail before closing the old service.

Need email on your domain set up alongside a new or existing site? See our website maintenance service, see all our services, or email info@creahive.com.