Set up business email on your own domain in seven steps
A business address such as [email protected] needs a domain, a mail service and the correct DNS configuration. The technical setup is only part of the job: decide who receives role-based messages, how people sign in and what happens to existing mail.
Use this sequence to avoid routing customers' messages to a service that is not ready. Obtain the actual DNS values from your provider; examples from another account are not a substitute.
1. Register or confirm control of the domain
Choose a name that fits the business and your intended markets. Check the extension's requirements and renewal cost, and register it for the appropriate owner. If you already have a domain, confirm administrative access and identify the authoritative DNS provider.
Keep a monitored contact address and protect the registrar account. Consider a recovery contact that remains usable if the domain's own email stops working. Our domain guide explains the registration and ownership decisions.
There is no requirement to host the website and email at the same supplier. Preserve existing website records unless you are deliberately moving the site too.
2. Choose the email service for the team
List users, storage, shared mailboxes, calendars, mobile access and any office applications the business already relies on. A collaboration suite may fit an established workflow; straightforward hosted mailboxes may be enough for another team.
Compare the actual subscription, support, account administration, retention and data-handling terms. Do not assume that all plans from a large provider use the same location or that a European server alone resolves every privacy requirement.
ResaHost's business email service can be discussed alongside hosting and domains. Confirm mailbox capacity and any migration work for the selected package before ordering.
3. Create users, aliases and shared access
Create personal accounts for staff and decide how role addresses such as sales@, info@ and billing@ should work. An alias forwards to an existing destination; a shared mailbox can provide a common inbox with delegated access where the service supports it.
Avoid having several people share one password. Check whether users can reply from role addresses, who receives replies and whether sent messages are visible to the team that needs them.
Set up strong authentication, recovery methods and at least an agreed route for administrative recovery. Deliver initial credentials through an appropriate secure channel and have users complete activation before the routing change.
If migrating, plan old-message copying now. Contacts, calendars, filters and signatures may require separate handling from mailbox folders.
4. Configure incoming mail with MX records
Verify the domain with the provider if required, then publish its MX records in the authoritative DNS zone. The record points to a hostname and includes a priority; lower numbers are preferred within the applicable setup.
Use the full set supplied by the service. Remove obsolete destinations as part of the planned cutover, but do not delete a valid secondary MX merely because there is more than one record. Multiple records can provide a coordinated mail-routing arrangement.
Do not mix unrelated mail providers without a designed coexistence setup. Keep the old service available while cached records can still direct messages there, and plan a final reconciliation of messages after the move.
See how to connect a domain to email for DNS-panel details and proxy-related mistakes.
5. Publish a correct SPF policy
SPF authorises sending systems for the relevant envelope-sender domain. Inventory every legitimate sender, including website forms, CRM, newsletters, invoices and booking confirmations.
Publish one SPF policy per relevant domain, incorporating the correct provider values. Adding a second SPF record is not how you authorise another service. Complex configurations also need attention to DNS-lookup limits.
The ending mechanism expresses a policy result; it is not a command that makes every receiver handle the message identically. Have the maintainer check the complete record rather than changing it blindly to a stricter-looking value.
6. Enable DKIM signing
Generate or activate DKIM through the sending provider. Publish the TXT or CNAME records it gives you, using the exact selector and name. Confirm that the DNS panel does not append the domain twice.
Return to the mail service and enable or verify signing where required. Then inspect an actual received message: a published key is not evidence that messages are being signed successfully.
If several tools send mail, configure and test each one. They may use distinct selectors. Our SPF, DKIM and DMARC guide explains the separate identities these checks assess.
7. Introduce DMARC and verify the whole workflow
DMARC ties authentication to the visible From domain through alignment. Arrange a monitored reporting destination, review legitimate senders and progress to an enforcement policy once their configuration is understood.
A monitoring policy is useful while discovering legitimate sources, but it does not request rejection or quarantine. Do not leave monitoring unattended indefinitely, and do not enforce rejection before testing the services your business needs.
Finish account protection too: confirm multi-factor authentication, recovery and access for every user. Authentication records do not stop someone who has taken over a legitimate account.
Test before calling the setup complete
Send and receive external messages, reply in both directions and test aliases. Check headers for authentication results. Send a contact-form enquiry, invoice and any automated confirmation the business uses.
Verify phones and desktop clients, including sending rather than just synchronised reading. Check that historical mail arrived and that the team knows where new messages will appear.
Fix common problems methodically
| Symptom | First checks |
|---|---|
| Incoming mail bounces | Recipient exists, MX destinations are correct, mailbox has capacity |
| Reading works but sending fails | Outgoing service, authentication and client configuration |
| One tool's mail goes to spam | That tool's signing, alignment, reputation and message details |
| Some mail reaches the old service | Cached routing and migration reconciliation |
| New records appear to do nothing | You edited the authoritative DNS zone |
Keep the full bounce or error message and a timestamp. Do not repeatedly change unrelated DNS records in response to one failed test. A documented setup with tested recovery and an identified maintainer is easier to operate long after the first message arrives.