What DNS records are needed for email?

For receiving: MX records pointing to your mailbox provider. For sending: SPF (TXT record listing authorized IPs), DKIM (TXT or CNAME records with signing keys), and DMARC (TXT record at _dmarc with enforcement policy). Optional but recommended: BIMI for brand logo, MTA-STS and TLS-RPT for transport security.

What is a DNS email record?

A DNS email record is any DNS entry that controls or authenticates email flow for a domain. The core types are MX (mail routing), SPF (sender authorization), DKIM (cryptographic signing), DMARC (authentication policy), BIMI (brand identification), and MTA-STS (transport security).

How do I check my DNS records for email?

Use dig from a terminal (dig MX yourdomain.com, dig TXT yourdomain.com, dig TXT _dmarc.yourdomain.com), or MXToolbox's SuperTool (web UI). For a complete check, use a deliverability tool like Mailhardener or Mail-Tester that audits MX, SPF, DKIM, DMARC, MTA-STS, and BIMI in one report.

What's the difference between MX and SPF records?

MX records tell other mail servers where to deliver mail for your domain (inbound routing). SPF records tell receiving servers which IPs are allowed to send mail as your domain (outbound authorization). They serve opposite directions and don't overlap functionally.

Do I need DNS records if I use Gmail or Microsoft 365?

Yes. Both platforms require MX records pointing to their inbound servers, plus SPF, DKIM, and DMARC to authenticate mail you send through them. Microsoft 365 and Google Workspace set up MX and DKIM during onboarding, but you still need to publish SPF and DMARC yourself.

What is a PTR record and do I need one?

PTR (Pointer) records map an IP address to a hostname (reverse DNS). Required if you run your own mail server — many ISPs reject email from IPs without PTR records. Not needed if you use an ESP (they manage their own PTR records).

How long do DNS changes take to propagate?

Depends on TTL (Time to Live). Most changes propagate within 1-4 hours. Some DNS providers cache aggressively and may take up to 48 hours. Lower your TTL before making changes (set to 300 seconds), make the change, then restore TTL after verification.

Should I use Cloudflare proxy for email records?

No. MX records, DKIM records, and SPF records must NOT be proxied through Cloudflare. Set these to 'DNS only' (gray cloud, not orange cloud). Proxying email DNS records breaks email delivery.

DNS Records for Email: The Complete Guide

The DNS records that control email are scattered across half a dozen RFCs, multiple record types, and several non-obvious locations. A complete email DNS setup looks intimidating until you realize most of it is once-and-forget. This guide is the complete record reference — what each one does, what it looks like, and the order to publish them in to avoid breaking mail flow.

The six categories of email DNS records

Category	Records	Purpose
Inbound routing	`MX`	Where to deliver mail addressed to you
Sender authorization	`SPF` (TXT)	Which IPs may send as your domain
Message signing	`DKIM` (TXT or CNAME)	Public keys to verify message signatures
Authentication policy	`DMARC` (TXT)	What receivers should do with unauthenticated mail
Brand visualization	`BIMI` (TXT)	Logo for supported inboxes
Transport security	`MTA-STS`, `TLS-RPT`	Force TLS, report TLS failures

For a typical sending domain, you'll publish records in all six categories. Inbound-only domains need MX; sending-only domains can skip MX but still need SPF/DKIM/DMARC.

MX records

MX records tell other mail servers where to deliver mail for your domain. Format:

example.com.    MX    10  aspmx.l.google.com.
example.com.    MX    20  alt1.aspmx.l.google.com.
example.com.    MX    30  alt2.aspmx.l.google.com.

The number is the priority — lower is preferred. Multiple MX records provide failover.

For major providers, copy MX values exactly from their setup docs:

Provider	Primary MX
Google Workspace	`smtp.google.com` (modern setup) or `aspmx.l.google.com` (legacy)
Microsoft 365	`<tenant>.mail.protection.outlook.com`
Fastmail	`in1-smtp.messagingengine.com`
Self-hosted	Your inbound MTA hostname

See Gmail MX records for the Google-specific setup including the recent move from five MX records to one.

SPF (Sender Policy Framework)

SPF is a TXT record on the root of your domain listing which IPs may send as your domain. Format:

example.com.    TXT    "v=spf1 include:_spf.google.com include:sendgrid.net ip4:192.0.2.10 ~all"

Components:

v=spf1 — declares SPF version 1 (required)
include: — references another domain's SPF (chains to that domain's record)
ip4: / ip6: — direct IP authorizations
~all — softfail unauthorized (recommended); -all is hardfail

Key constraint: SPF records count "DNS lookups" and have a 10-lookup limit per RFC 7208. Each include: and most a:/mx: mechanisms count as one. Multi-ESP setups blow past the limit quickly — see SPF flattening.

The SPF setup guide covers the mechanics in depth.

DKIM (DomainKeys Identified Mail)

DKIM records publish the public key receivers use to verify message signatures. Format depends on whether the record is TXT (key inline) or CNAME (delegated to ESP):

TXT format:

selector1._domainkey.example.com.    TXT    "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQ...truncated..."

CNAME format (used by Mailchimp, Mailgun, Microsoft 365):

selector1._domainkey.example.com.    CNAME    selector1-example-com._domainkey.example.onmicrosoft.com.

The selector is arbitrary — see DKIM selector examples for naming patterns. Multiple selectors are normal (one per sender, plus rotation versions).

