DNS Records for Email

The complete checklist

MX record

Format: example.com. IN MX 10 mail.example.com.

Multiple MX records create a priority list. Lower numbers are tried first. Common pattern: primary MX at priority 10, backup MX at priority 20 pointing to a different server. If your domain uses a cloud mail provider (Google Workspace, Microsoft 365, Fastmail), the provider gives you the exact MX records to publish — usually 3-5 entries at different priorities.

An MX record cannot point at an IP address directly; it points at a hostname, which must have an A or AAAA record. See what is an MX record for the full mechanics.

SPF

Published as a TXT record on the root of the domain:

example.com. IN TXT "v=spf1 include:_spf.google.com include:mailgun.org -all"

Lists IPs or other SPF-publishing domains authorized to send as example.com. Receivers check the envelope sender's domain against this record. See how SPF works.

DKIM

Each sending service publishes a DKIM public key at a selector hostname:

selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0..."

The selector (here, selector1) identifies one of potentially many keys for the domain. Outgoing mail is signed with the corresponding private key; receivers fetch the public key from DNS to verify. See how DKIM works.

DMARC

One TXT record at _dmarc.example.com:

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; pct=100"

Ties SPF and DKIM together. Tells receivers: if both fail, what should you do (none / quarantine / reject), and where should you send aggregate reports. The aggregate reports are how you see what's happening with mail authentication for your domain. See how DMARC works.

MTA-STS

Two pieces: a TXT record plus an HTTPS-served policy file.

_mta-sts.example.com. IN TXT "v=STSv1; id=20260529093000Z"

# Plus a policy file at:
# https://mta-sts.example.com/.well-known/mta-sts.txt

The DNS record gives the policy version and ID; the HTTPS file gives the actual policy contents. See STARTTLS and MTA-STS.

TLS-RPT

_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

Tells sending servers where to send daily aggregate TLS reports. Useful for monitoring whether MTA-STS is breaking delivery.

BIMI

default._bimi.example.com. IN TXT "v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/vmc.pem"

Provides a logo URL (and optionally a Verified Mark Certificate) that some mail clients display next to authenticated, DMARC-passing mail from your domain. Requires DMARC at p=quarantine or stricter. See what is BIMI.

Reverse DNS (PTR)

Maps an IP address back to a hostname. Format example: 1.2.3.4 reverse-resolves to mail.example.com via a PTR record in the 1.2.3.in-addr.arpa zone.

Most mail receivers verify that the sending IP has a PTR record and that the PTR hostname forward-resolves back to the same IP. Mismatch or missing PTR is a strong spam signal. PTRs are controlled by whoever owns the IP block — typically your ISP or hosting provider — so configuring one requires a control-panel action or a support ticket. See reverse DNS and email.

Subdomain delegation patterns

Many large senders delegate email to a dedicated subdomain:

• mail.example.com — transactional mail (receipts, password resets).
• newsletter.example.com — marketing/bulk mail.
• example.com — corporate (HR, executive correspondence).

Each subdomain has its own SPF, DKIM, and DMARC records. A reputation hit on the marketing subdomain doesn't affect transactional mail or corporate mail.

What goes wrong with email DNS

• Multiple SPF records on the same name. Only one TXT can have v=spf1. Multiple is invalid; receivers may reject.
• SPF too many lookups. SPF limits to 10 DNS lookups during evaluation; using too many include: directives blows the limit and fails.
• DKIM selector mismatch. The selector in the email's DKIM-Signature header must match a published selector. Wrong selector = unsigned.
• DMARC policy at root but mail sent from subdomain. DMARC at example.com applies to mail from example.com; mail from news.example.com needs its own DMARC or aligns to the root via subdomain policy.
• Forgetting to add a record after switching mail providers. Old SPF includes break authentication for the new provider.

Verification tools

Several free tools check email DNS:

• Sending a test email to check-auth@verifier.port25.com returns a verbose authentication report.
• MXToolbox, mail-tester.com, and similar provide GUI checks.
• DMARC aggregate reports (delivered to your rua address) show real-world results.

Run all three after any DNS change.

Frequently Asked Questions

What DNS records does a domain need to send email?

At minimum: an MX record telling other servers where to deliver mail to your domain, an SPF TXT record listing who's allowed to send as your domain, DKIM TXT records publishing the public keys your outgoing mail is signed with, and a DMARC TXT record telling receivers what to do with unauthenticated mail. Strongly recommended: MTA-STS for transport TLS, TLS-RPT for reporting, BIMI for logo display, and a PTR record (reverse DNS) for sending IPs.

What is an MX record?

A DNS record that tells the world which mail servers handle incoming email for your domain. Each MX record has a priority and a hostname; the sending server tries the lowest-priority host first, falling back to higher priorities on failure. Without MX records, email cannot be delivered to your domain.

Why do email DNS records use TXT instead of dedicated types?

SPF, DKIM, DMARC, MTA-STS, TLS-RPT, and BIMI all started as conventions layered on top of generic TXT records because adding new DNS record types is operationally hard. SPF briefly had a dedicated SPF type that was deprecated in favor of TXT. The downside is that TXT records can collide if multiple services use the same name; the upside is universal DNS-provider support.

What is a PTR record and do I need one?

A reverse DNS record mapping an IP address back to a hostname. If you run your own mail server, the IPs you send from need PTR records matching your sending hostname or many recipients will reject your mail as spam. PTRs are controlled by the IP owner (your ISP or hosting provider), not by you, so they typically require a support request or control-panel action.

What does a CNAME record have to do with email?

Most email service providers (Mailchimp, SendGrid, AWS SES, Postmark) ask you to add CNAME records for DKIM keys and tracking domains. The CNAME points from a subdomain of yours to a record they control; that lets them rotate keys or change configurations without you having to update DNS each time.