Email DNS Setup Guide: SPF, DKIM, DMARC, MX Records, and Troubleshooting

Overview

Email DNS records live in the DNS management panel for your domain. They do not usually contain your mailbox content; instead, they publish instructions that email systems use to locate mailboxes and assess sending authority.

The four records have different jobs:

Exact hostnames, selectors, include domains, and verification values must come from the email provider you actually use. Treat examples in this guide as syntax illustrations, not as values to copy into production. Before changing records, identify every legitimate sender, including your mailbox provider, contact forms, support tools, marketing platforms, billing systems, and application servers.

If you need a broader introduction to DNS record types, see DNS Records Explained: A, AAAA, CNAME, MX, TXT, and SRV Records With Examples.

Checklist by scenario

Scenario 1: Setting up a new domain mailbox

1. Confirm the authoritative DNS provider. Make changes where the domain's active nameservers point. Editing records at a registrar will not help if another DNS service is authoritative.
2. Record the existing state. Export or document current MX, TXT, and related records before making changes. Note the time, hostname, value, and TTL where available.
3. Add the provider's MX records. Enter each destination exactly as supplied and preserve its priority. A lower numeric priority generally indicates preference, but follow the provider's instructions rather than assuming an order.
4. Remove obsolete MX records carefully. Leaving records for an old mailbox provider can send different messages to different destinations or cause unpredictable delivery.
5. Add the provider's verification record. This is commonly a TXT record at the root of the domain or at a specified hostname.
6. Publish SPF. Add the provider's authorized sending mechanism to the domain's existing SPF policy. Do not create a second SPF record.
7. Enable DKIM. The provider may ask you to publish one or more TXT or CNAME records under a selector hostname. Copy the selector and value exactly, including punctuation and line handling.
8. Start DMARC conservatively. A monitoring policy such as p=none can help you observe reports before requesting quarantine or rejection. Move to a stricter policy only after legitimate sources are identified and aligned.

Scenario 2: Adding a new sending service

1. List the new service's sending domains, DKIM selectors, SPF include value, and any required verification records.
2. Check whether the service sends from your visible domain or from a separate provider-managed domain.
3. Merge the service into the existing SPF record rather than publishing a new SPF record.
4. Publish and test DKIM before sending a campaign or automated notification.
5. Review DMARC reports after the change. A new sender may pass SPF but still fail DMARC alignment if its envelope-from domain differs from the visible From domain.
6. Update internal documentation and remove the service's records when the integration is retired.

Scenario 3: Moving mail to a different provider

1. Lowering the DNS TTL in advance may make a later change easier to roll back, but it does not guarantee instant propagation.
2. Prepare mailboxes, aliases, forwarding rules, and authentication at the new provider before changing MX records.
3. Schedule the MX change when you can monitor both old and new systems.
4. Change MX records as a complete set, following the new provider's priority instructions.
5. Keep the old service available for a transition period if appropriate, but avoid leaving conflicting records indefinitely.
6. Send test messages in both directions and verify that applications using SMTP or API credentials still work.

Scenario 4: Troubleshooting a bounce or spoofing report

1. Read the bounce text and identify whether the failure concerns MX lookup, SPF, DKIM, DMARC, reputation, mailbox status, or a provider-specific restriction.
2. Check the message's authentication results for SPF, DKIM, and DMARC. A passing check is not enough if the authenticated domain is not aligned with the visible From domain.
3. Compare the sender's actual infrastructure with your documented list of authorized services.
4. Inspect recent DNS changes and confirm that the query is reaching the authoritative nameservers.
5. Use a test message and a DNS lookup tool to validate the public records from outside your network.

What to double-check

SPF syntax and scope

SPF is published as a TXT record, usually at the root of the domain. A simple illustrative policy might look like v=spf1 include:sender.example -all, but the correct include value must come from your provider. If multiple services send mail, combine their authorized mechanisms in one SPF record. Multiple separate records beginning with v=spf1 can produce an evaluation error.

Review SPF whenever a vendor is added or removed. Also check whether an application sends directly from a cloud server, VPS, website host, or transactional email service. A server's IP address is not automatically authorized just because it hosts your website.

DKIM selector names

DKIM records are selector-specific. The hostname often follows a pattern such as selector1._domainkey.example.com, but the provider determines the selector. A missing character, incorrect zone suffix, or pasted quotation mark can prevent verification. If the provider supplies a CNAME, do not replace it with a TXT record unless its documentation explicitly says to do so.

DMARC alignment and policy progression

DMARC evaluates whether SPF or DKIM passes with alignment to the visible From domain. Begin by collecting information with a monitoring policy, then investigate every legitimate source shown in reports. After testing, some organizations choose a quarantine policy, and later a reject policy, but the appropriate progression depends on the domain's senders, operational tolerance, and reporting coverage.

A starting template is v=DMARC1; p=none; rua=mailto:dmarc@example.com. Replace the reporting address with one you control and confirm that your chosen reporting service can receive the report format. Do not publish a strict policy without understanding which business systems send as the domain.

MX records and subdomains

MX records for example.com do not automatically configure mail for sub.example.com. Check the exact domain used in the message's recipient address. Also verify that MX targets resolve to address records and that the target is a hostname rather than an IP address when the provider requires a hostname.

Propagation and validation

DNS changes can appear at different times because recursive resolvers cache answers according to TTL. Check from more than one network or DNS lookup service, and compare the result with the authoritative zone. A local result can remain old even after the authoritative record has changed. Record the time of each change so support teams can distinguish an unchanged record from a cached response.

Common mistakes

• Publishing two SPF records: merge authorized mechanisms into one policy.
• Changing nameservers unintentionally: a nameserver change can replace the entire authoritative DNS zone, not just email records.
• Using website DNS values for email: A or CNAME records for a website do not replace MX, SPF, DKIM, or DMARC records.
• Copying an example literally: provider-specific domains, selectors, and IP addresses must come from current provider instructions.
• Enforcing DMARC too quickly: legitimate automated mail may be rejected if it was not included in the inventory and tested.
• Ignoring third-party senders: forms, ticketing systems, invoices, and monitoring tools often send mail separately from the main mailbox provider.
• Testing only one destination: test personal, business, and external recipient addresses where appropriate, and inspect full message headers.
• Forgetting reverse changes: remove retired provider records and update runbooks after a migration is complete.

When to revisit

Use this checklist whenever you register a domain, change nameservers, move mail, add a marketing or transactional sender, deploy an application that sends notifications, or see a sudden increase in bounces or spoofing reports. It is also useful before seasonal planning cycles when campaign tools, vendors, or sending volumes may change.

At each review, confirm the authoritative DNS provider, inventory all legitimate senders, inspect MX and TXT records, verify DKIM selectors, review DMARC reports, and test a real message path. Keep a dated record of the intended configuration and the person or system responsible for each sender. If your website and email are hosted separately, document that boundary clearly; the DNS changes for one should not be assumed to configure the other.

For a complete launch review, combine this email checklist with the Website Launch Checklist: Domain, DNS, Deployment, Email, Security, and Monitoring. If you are connecting a domain to a cloud server, see How to Connect a Domain to Cloud Hosting: DNS, SSL, and Verification Guide. Finish by sending test messages, checking authentication headers, and saving the final DNS record set so the next change starts from an accurate baseline.