A custom domain makes business email easier to recognize and manage, but reliable delivery depends on more than creating a mailbox. This guide explains how to choose email hosting, plan mailboxes and aliases, add MX records, configure SPF, DKIM, and DMARC, test the setup, and maintain a recurring checklist as providers and domain settings change.
Overview
Custom domain email uses an address such as you@example.com instead of a free mailbox address. The domain may be registered with one company, the website may be hosted elsewhere, and email may be handled by a third provider. Keeping those services separate is normal, but it means DNS records must be planned carefully.
Email hosting for a custom domain generally includes one or more mailboxes, webmail access, calendar or contact features, spam filtering, mobile and desktop access, and administrative controls. The exact feature set varies, so compare providers by the work your organization needs rather than by mailbox count alone.
Before changing DNS, write down your current setup and decide which service should receive mail. The most important rule is simple: use the MX records supplied by your chosen mail host, not examples copied from another provider. Incorrect or mixed MX records can cause messages to go to the wrong service or fail to arrive.
If you are also launching a website, keep email changes separate from website changes where possible. A website may use an A or CNAME record, while email depends mainly on MX and authentication records. The domain and hosting launch checklist can help you organize these services before going live.
What to track
1. Provider and account details
Record the email provider, administrator login location, support contact, renewal date, plan name, mailbox limits, storage limits, and any separate charges for additional users or features. Avoid storing passwords in a shared document. Instead, keep the account owner and recovery method in an approved password manager.
For a useful domain email hosting comparison, note whether the service supports the protocols and features your users require, such as webmail, IMAP or other supported client access, aliases, forwarding, shared mailboxes, calendars, mobile applications, retention controls, and administrative audit options. Treat provider documentation as the source of truth because setup values can change.
2. Mailbox, alias, and forwarding inventory
Maintain a simple list with these categories:
- People: individual mailboxes that need separate logins.
- Shared addresses: addresses such as
support@,sales@, orbilling@. - Aliases: alternate addresses that deliver to an existing mailbox.
- Forwarders: addresses that redirect messages to another destination.
- Service accounts: applications, forms, monitoring tools, and transactional systems that send email.
For each address, record its owner, purpose, destination, and whether it is still required. Remove obsolete forwarding rules and unused accounts during regular reviews. They can create confusion, privacy exposure, or delivery problems even when the domain itself is configured correctly.
3. DNS records
Track the record type, hostname, value, purpose, TTL, date added, and source of the value. The main records for custom domain email are:
- MX: tells receiving systems which mail servers accept incoming messages for your domain.
- SPF: a TXT record that identifies services permitted to send mail for the domain.
- DKIM: uses a provider-generated public key in DNS so recipients can verify a signature added to outgoing messages.
- DMARC: a TXT record that tells receiving systems how to handle messages that do not align with authentication checks and where reports may be sent.
Do not create multiple independent SPF records for the same domain. If several services send mail, their authorized sources must be combined according to the provider instructions. DKIM selectors and DMARC values are provider- and policy-specific, so copy them exactly and preserve punctuation.
For a broader explanation of record behavior and troubleshooting, see the DNS troubleshooting guide. If you use a DNS proxy or security platform, also confirm whether mail-related records should remain unproxied. The Cloudflare setup guide covers the distinction between DNS management and proxying.
4. Delivery and authentication signals
Track whether messages are being delivered, delayed, rejected, or placed in spam. Test both directions: send from the custom domain to several unrelated test accounts, and reply back to the custom domain. Review the message headers for SPF, DKIM, and DMARC results when available.
Also record whether your website, contact forms, newsletters, cloud applications, or billing systems send mail using the domain. A mailbox may work while an application silently fails because the application uses a different sending service that has not been included in the authentication plan.
Cadence and checkpoints
Before launch or migration
- Choose the mail host and confirm the required mailbox, MX, SPF, DKIM, and DMARC values.
- List every person, alias, forwarder, shared address, and application that sends mail.
- Export or preserve important messages and contacts if moving from another provider.
- Lower DNS TTL only if your migration plan calls for it; do not change records without a rollback note.
- Create mailboxes before switching incoming MX records when the provider supports that sequence.
- Test a small group of accounts before moving every user.
Keep the old service available during the transition when practical. Do not cancel it immediately after changing MX records; messages may continue reaching the previous service while DNS caches expire.
Monthly review
Once a month, check failed delivery notices, spam complaints or user reports, forwarding rules, mailbox capacity, account access, and automated messages from websites or applications. Confirm that no new service has started sending mail without being documented in SPF or DKIM settings.
Quarterly review
Every quarter, verify the provider plan, renewal date, active users, aliases, recovery contacts, administrator access, and authentication records. Review DMARC reports if you receive them. They can reveal legitimate senders you forgot to document, as well as messages that appear to use your domain without authorization.
Use this review to confirm that the email provider still meets operational needs. For example, a growing team may need shared mailbox controls or stronger administration, while a small project may be paying for inactive accounts. Compare total renewal cost and practical features rather than the introductory price alone.
How to interpret changes
A DNS change is not the same as an immediate global switch. Resolvers and receiving systems may cache records for different periods, so results can differ between networks during a transition. Use a DNS propagation checker as a diagnostic aid, but also test actual mail delivery and inspect headers.
If incoming mail fails, check the domain's MX records first. Look for old records left beside the new provider's records, spelling errors, an incorrect hostname, or a record entered under the wrong DNS zone. The domain connection guide explains how to identify which service is authoritative for DNS.
If outgoing mail is rejected or marked as suspicious, check whether the sending service is authorized by SPF, whether DKIM signing is enabled, and whether the DKIM public key matches the selector used by the provider. A DMARC failure can result from authentication or alignment problems, even when SPF or DKIM appears to pass independently.
Change one variable at a time when troubleshooting. Record the previous value, new value, time of change, and test result. This makes rollback possible and prevents several simultaneous edits from hiding the original cause.
When to revisit
Revisit this guide monthly for operational checks and quarterly for a fuller account and DNS review. Also return to it immediately when you change email providers, register a new sending service, launch a contact form, change your DNS host, add a new domain, or receive unusual delivery failures.
Use this practical tracker:
- Next review date: choose a recurring monthly or quarterly date.
- Provider: record the current mail host and plan.
- Renewal check: confirm the renewal date and expected recurring cost.
- Users: remove departed users and confirm required accounts.
- Aliases and forwarding: verify owners, destinations, and business purpose.
- DNS: compare MX, SPF, DKIM, and DMARC records with current provider documentation.
- Senders: list every website, application, newsletter, and service that sends mail.
- Tests: send and receive test messages and record any authentication or delivery warnings.
- Changes: document what changed, who approved it, and how to reverse it.
For related website setup work, combine this tracker with a domain and hosting setup checklist. Keeping domain registration, DNS, website hosting, SSL, and email ownership documented in one place makes future migrations safer and reduces the chance that a forgotten record or renewal interrupts communication.
