Set Up MX, SPF, DKIM, and DMARC for Email

A reusable checklist for setting up MX, SPF, DKIM, and DMARC for custom domain email without common DNS mistakes.

Setting up email for a custom domain often looks harder than it is, mainly because the important pieces live in DNS and are easy to mix up. This guide gives you a reusable checklist for configuring MX, SPF, DKIM, and DMARC, along with practical examples, verification steps, and the common mistakes that cause mail delivery problems. Keep it bookmarked for new setups, provider changes, and troubleshooting days.

Overview

If you use a custom domain for email, four record types matter most: MX, SPF, DKIM, and DMARC. Together, they tell the internet where your mail should go, which systems are allowed to send on behalf of your domain, how messages can be cryptographically signed, and what receiving servers should do when authentication fails.

Here is the simple version:

MX records route incoming email to your mail provider.
SPF is a TXT record that lists the servers or services allowed to send mail for your domain.
DKIM is usually a TXT or CNAME-based setup that lets your provider sign outgoing mail so receivers can verify it was authorized.
DMARC is a TXT record that tells receiving servers how to handle messages that fail SPF and DKIM alignment checks, and where to send reports.

The exact values depend on your email host. The process, however, stays fairly consistent across providers:

Confirm which company is hosting your email.
Find your domain’s active DNS zone.
Add or replace the required records exactly as provided by the email service.
Wait for propagation.
Verify mail flow and authentication.
Document the final state so future changes do not break it.

If you are not sure where DNS is actually managed, start there first. Your registrar might not be your DNS host. If your nameservers point elsewhere, the records must be added in the active DNS provider’s control panel, not just at the registrar. If you need a refresher on this distinction, see DNS Records Explained: A, AAAA, CNAME, MX, TXT, NS, and SRV.

Before you touch anything, collect these details:

Your domain name
Your email provider’s setup instructions
Access to the DNS control panel
A list of any current MX, SPF, DKIM, and DMARC records
The expected sending services, such as your mailbox host, marketing platform, help desk, or transactional sender

That last point matters. Email authentication problems often happen because teams add a mailbox provider but forget about the newsletter tool, contact form service, or ticketing system that also sends mail from the same domain.

Checklist by scenario

Use the scenario below that matches your situation. Each checklist is designed to be reusable, so you can come back to it when changing vendors or fixing deliverability.

Scenario 1: Brand new custom domain email setup

This is the cleanest case because you are not migrating from another mail system.

Identify the DNS host. Log in where the authoritative DNS zone is managed. If needed, compare your registrar and nameserver settings. If your domain itself is still being connected to a site or server, this guide may help too: How to Point a Domain to Your Hosting Provider, Website Builder, or Server.
Add the provider’s MX records. Remove placeholder MX entries if the provider says to replace them. Pay close attention to priorities. Lower numbers usually mean higher priority.
Add the SPF record. Most providers give you a TXT value beginning with v=spf1. If there is already an SPF record, do not create a second one without checking the existing setup. SPF should usually exist as a single combined record for a domain.
Enable DKIM in the mail provider dashboard. Some services ask you to add one or more TXT or CNAME records. Copy them exactly. Selector names matter.
Add a DMARC record. Start with a monitoring-friendly policy if you want a cautious rollout, such as one that focuses on reporting before enforcement. A common record starts with v=DMARC1 and includes a policy tag like p=none, plus a reporting address.
Wait for DNS propagation. Record changes may appear quickly or take longer depending on TTL, caching, and the provider. For a deeper explanation, see DNS Propagation Time Guide: How Long Changes Take and How to Check.
Test inbound and outbound email. Send a message into the domain and send one out to a few major mailbox providers.
Verify authentication. Check your provider’s admin console or message headers to confirm SPF, DKIM, and DMARC are passing as expected.

Scenario 2: Switching from one email provider to another

Migrations fail when old and new records overlap in ways the team did not expect. Treat this as a controlled cutover.

Inventory the existing records. Export or copy the current MX, SPF, DKIM, and DMARC values before making changes.
List all senders. Do not focus only on user mailboxes. Include support tools, billing systems, CRM platforms, forms, status pages, and transactional email services.
Plan the MX change window. If possible, make the switch at a low-traffic time for your team.
Update MX to the new provider. Remove or replace old MX records according to the new provider’s instructions.
Merge or rebuild SPF carefully. The new provider may supply an include: mechanism. If you still use other senders, they may need to remain in SPF too. Avoid creating multiple SPF TXT records.
Replace DKIM records for the new provider. If the selectors change, publish the new ones exactly. Old DKIM records can sometimes remain temporarily, but only if you understand why they are still needed.
Review DMARC alignment. A DMARC policy can expose issues after migration if the new provider is not fully configured. Make sure the visible From domain aligns with SPF or DKIM.
Test forwards, aliases, and shared mailboxes. These are often overlooked in provider moves.
Monitor reports and bounces for several days. Migrations often look fine at first but reveal issues with less common senders later.

Scenario 3: Adding a new sending service without changing inbox hosting

This is common when you keep your main mailbox host but add a newsletter tool, sales platform, or help desk.

