Setting up a custom email domain involves more than choosing an address. This checklist explains how to connect your domain to an email provider, publish the required MX, SPF, DKIM, and DMARC records, test delivery, and maintain the configuration as your systems change.
Overview
A custom email domain uses an address such as hello@example.com instead of a generic mailbox. The domain remains under your control, while an email provider typically handles mailbox storage, sending, receiving, spam filtering, and account access.
DNS connects the domain to that provider. MX records tell other mail systems where to deliver incoming messages. SPF, DKIM, and DMARC help receiving systems evaluate whether messages claiming to come from your domain are authorized and trustworthy.
Before changing anything, identify two separate services:
- Your domain registrar or DNS provider: the service where you manage nameservers and DNS records.
- Your email provider: the service that supplies mailboxes and gives you the required DNS values.
These may be the same company, but they do not have to be. If you are unsure where DNS is managed, check the domain's nameserver settings first. For background on record types, see DNS Records Explained: How to Configure A, CNAME, MX, TXT, and NS Records.
Use the exact hostnames, priorities, and values supplied by your email provider. The examples below describe the purpose of each record, not universal values that can be copied between providers.
Checklist by scenario
Scenario 1: Setting up a new custom email domain
- Choose the domain. Confirm that the domain is registered, accessible, and protected by a strong registrar account. If you have not selected one, use the practical checks in How to Choose and Buy a Domain Name.
- Choose the email provider. Confirm that it supports your required mailboxes, aliases, forwarding rules, calendars, mobile access, and administrative controls.
- Record the current DNS configuration. Export or document existing records before editing them. This helps you restore a change and prevents accidental disruption to a website, verification service, or other subdomain.
- Add the provider's MX records. Remove obsolete MX records only when you are certain they belong to the previous mail service. Multiple MX records can be valid when supplied by the same provider, usually with different priorities.
- Add SPF as a TXT record. SPF lists the systems permitted to send mail for your domain. Publish one SPF policy for the domain, combining authorized sending services according to the providers' instructions.
- Enable DKIM. Your provider will usually generate a selector and public key. Add the requested TXT or CNAME record, then enable signing in the provider's administration panel.
- Publish DMARC. Start with a monitoring policy if you need to discover legitimate senders first. Use the provider's recommended reporting address and avoid enforcing a strict policy until you understand all systems that send on behalf of the domain.
- Create users and aliases. Make sure the addresses used by your website, contact forms, support tools, and automated applications exist or forward correctly.
- Test both directions. Send messages to the new domain from an unrelated mailbox and send messages from the new domain to several test recipients. Check delivery, replies, attachments, and the displayed sender.
Scenario 2: Moving from one email provider to another
Plan a migration rather than treating it as a simple DNS edit. Inventory every mailbox, alias, forwarding rule, shared address, mailing system, website form, and application that sends email. Lowering the DNS TTL before the change may help some resolvers notice updates sooner, but it cannot force every cached result to expire immediately.
Prepare the new mailboxes and migrate historical messages if required. Schedule the MX change for a period when you can monitor delivery. Keep the previous service available for an appropriate transition period if your migration plan requires it. Then update SPF, DKIM, and DMARC so the new provider is authorized and signing messages. A domain transfer is a different operation; changing registrars does not automatically move email. See How to Transfer a Domain Without Downtime if both changes are planned.
Scenario 3: Adding a website or application that sends mail
Do not automatically add every server to SPF. First determine whether the application can send through your established email provider using authenticated submission or an approved transactional email service. Add only the necessary authorization, configure DKIM where available, and test contact forms, password resets, invoices, and notifications. Keep application sending separate from employee mail when that makes auditing and reputation management easier.
What to double-check
MX records
Check the record name, destination, and priority exactly. The root domain is often represented by an “@” symbol in a DNS dashboard, although interfaces differ. Do not add an IP address to an MX record unless the provider specifically documents that format; MX destinations normally point to mail hostnames.
SPF records
SPF is published as TXT and applies to a domain or subdomain. Confirm that all legitimate senders are included, including marketing platforms, support systems, website infrastructure, and CRM tools. The most common operational problem is publishing more than one SPF record at the same name. Consolidate authorized mechanisms into the single policy required by your provider's instructions.
DKIM records
DKIM uses a selector, so the full DNS name may look like selector._domainkey.example.com. Copy the public key without changing punctuation or spacing. If the provider gives a CNAME, use the CNAME destination exactly rather than converting it to a TXT record.
DMARC records
DMARC is normally published at _dmarc.example.com as TXT. Review the policy, alignment settings, reporting addresses, and subdomain behavior before enforcing it. Reports can reveal forgotten systems, but they may contain operational data, so send them to a monitored address or analysis service that your organization has approved.
Propagation and testing
DNS changes can appear at different times because resolvers cache records according to their TTL. Test with a DNS lookup tool and with real messages, but interpret a temporary mixed result as possible caching rather than immediate proof that the record is wrong. Inspect message headers for SPF, DKIM, and DMARC results. Also check your provider's domain verification dashboard.
Common mistakes
- Changing nameservers instead of adding records: Replacing nameservers can remove unrelated website and verification records. Edit records at the active DNS provider unless you intentionally plan a DNS migration.
- Leaving old MX records in place: A stale MX destination can route some mail to an old service or create confusing delivery behavior.
- Publishing multiple SPF records: Combine the policy rather than adding a separate TXT SPF record for each vendor.
- Forgetting non-human senders: Websites, ticketing systems, newsletters, and business applications may all send mail. Include them in your inventory before enforcing DMARC.
- Assuming SPF alone prevents spoofing: SPF validates permitted sending paths, while DKIM supplies a message signature and DMARC defines how alignment and failures should be handled.
- Testing only from one mailbox: Test inbound, outbound, replies, forwarding, attachments, aliases, and automated messages. A message arriving in one inbox does not prove the entire setup works.
- Making DMARC strict too early: A policy that rejects failures can affect legitimate mail if your sending inventory is incomplete. Monitor first when appropriate, then tighten the policy after reviewing results.
When to revisit
Keep this checklist with your domain and DNS documentation. Revisit it before seasonal planning cycles, a major campaign, a website migration, or any change to your email provider, registrar, DNS host, CRM, help desk, newsletter platform, or transactional mail service.
Review the configuration after staff or mailbox changes, new subdomains, acquisitions, application launches, and security incidents. Also check that registrar access, DNS access, provider recovery methods, and domain renewal details are held by the appropriate administrators rather than one individual account.
For a practical maintenance routine, schedule a periodic review of MX, SPF, DKIM, and DMARC records; verify that the published records still match active services; inspect authentication results from representative messages; and remove authorization for systems you no longer use. If you move DNS or hosting at the same time, document the sequence carefully. Related guidance on DNS provider choices is available in Managed DNS vs Registrar DNS.
The final pre-change check is simple: document the current records, confirm the destination provider's exact requirements, make one controlled change at a time, and test before declaring the custom email domain ready.