Minimum 1024-bit RSA per RFC 8301; 2048-bit is current standard.

DMARC

DMARC is a TXT record at the _dmarc subdomain. Minimum viable:

_dmarc.example.com.    TXT    "v=DMARC1; p=none; rua=mailto:[email protected];"

Production:

_dmarc.example.com.    TXT    "v=DMARC1; p=reject; rua=mailto:[email protected]; sp=reject; adkim=r; aspf=r; fo=1;"

See every DMARC tag explained for the full tag reference.

BIMI (Brand Indicators for Message Identification)

BIMI publishes a logo URL that supported inboxes (Gmail, Apple Mail, Yahoo, Fastmail) display next to your sender name. Format:

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

Requirements:

DMARC at p=quarantine or p=reject (at minimum 75% pct enforcement)
SVG Tiny PS logo (specific subset of SVG)
VMC (Verified Mark Certificate) for Gmail to show the logo

See BIMI setup guide for the full setup including VMC procurement.

MTA-STS and TLS-RPT

MTA-STS forces opportunistic TLS to become required TLS for inbound mail. Setup is two records plus a policy file served via HTTPS.

DNS records:

_mta-sts.example.com.    TXT    "v=STSv1; id=20260516001;"
_smtp._tls.example.com.  TXT    "v=TLSRPTv1; rua=mailto:[email protected];"

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

version: STSv1
mode: enforce
mx: aspmx.l.google.com
mx: alt*.aspmx.l.google.com
max_age: 86400

See MTA-STS setup for the full configuration. TLS-RPT (the second record) sends you daily reports on TLS failures from sending servers.

PTR records (reverse DNS)

If you run your own mail server, you also need a PTR record mapping your sending IP back to a hostname:

203.0.113.10 → mail.example.com

PTR records are set in your VPS or hosting provider's dashboard, not your domain DNS — the provider controls the reverse zone for the IP. Many ISPs reject email from IPs without PTR records. If you send through an ESP (Mailgun, SendGrid, Google Workspace), they manage PTR for their own IPs and you can skip this. See the PTR records guide.

Publishing order

Order matters. Publish in this sequence to avoid breaking mail flow:

MX (if changing inbound provider — coordinate cutover carefully)
SPF (publish in monitoring mode with ~all, not -all)
DKIM (publish before enabling signing at the sender)
DMARC at p=none for 4 to 8 weeks of monitoring
DMARC at p=quarantine with staged pct
DMARC at p=reject
BIMI (requires DMARC enforcement)
MTA-STS (publish DNS records, then policy file, then switch to enforce mode)

The mistake I see most: publishing DMARC at p=reject before any of the senders are correctly aligned. The result is legitimate mail getting blocked. Stage it.

Practitioner note: Before any DNS edit on a domain that handles production mail, take a snapshot of current records (dig ANY yourdomain.com, plus _dmarc, _bimi, _mta-sts, all known DKIM selectors). DNS providers don't always have great undo workflows, and having a baseline saves you when a coworker "cleans up" the wrong record.

Practitioner note: Before making DNS changes, lower the TTL to 300 seconds (5 minutes), wait for the old TTL to expire, then make your change. This means mistakes propagate and can be fixed in minutes instead of hours. Restore the TTL after verification.

Verifying email DNS

Use multiple sources to verify:

dig MX example.com
dig TXT example.com
dig TXT _dmarc.example.com
dig TXT selector1._domainkey.example.com
dig TXT default._bimi.example.com
dig TXT _mta-sts.example.com

Then validate parsing through:

MXToolbox SuperTool — quick all-in-one
Mailhardener — comprehensive audit with explanations
Mail-Tester — end-to-end test by sending a message

Practitioner note: Test from outside your network. DNS responses can differ depending on whether you query your authoritative server, your local resolver, or a public resolver like 1.1.1.1. Use multiple resolvers when verifying changes — especially with CNAME chains.

Common DNS mistakes

Two SPF records on the same domain. Receivers will fail SPF entirely with a permerror. Merge into one record.
TXT records over 255 characters without proper chunking. DNS allows multiple strings inside a TXT record; concatenation happens at the resolver. Most DNS UIs handle this for you, but manual edits can break it.
DKIM CNAME pointing nowhere. If the ESP's DNS chain isn't published, your DKIM record resolves to nothing and signing fails.
DMARC at the wrong location. It belongs at _dmarc.yourdomain.com, not yourdomain.com. Adding _dmarc is the common miss.
MTA-STS policy file missing or mismatched. The DNS record can be valid while the HTTPS file is misconfigured. Mail still flows but MTA-STS does nothing.
Wrong DKIM hostname. domainkey.yourdomain.com instead of _domainkey.yourdomain.com (note the underscore), or selector.domainkey instead of selector._domainkey.
Missing DKIM after ESP migration. Old ESP's DKIM records left in DNS, new ESP's records not added. DKIM fails silently. Always add new records BEFORE removing old ones.
Cloudflare proxy on email records. MX, DKIM, and tracking-domain records must NOT be proxied (orange cloud). Set them to DNS-only (gray cloud) or email breaks.

If you're standing up a new sending domain or auditing a tangled one, book a consultation. DNS audits are one of the most common requests and the cleanup pays off in deliverability fast.

Sources

v1.0 · May 2026