What DNS records does a business email domain need?

When the answer changes

The required record set changes with the mail services your domain actually uses.

If the domain receives mail, publish the MX records supplied by the service receiving that mail. If the domain sends mail through one or more platforms, include each legitimate sending path in the SPF design and enable DKIM for each platform where available. A marketing platform, support system, transactional sender, and employee mailbox service can each use different authorization and DKIM settings.

A domain that never receives mail may not need MX records for that domain. It can still need SPF, DKIM, and DMARC if it sends mail or if the organization wants to publish DMARC policy for the visible From domain.

Use this decision rule:

• Mail addressed to person@yourdomain.com must arrive: publish the receiving provider's MX records.
• A service sends with yourdomain.com in the SMTP envelope: account for that service in the single SPF record for that domain.
• A service signs mail with yourdomain.com or an aligned subdomain: publish the provider-generated DKIM selector record.
• Recipients see yourdomain.com in the From field: publish and maintain a DMARC record for that domain.

Do not copy MX, DKIM, CNAME, or SPF values from another organization. Provider-generated values can be tenant-specific, and an incorrect record can interrupt mail delivery or authentication.

A DNS change also has a timing component. The published answer can differ across resolvers until cached data expires. See how long DNS propagation takes for email records before judging a newly published record as missing.

Worked business email DNS record set

The following is illustrative only. It shows record shapes, not values to publish. Obtain your real MX destinations, DKIM selector, DKIM target or public key, and SPF includes from the providers that send or receive mail for your domain.

yourdomain.com.                 MX    10 inbound.mail-provider.example
yourdomain.com.                 TXT   "v=spf1 include:spf.sender-provider.example -all"
selector1._domainkey.yourdomain.com. CNAME selector1.provider.example
_dmarc.yourdomain.com.          TXT   "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"

In this example, the MX record identifies one inbound destination. The SPF record has one v=spf1 policy. RFC 7208 specifies that multiple SPF records at the same domain create an SPF permanent error, so combine authorized mechanisms into one SPF policy rather than publishing separate records for each service.

The DKIM hostname contains selector1._domainkey. A selector lets a domain publish multiple DKIM keys. The actual selector comes from the service that signs the message. The DMARC record is at _dmarc.yourdomain.com, not at the bare domain.

DMARC policy choice is separate from record publication. A p=none record requests reporting without a handling preference for DMARC failures. Before requesting quarantine or reject, identify legitimate sources and confirm that important production messages achieve aligned SPF or DKIM authentication. How a DMARC record protects a domain and supports email delivery explains that relationship in more detail.

What to check after publishing the records

Start with the evidence you have.

If you have only a domain name, use a public DNS lookup to inspect the published MX, TXT, CNAME, and DMARC records. Look up the domain's DNS records and compare the response with the provider instructions and your approved DNS change. Public results do not prove which application sent a message, whether DKIM signing occurred, or how a receiver handled the mail.

If the provider has a domain-authentication or verification page, confirm its current status after DNS has propagated. That status is provider-specific evidence, not a message-level result.

Then send a real test message from each important production path and inspect the delivered message headers. The Authentication-Results header is standardized by RFC 8601 and can show receiver-reported SPF, DKIM, and DMARC evaluation results. Check that the message came from the exact application, branded domain, and return-path configuration that matters.

Finally, review DMARC aggregate reports after data accumulates. DNS confirms publication. Provider status confirms what that provider sees. A delivered message confirms one real mail path. Aggregate reports help reveal the sending sources and authentication results observed over time.

Record length can also matter when providers issue long DKIM keys or layered SPF policies. The DNS record length limit for email records explains the DNS constraints that can affect how a value is published.

Check the DNS records behind your business email

Use a domain DNS lookup to compare the records visible on public DNS with the values your mail and sending providers instructed you to publish. Follow that with a provider-status check and a delivered-message header check for each production sending path.

Inspect business email DNS records

A public lookup cannot prove that every sender is authorized, that a service is signing with the expected DKIM selector, or that a recipient will deliver a future message to the inbox. Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and proposes prioritized remediation work. A human reviews the evidence and applies any DNS or DMARC policy change.

Start with Palisade

For a provider-specific implementation of these authentication checks, see What is DANE and does your email need it?.