Move from explanation to action with the matching DomainCheck.co.uk tools for this topic.
Confirm the domain is resolving cleanly before troubleshooting email delivery.
Useful when auditing email-related domains across many records or assets.
Escalate when email setup touches DNS, registrar access, and live business mail.
Setting up email on a new domain is not just “buy domain, create inbox.” It touches DNS, mailbox hosting, authentication, and migration planning. A beginner needs a single sequence they can follow without guessing which record comes first. This article exists separately because it is a workflow guide rather than a theory guide. It pulls together the practical steps needed to get a working business email setup on a fresh domain, while the SPF, DKIM, DMARC, and troubleshooting articles explain the individual pieces in more detail.
Setting up business email on a new domain is mostly about making sure three things work together:
If you skip any of those, mail may still work sometimes, but it is more likely to be unreliable or land in spam.
| What you need | Why it matters | Common mistake |
|---|---|---|
| Domain access | You must be able to edit DNS | Editing the wrong registrar or zone |
| Email provider | It supplies MX, SPF, DKIM, and DMARC values | Guessing the records |
| Mailbox names | You need the addresses you actually plan to use | Only creating one inbox and forgetting aliases |
| A test plan | You should verify delivery after setup | Assuming DNS changes are enough |
Before changing any DNS records, decide which provider will handle your mailboxes. That might be your web host, a specialist email provider, or a platform like Microsoft 365 or Google Workspace.
Different providers use different DNS values, different setup steps, and different verification methods. Do not guess. Use the records they give you.
This matters because the provider determines the MX records, SPF includes, and DKIM selectors you will need.
If your domain registrar is not also your DNS host, the records you edit at the registrar may not be the records that are actually used.
Check which nameservers are active for the domain. Then make sure you are editing the live DNS zone. If you update the wrong place, the setup may look correct in one dashboard while mail continues to fail elsewhere.
Route incoming mail to the provider that should receive messages for the domain.
Lists the services allowed to send mail on behalf of the domain.
Adds a verifiable signature to outgoing mail.
Tells receiving systems how to handle failed or suspicious mail.
MX records tell the internet where to deliver incoming mail.
Your email provider should give you one or more MX values. Add them exactly as provided. Remove old MX records if they conflict with the new provider, unless the provider specifically tells you to keep them during a transition.
After saving the changes, wait for DNS to update and confirm the MX records are visible in the active zone. If the MX data is wrong, people may send you email that never arrives.
SPF tells the world which servers are allowed to send email for your domain.
Your provider will usually give you an SPF value that includes their sending service. In some cases, you may need to add more than one sending source, such as a newsletter tool or invoicing system. The important thing is that all legitimate senders are included.
Avoid creating multiple SPF records. Usually you should have one SPF policy per domain, not several competing TXT records.
Business email often fails because the domain was created successfully but the live DNS zone was never updated, or because the new mail provider’s records were entered with the wrong hostnames.
DKIM signs outgoing messages so receiving mail systems can verify them.
Most providers will show you a selector and a TXT value to add in DNS. Add it exactly as instructed, then enable signing in the provider dashboard if needed. Some systems require both the DNS record and a toggle inside the mail service.
If the provider offers more than one selector, that can help with rotation or separate services. The details vary, so follow the provider’s own documentation rather than trying to simplify the setup yourself.
Once SPF and DKIM are in place, add DMARC.
If this is a brand-new setup, many businesses start with p=none so they can monitor first. That allows you to see whether all legitimate mail sources are authenticating correctly before you enforce a stricter policy.
When confident, you can move to quarantine or reject. The right policy depends on how many services send mail for the domain and how well controlled they are.
Now create the actual mailbox or mailboxes you want, such as hello@, info@, or accounts@.
Then test both sending and receiving:
Testing matters because DNS can look correct and still fail in practice if a record was entered with the wrong host name or value.
Businesses often need more than one mailbox structure.
You may want aliases such as sales@ or support@, forwarding from a simple address to a shared inbox, or delegated access for a colleague. Those features are usually provider-specific and should be set up inside the mail platform rather than in DNS.
Keep in mind that forwarding can affect SPF and DKIM results depending on the path the message takes. If you rely heavily on forwarding, test it carefully.
Once everything works, document it.
Write down:
That record saves time later when someone changes name servers, migrates hosting, or updates the website and accidentally touches email settings.
Before you call the setup finished, confirm all of the following:
This is the practical minimum for a business email setup that you can trust.
If your domain will send important customer mail, take extra care before enforcing DMARC. A strict policy is useful, but only after every real sender is covered.
If you are switching from another host, keep the old setup alive long enough to avoid missing mail during the transition. Provider behaviour and DNS caches vary, so migration timing matters.
If you are not confident about the DNS side, it is usually safer to verify the records with a DNS checker before assuming the mail provider has finished the job.