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.

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.

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.

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.

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