DNS Records for Email: MX, TXT, SPF, DKIM, DMARC and CNAME

Overview

DNS gives sending and receiving systems the public information they need to route mail and evaluate identity. An MX record answers where inbound mail for a domain should be delivered. TXT is a general text record type used to publish SPF, DKIM and DMARC data. CNAME aliases one DNS name to another and is often used when an email provider wants to manage a DKIM key or service-specific hostname on your behalf.

It is technically inaccurate to call SPF, DKIM and DMARC DNS record types. SPF is a sender-authorization policy, DKIM publishes a public key for message signatures, and DMARC publishes an alignment and handling policy. DNS is the publication channel.

Why it happens

Email crosses independent networks, so receivers need globally discoverable routing and authentication data. DNS provides that shared lookup layer. Problems arise when records are missing, duplicated, placed at the wrong hostname, copied without provider-specific changes, or split across multiple competing SPF TXT records.

How to fix it

Inventory every system that sends or receives mail for the domain before editing DNS. Check MX routing, locate the single SPF policy, identify every active DKIM selector, and review the DMARC policy and report destinations. Follow each provider's current documentation for exact hostnames and values. Then verify the public result with the matching checker and allow for DNS TTL and caching before interpreting a retest.

Examples

A domain can have MX records pointing to its receiving provider, one TXT record beginning with v=spf1, one or more selector._domainkey TXT or CNAME records for DKIM, and one _dmarc TXT record beginning with v=DMARC1. The exact targets, selectors and policy values depend on the services the domain actually uses.

Common mistakes

Common mistakes include publishing two SPF policies, placing DMARC at the root instead of _dmarc, assuming a copied DKIM selector is universal, replacing an MX target with an IP address, flattening or rewriting provider values without understanding update risk, and treating a syntactically valid record as proof that real messages authenticate and align.

Checklist

• Confirm which service receives mail before changing MX records.
• Keep exactly one SPF policy for a hostname and include every legitimate sender.
• Verify each active DKIM selector at selector._domainkey.
• Publish DMARC at _dmarc and confirm alignment on real messages.
• Use provider-documented CNAME targets exactly where delegated management is required.
• Retest after DNS TTL and resolver caches have had time to update.

MX records route inbound email

MX records contain hostnames and priorities. Lower numeric priority is preferred. The target must resolve to a mail server hostname; an MX record does not authorize outbound senders and should not point directly to an IP address.

TXT carries several email policies

TXT is a generic DNS record type. SPF uses a TXT value beginning with v=spf1. DKIM usually stores a public key in TXT beneath a selector._domainkey name. DMARC uses TXT beneath _dmarc and begins with v=DMARC1. These protocols have different jobs even though they share the TXT transport.

When CNAME is relevant

Some providers ask you to publish a CNAME for a DKIM selector so they can rotate the destination key without requiring a new customer-side value. Use CNAME only when the provider documents it; a name that is a CNAME generally cannot also hold unrelated record data.