Confirm whether the service sends from your root domain or a subdomain. Many teams prefer a subdomain such as news.example.com or mail.example.com for better separation.
Check SPF impact. If the service wants you to add an include: entry to SPF, update the existing record instead of creating a second SPF record.
Publish the service’s DKIM record. Many sending platforms depend more heavily on DKIM than SPF alone.
Review DMARC alignment. Some tools send from one domain while using return paths or envelope senders from another. Make sure alignment still works for your visible From address.
Send real test messages. Use major mailbox providers and inspect the headers if possible.

Scenario 4: Fixing deliverability problems

If messages are going to spam, bouncing, or failing authentication, use this order of operations.

Check MX first for inbound issues. If mail is not arriving, confirm the right mail exchanger hostnames and priorities are published.
Check SPF syntax and duplication. One malformed SPF record can invalidate the whole policy.
Check DKIM selector names and values. A single missing character can break signing validation.
Check DMARC policy and reporting mailbox. If your policy is strict but SPF or DKIM alignment is failing, some messages may be quarantined or rejected.
Look for stale records from old providers. Legacy DNS entries are a frequent source of confusion.
Verify the sending path. The platform users think is sending mail is not always the one actually doing it.

Example record patterns to understand

The exact values will vary, but these simplified patterns help explain what you are looking at:

MX: host @, priority 10, value mail.provider.example
SPF TXT: v=spf1 include:provider.example ~all
DKIM TXT: host selector1._domainkey, value beginning with v=DKIM1; k=rsa; p=...
DMARC TXT: host _dmarc, value beginning with v=DMARC1; p=none; rua=mailto:dmarc@example.com

Do not copy those directly into production. Use the values supplied by your actual email service.

What to double-check

Most DNS email issues come from small details rather than big misunderstandings. Before you declare the setup complete, review this list slowly.

You edited the right DNS zone. This is the most common problem when registrar and DNS provider are different.
There is only one active SPF record for the same hostname. Multiple SPF records can cause authentication failures.
MX priorities are correct. A wrong priority can send mail to an unexpected server or create confusing fallback behavior.
Hostnames are entered correctly. Some DNS panels want @ for the root domain; others want the domain left blank. Some automatically append the zone name; others do not.
TXT values were pasted exactly. Missing quotes, broken line wrapping, and extra spaces can all matter depending on the control panel.
DKIM selectors match what the provider expects. If the provider says use google._domainkey or selector1._domainkey, that must match exactly.
DMARC reporting addresses can receive mail. If you specify a reporting mailbox, make sure it exists and is monitored.
Your visible From domain aligns with SPF or DKIM. Passing SPF alone is not enough for DMARC unless alignment also works.
You tested from every actual sender. A newsletter platform passing checks does not prove your billing app or support desk is configured correctly.

It is also worth documenting what each record is for. A simple internal note with record name, purpose, owner, and date added can save hours later. That is especially true in teams where web hosting, DNS, and email are managed by different people.

Common mistakes

These are the issues that repeatedly cause failed setups or partial success.

Creating more than one SPF record

When a second service asks for SPF, many users add a second v=spf1 TXT record instead of merging the mechanisms into the existing one. In practice, that often breaks SPF evaluation. Treat SPF as a single policy per hostname.

Changing MX but forgetting the rest

Switching inbox hosting requires more than pointing MX records to the new provider. Outbound authentication also matters. If SPF and DKIM still reference the old service, your mail may arrive but outgoing messages may fail checks.

Using the wrong host field

DNS panels differ. One may want selector1._domainkey, another may expect the full FQDN, and another may append the domain automatically. If the final record becomes duplicated, DKIM lookups will fail.

Publishing DMARC too aggressively too early

A strict DMARC policy can be useful, but only after you are confident every legitimate sender is authenticating and aligning correctly. If not, valid mail may be quarantined or rejected. A staged rollout is usually easier to manage.

Ignoring subdomains

Your main domain and your sending subdomain may need separate records. This is common with marketing tools and transactional systems.

Forgetting propagation time

Users often change records and immediately conclude something is broken. Sometimes it is just not visible everywhere yet. Use a DNS propagation checker and compare what your provider expects to what public resolvers return. The propagation guide linked earlier is useful here.

Leaving stale legacy records in place

Old DKIM selectors, outdated MX entries, or SPF references to retired services can create confusing results during troubleshooting. Remove what you no longer need, but only after confirming nothing still depends on it.

When to revisit

Email DNS is not a one-time task. Revisit this setup whenever the underlying sending or receiving path changes. A short review at the right time prevents avoidable outages and deliverability dips.

Come back to this checklist when:

You move to a new email hosting provider
You add or remove a newsletter, CRM, help desk, or transactional sender
You change DNS hosts or nameservers
You migrate a website contact form to a different platform
You tighten your DMARC policy after a monitoring period
You notice spam placement, bounces, or missing inbound mail
You are doing annual cleanup before busy seasons or planning cycles

A practical maintenance routine looks like this:

Quarterly: review current MX, SPF, DKIM, and DMARC records against the list of active services.
Before major launches: test every tool that sends mail from your domain, including forms and automated notifications.
After provider changes: monitor reports, bounces, and authentication results for several days.
Once a year: remove obsolete records, confirm reporting addresses still work, and update internal documentation.

If your wider domain setup is also changing, it helps to review related DNS basics at the same time, especially if mail and website records are managed together. For broader reading, see DNS Records Explained and How to Point a Domain to Your Hosting Provider, Website Builder, or Server.

Final action checklist: