How to Set Up DNS for Email: MX, SPF, DKIM, and DMARC Checklist

Overview

If you manage a domain, email DNS is part of your reliability and security baseline. The four record types in this checklist solve different problems, and they work best as a set rather than as isolated tasks.

MX records tell the internet where to deliver incoming mail for your domain. If these are missing, incorrect, duplicated improperly, or left pointing to an old provider, mail delivery can fail or become unpredictable.

SPF is a TXT record that lists which systems are allowed to send mail using your domain. It helps receiving servers evaluate whether a message came from an approved source. SPF is useful, but on its own it is not enough, especially if your organization sends through multiple tools.

DKIM adds a cryptographic signature to outgoing mail. The public key lives in DNS, and the sending provider uses the matching private key to sign messages. DKIM helps prove that a message was authorized by a sender with access to the signing key and that it was not altered in transit.

DMARC builds on SPF and DKIM. It tells receivers what policy to apply when messages fail authentication checks, and it can send reports back to addresses you specify. DMARC is where many teams gain visibility for the first time into who is sending on behalf of the domain.

The practical goal is simple: mail should arrive reliably, legitimate senders should pass authentication, and spoofed or unauthorized mail should be easier to detect and reject. The exact values for your records depend on your email provider and any additional services you use, but the checklist below will help you avoid the most common failures.

One important operational rule: DNS for email usually lives with your domain’s authoritative DNS provider, which may or may not be the same company as your registrar or your web hosting provider. Before editing anything, confirm where your active DNS zone is hosted. If you are also planning a broader infrastructure move, keep email DNS separate from web hosting assumptions. A website migration and an email migration often touch different systems. For a related planning framework, see Website Migration Checklist: Move Hosts Without Breaking SEO or Email.

Checklist by scenario

This section is organized for repeat use. Start with the scenario closest to your situation, then move through the specific checks.

Scenario 1: Setting up email on a brand-new domain

Use this when: you just completed domain registration, you are launching a new brand, or you are creating email for a domain that has never had it before.

1. Confirm where DNS is hosted. Log in to the provider that holds the authoritative zone for the domain. Do not assume it is the same as your domain registration panel or web hosting dashboard.
2. Add the provider’s required MX records exactly as documented. Pay attention to host names, priorities, and whether the DNS editor expects the root domain as @, blank, or the full domain name.
3. Add the SPF TXT record. If your main mailbox provider supplies one, publish that exact record and do not create multiple SPF records for the same domain. If you need to authorize additional senders later, update the existing SPF policy instead of adding a second SPF record.
4. Enable DKIM in the mail provider first, then publish the DNS keys. Most modern providers generate one or more CNAME or TXT records tied to selectors such as selector1._domainkey. Copy them carefully.
5. Create a basic DMARC record. Start with monitoring if needed, using a policy such as p=none, and specify a reporting address that you actively monitor. This gives you visibility before stricter enforcement.
6. Check for an autodiscover or client configuration requirement. Some providers recommend additional records for mail clients or mobile device setup. These are not part of authentication, but they may reduce support friction.
7. Wait for propagation, then test both inbound and outbound mail. Send from an external mailbox to the new domain and from the new domain to at least two major mailbox providers if possible.

If you want a refresher on timing and verification after DNS changes, see DNS Propagation Checker Guide: How Long Changes Take and What to Test.

Scenario 2: Moving from one email provider to another

Use this when: you are migrating mailboxes, consolidating vendors, or replacing a legacy provider.

1. Inventory every current email-related DNS record before changing anything. Export or copy the existing zone entries for MX, SPF, DKIM, DMARC, autodiscover, custom tracking, and any subdomains used for sending.
2. Lower TTL values in advance if your DNS provider allows it. Do this before the cutover window so changes can propagate more quickly. Avoid last-minute edits without a rollback plan.
3. Stage the new provider’s DKIM records early. In many cases these can be published before the final MX switch.
4. Build the new SPF record carefully. Preserve any still-needed senders during transition. If your marketing platform, CRM, help desk, or billing system sends from the domain, include them or plan a phased cutover.
5. Change MX records during a controlled window. Keep a written record of old and new values and who approved the change.
6. Review DMARC alignment after the migration. Passing SPF alone may not be enough if the visible From domain does not align the way you expect. Confirm that the new provider’s DKIM signing domain aligns properly.
7. Retire old records only after testing. Removing a legacy sender too early is a common reason transactional messages fail after a migration.

If the domain itself is also moving to a new registrar, use a separate domain transfer plan so you do not stack multiple risks at once. A good starting point is Domain Transfer Checklist: How to Move a Domain Without Downtime.

Scenario 3: Adding a marketing, CRM, or transactional email tool

Use this when: your primary inbox provider stays the same, but a new platform needs permission to send as your domain.

1. Determine whether the tool sends from the root domain or a dedicated subdomain. Many teams benefit from using a separate sending subdomain for marketing or automated application mail.
2. Add only the records required for that service. This often includes DKIM selectors and either SPF includes or a return-path/bounce domain configuration.
3. Do not overwrite your main MX records. Many marketing and transactional tools do not handle inbound mail for your domain, so they should not replace your mailbox provider’s MX entries.
4. Keep SPF under control. Every new include adds complexity. If your SPF policy becomes difficult to reason about, document ownership by service.
5. Update DMARC monitoring expectations. A new sending source can trigger fresh failures until alignment is correct. Watch reports after launch.
6. Test the exact use case. A password-reset email, invoice email, or newsletter confirmation may follow a different path than a manual test message.

Scenario 4: Hardening an existing setup that already works “well enough”

