Professional email on your own domain makes a business easier to recognize and manage, but it depends on more than creating a mailbox. This guide explains how to set up domain email, add the required DNS records, configure SPF, DKIM, and DMARC, test delivery, protect account recovery details, and maintain the setup as your team and providers change.
Overview
A domain email address uses a name such as hello@example.com instead of a consumer mailbox. Your domain registrar controls the domain, your DNS host publishes instructions for internet services, and your email provider stores and sends messages. These may be three separate accounts, even when one company offers all three services.
The setup has two related parts:
- Mail routing: MX records tell other mail servers where to deliver messages for your domain.
- Sender authentication: SPF, DKIM, and DMARC help receiving systems evaluate whether messages claiming to come from your domain are authorized and aligned.
Before changing DNS, choose an email provider and record its exact setup instructions. Do not copy a record from another provider or assume that a similar-looking hostname is correct. Provider requirements, administrator screens, sending limits, and authentication workflows can change, so the provider’s current documentation should be the final reference.
If you are still choosing a domain, start with this practical domain naming checklist. If the domain is already connected to a website, remember that changing email records is separate from connecting the domain to hosting; website records and mail records must be reviewed independently.
Checklist by scenario
Scenario 1: Setting up a new domain email service
- List the addresses you need. Separate individual mailboxes, shared addresses, aliases, and forwarding addresses. For example, a person may need a mailbox, while
sales@may be an alias or shared inbox depending on the provider. - Secure the administrator account. Use a unique password, enable multi-factor authentication where available, and record at least one approved recovery method. Keep recovery information in a secure password manager rather than in a public document.
- Create users and groups. Add only the mailboxes required at launch. Document who owns each shared address and who can administer the email service.
- Add the provider’s MX records. Remove obsolete MX records only after confirming that the old service is no longer needed. Multiple old and new mail routes can produce unpredictable delivery results.
- Publish SPF. Add one SPF TXT record at the root of the domain that authorizes the services allowed to send mail. Ask the provider for the exact SPF value.
- Enable DKIM. The provider will usually give you a selector and a DNS record, often a TXT or CNAME record. Add the record exactly as supplied, then return to the provider’s administrator panel to enable or verify signing.
- Add DMARC cautiously. Begin with a monitoring policy if you are unsure which legitimate services send mail for the domain. A typical record uses the hostname
_dmarc, a policy value, and a reporting address controlled by your organization. Move toward a stricter policy only after reviewing legitimate sending sources. - Test both directions. Send from the new domain to an unrelated mailbox and reply to the new address. Test a personal address, a business address, and any important contact forms or website notifications.
Scenario 2: Moving from one email provider to another
Plan migration as a sequence rather than as a single DNS edit. Export or migrate existing messages, confirm that user accounts exist at the new provider, and lower DNS TTL in advance only if your provider or DNS host recommends it. Keep a written rollback plan.
- Record the current MX, SPF, DKIM, and DMARC values before making changes.
- Confirm whether website forms, newsletters, invoicing tools, CRM systems, or help desks send mail using the domain.
- Add the new provider’s authentication records before switching mail routing where possible.
- Change MX records according to the new provider’s instructions and monitor both incoming and outgoing delivery.
- Remove old authorization only after the old service and its connected applications have stopped sending.
Scenario 3: Adding a mailbox or onboarding a team member
Adding a user normally does not require new MX, SPF, DKIM, or DMARC records. Create the mailbox in the provider’s admin area, assign the correct permissions, enable multi-factor authentication, and document the recovery process. Do not share one person’s password with a new team member. Use delegated access, groups, or shared mailbox features when the provider supports them.
Scenario 4: Connecting a website contact form
A website form may send through the web host, a transactional email service, or your main email provider. Identify the actual sending service before changing SPF. Add its authorization only if it is genuinely used, and configure a consistent From address. A visitor’s address should generally appear in the Reply-To field rather than replacing the authenticated sender. This reduces confusion and makes form delivery easier to diagnose.
DNS record template and verification workflow
Use the following as a planning template, not as values to paste unchanged:
| Record | Host or name | Purpose | Value |
|---|---|---|---|
| MX | @ | Routes incoming mail | Provider-supplied mail server and priority |
| TXT / SPF | @ | Lists authorized senders | One provider-approved SPF policy |
| TXT or CNAME / DKIM | Provider-supplied selector | Enables signed outgoing mail | Provider-supplied public key or target |
| TXT / DMARC | _dmarc | Defines handling and reporting preferences | Organization-approved monitoring or enforcement policy |
After saving records, allow time for DNS changes to become visible. Check the provider’s verification screen and use a DNS lookup tool to confirm the published values. Then inspect message headers in a test mailbox. Look for SPF and DKIM results, the authenticated sending domain, and DMARC alignment. A message arriving in an inbox is useful evidence, but it does not by itself prove that every sending service is configured correctly.
What to double-check
- There is only one SPF record. Combining the contents of multiple SPF records into one provider-approved record is usually preferable to publishing competing SPF records. Ask the provider how to include other legitimate senders.
- The domain in the From address is intentional. A form, newsletter, or application may use a different sending domain than your normal mailbox.
- DKIM is enabled, not merely published. Some services require a verification step after the DNS record is added.
- DMARC reports go to a monitored address. Use a dedicated mailbox or reporting service that your organization can review. Do not publish a reporting address without deciding who will handle the reports.
- Website DNS remains intact. MX records affect email, while A, AAAA, and CNAME records commonly affect websites and other services. Compare the complete DNS zone before deleting anything.
- Recovery access is documented. Keep the registrar login, DNS host login, email administrator account, recovery contacts, and renewal information in a controlled location.
For a broader launch process, use the website launch checklist, which can help you review domain, hosting, and site tasks separately.
Common mistakes and a deliverability troubleshooting flow
Start with the scope of the problem. If nobody can receive mail, check MX records and mailbox status first. If receiving works but outgoing mail fails, check provider limits, account verification, and authentication. If mail sends but lands in spam, inspect SPF, DKIM, and DMARC results and review the message content, sending pattern, and recipient feedback.
Frequent mistakes include leaving old MX records in place, creating multiple SPF records, adding a DKIM record under the wrong host name, publishing a DMARC policy before identifying legitimate senders, and changing DNS while troubleshooting without recording each change. Another common error is forgetting automated senders: website forms, appointment systems, accounting tools, and marketing platforms may all need separate authorization or provider-specific configuration.
Change one logical setting at a time, note the time and result, and retest from more than one receiving service. If a provider’s setup instructions conflict with your DNS host’s field labels, contact the provider or DNS host before guessing. Keep the original records in your change log so a rollback is possible.
When to revisit
Review domain email before seasonal planning cycles, before a major campaign, and whenever workflows or tools change. Revisit the setup immediately when you change email providers, add a website or application that sends mail, move DNS management, register a new domain, or notice authentication failures and unusual spam placement.
Use this recurring checklist:
- Confirm administrator and recovery access.
- Review active mailboxes, aliases, forwarding rules, and delegated permissions.
- Check that MX, SPF, DKIM, and DMARC records match the services actually in use.
- Review DMARC reports or provider authentication summaries when available.
- Send a test message after significant DNS or provider changes.
- Update the internal record of providers, DNS ownership, recovery contacts, and approved sending applications.
Keep the checklist with your domain and website documentation. When a new team member joins or a tool is added, update the record before relying on it for customer communication. For related domain and hosting tasks, see the hosting comparison guide and the guide to choosing a domain name for a small business.