Use this when: email is functioning, but the records were set up years ago, nobody is sure why they look the way they do, or spoofing concerns have increased.

1. Audit the current DNS zone. Identify all email-related TXT, MX, and CNAME records. Remove duplicate, obsolete, or undocumented entries only after confirming they are unused.
2. Check whether SPF has a single authoritative record. Multiple SPF TXT records for the same hostname often lead to authentication problems.
3. Verify DKIM for every active sender. A primary mailbox provider may be signing correctly while a secondary system is not.
4. Review your DMARC policy level. If you have been on monitoring mode for a long time and your legitimate senders are consistently aligned, consider whether a stricter policy is now appropriate for your environment.
5. Set up a reporting workflow. DMARC reports are only useful if they reach a mailbox or analysis process someone reviews.
6. Document ownership. Note which team or system owns each sender and record. This pays off during staff turnover and provider changes.

What to double-check

This is the part most teams wish they had reviewed before saving the zone file.

• Root domain vs subdomain placement. Make sure records are published on the correct host. Mail for example.com and mail for app.example.com are different contexts.
• Only one SPF record per hostname. SPF mechanisms can be combined inside one record, but publishing multiple SPF TXT records for the same hostname is a common failure.
• Correct MX priorities. If a provider specifies multiple MX entries with different priorities, preserve them exactly.
• No accidental trailing characters or missing quotes. DNS editors vary, and copy-paste mistakes are easy to miss in long TXT values.
• DKIM selectors match the provider. A valid-looking key on the wrong selector name will not help.
• DMARC reporting mailbox exists and can receive mail. If you specify reporting addresses, make sure they are live and monitored.
• Alignment, not just pass/fail. For DMARC, SPF or DKIM needs to pass with the right domain alignment. A provider can pass one test but still fail DMARC if the visible From domain does not line up as expected.
• Web hosting changes did not alter DNS unexpectedly. Some control panels try to manage DNS records broadly. After changing hosting, re-check that email records remain intact. If you are comparing hosting models for administrative control, see Shared vs VPS vs Cloud Hosting: Which Type of Web Hosting Fits Your Site.
• Registrar changes did not break the active name servers. During a domain transfer, the registration moves, but your DNS should remain stable unless you deliberately change name servers. This distinction matters for email continuity.

It also helps to keep a plain-text change log. Record the date, who made the change, why it was needed, the old values, the new values, and the expected impact. DNS mistakes become much easier to reverse when you have that history.

Common mistakes

The most expensive email DNS problems are usually not exotic. They are ordinary missteps made under time pressure.

Replacing mailbox MX records when adding a sender. A newsletter platform, support desk, or transactional email service may need DKIM and SPF entries, but it usually should not become the destination for all inbound mail. Always separate “can send” from “receives mail.”

Publishing multiple SPF records. This is one of the most common configuration errors because each vendor gives you a record snippet and admins paste them in separately. SPF needs to be consolidated into one policy per hostname.

Leaving old providers authorized forever. Over time, SPF includes, DKIM selectors, and custom bounce domains accumulate. If a service no longer sends on your behalf, remove or retire its access deliberately after verification.

Turning on a strict DMARC policy too quickly. DMARC can protect a domain, but jumping to aggressive enforcement before discovering all legitimate senders can interrupt real mail. Monitoring first is often the safer operational path.

Ignoring third-party senders owned by other teams. Marketing, finance, support, product, and IT may all use different systems. A successful email authentication DNS setup is as much inventory work as technical work.

Testing only from one mailbox. One successful message does not prove the whole setup is healthy. Test inbound, outbound, automated messages, replies, and cross-provider delivery.

Changing DNS without understanding where it is authoritative. Editing a stale zone at a registrar while the active name servers point elsewhere solves nothing and wastes valuable time during an incident.

Bundling too many changes together. If you are changing web hosting, registrars, DNS providers, and email platforms at once, troubleshooting becomes harder. Sequence the work when possible. If you are evaluating hosting alongside DNS management responsibilities, articles like Best Web Hosting for Small Business Websites: Features, Limits, and Tradeoffs and Best Managed Hosting for Growing Sites: What You Get for the Higher Price can help frame control and support tradeoffs.

When to revisit

Email DNS is not a one-time setup. Treat it as a living part of your domain operations. Revisit this checklist whenever the underlying inputs change.

• Before seasonal planning cycles or major campaigns. If your organization sends more email during launches, renewals, holiday periods, or event seasons, confirm authentication before volume increases.
• When you add or remove an email tool. New providers often need records; retired providers should usually lose authorization.
• When you migrate hosting, DNS, or domains. Even if the goal is unrelated to email, shared dashboards and control panels can introduce accidental edits.
• When staff ownership changes. If the person who originally configured the mail stack leaves, perform an audit while context can still be recovered.
• When deliverability changes. A rise in spam placement, bounce notices, or customer reports about missing mail is reason enough to inspect the DNS layer again.
• On a recurring schedule. For many teams, a lightweight quarterly or twice-yearly review is enough to catch drift.

For practical use, end with this short action list:

1. Locate the authoritative DNS zone for the domain.
2. Export all current email-related records.
3. Confirm who handles inbound mail and who sends outbound mail.
4. Verify one MX set, one SPF policy per hostname, DKIM for each active sender, and a DMARC record with monitored reporting.
5. Test real message flows after every change.
6. Document record ownership and set a date for the next review.

That routine is simple, but it prevents a large share of avoidable email failures. As providers change, tools come and go, and domains move between registrars or hosting environments, this checklist remains useful because the operational questions stay the same: who receives mail, who is allowed to send it, how is it authenticated, and how will you know when something drifts.