DNS is the invisible foundation of email. Without the right records, your emails won’t be delivered, authenticated, or encrypted. Here are all the DNS records a sending domain needs to know and configure.

Overview

RecordTypeRole
MXMXWhere to deliver emails for your domain
SPFTXTWho can send for your domain
DKIMTXT/CNAMEPublic key for verifying signatures
DMARCTXTSPF + DKIM alignment policy
MTA-STSTXT + HTTPSEnforce TLS encryption
TLS-RPTTXTReports on TLS failures
BIMITXTVerified logo in the inbox
PTRPTRReverse DNS for your sending IPs

MX: Where to Deliver Emails

The MX (Mail Exchange) record specifies which servers receive emails for your domain.

example.com.  MX  10 mx1.example.com.
example.com.  MX  20 mx2.example.com.
  • The number (10, 20) is the priority: lower means higher priority
  • Multiple MX records provide redundancy: if mx1 is down, mx2 takes over
  • MX servers must have a valid A record (not a CNAME)

Without an MX record, nobody can send you emails.

SPF: Who Can Send

A TXT record at the domain root listing IPs and domains authorized to send emails on your behalf.

example.com.  TXT  "v=spf1 include:_spf.google.com include:spf.brevo.com ip4:198.51.100.0/24 -all"

Key points:

  • Only one SPF record per domain (no duplicates)
  • Maximum 10 DNS lookups (include, a, mx, redirect count)
  • Always end with -all (fail) to reject unauthorized sources
  • Verify with the SPF Checker | SPF Generator

Full guide: Configure SPF

DKIM: The Public Key

A TXT record (or CNAME pointing to a TXT) under selector._domainkey.domain containing your DKIM public key.

Direct TXT Record

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

CNAME Record (Common with ESPs)

selector1._domainkey.example.com.  CNAME  selector1._domainkey.esp-domain.com.

The CNAME redirects to the ESP’s TXT record, allowing them to manage key rotation on their side.

Key points:

  • v=DKIM1: record version (mandatory)
  • k=rsa: algorithm (or ed25519)
  • p=...: the public key in Base64
  • Verify with the DKIM Checker

Guides: Configure DKIM | RSA Key Size

DMARC: The Policy

A TXT record under _dmarc.domain defining your authentication policy.

_dmarc.example.com.  TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:your-rua@example.com; pct=100"
TagRole
p=Policy for the domain (none, quarantine, reject)
sp=Policy for subdomains
rua=Address for aggregate reports
ruf=Address for forensic reports (limited support)
pct=Percentage of traffic subject to the policy
adkim=DKIM alignment (r=relaxed, s=strict)
aspf=SPF alignment (r=relaxed, s=strict)

Verify with the DMARC Checker | DMARC Generator.

Guides: Configure DMARC | Migrate from p=none to p=reject

MTA-STS: Enforcing Encryption

Two components:

DNS Record

_mta-sts.example.com.  TXT  "v=STSv1; id=20260621"

The id= must change with every policy update.

HTTPS File

Hosted at https://mta-sts.example.com/.well-known/mta-sts.txt:

version: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
max_age: 604800

MTA-STS tells sending servers they must use TLS to deliver emails to your domain.

Check: MTA-STS Checker

Guide: TLS and Email

TLS-RPT: TLS Reports

A TXT record under _smtp._tls.domain to receive reports on TLS negotiation failures.

_smtp._tls.example.com.  TXT  "v=TLSRPTv1; rua=mailto:your-tlsrpt@example.com"

Reports are in JSON format and contain failure details: expired certificate, MTA-STS policy violation, detected downgrade.

If you use Sender Audit, TLS reports are analyzed in your dashboard.

Check: TLS-RPT Checker

BIMI: Your Logo in the Inbox

A TXT record under default._bimi.domain pointing to your SVG logo and (optionally) a VMC certificate.

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

Prerequisites:

  • DMARC with p=quarantine or p=reject
  • Logo in SVG Tiny PS format
  • VMC (Verified Mark Certificate) for Gmail (paid)

Guide: Configure BIMI

PTR: Reverse DNS

The PTR record maps an IP to a hostname. It’s not in your domain’s DNS zone but in the reverse DNS zone managed by your hosting provider/ISP.

42.100.51.198.in-addr.arpa.  PTR  mail.example.com.

Key points:

  • Your sending IP’s PTR must match a valid domain name
  • That name must have an A record pointing back to the same IP (forward-confirmed reverse DNS)
  • Mailbox providers (especially Gmail) check PTR and reject emails from IPs without valid rDNS

DANE / TLSA (Bonus)

For domains with DNSSEC, the TLSA record publishes the TLS certificate fingerprint of the mail server:

_25._tcp.mx1.example.com.  TLSA  3 1 1 abc123def456...

More robust than MTA-STS (protected by DNSSEC), but requires DNS resolver DNSSEC support.

Email DNS Checklist

  • Valid MX records with redundancy
  • SPF published, under 10 lookups, ending with -all
  • DKIM published for each selector/ESP
  • DMARC published with rua= and quarantine or reject policy
  • MTA-STS configured (DNS record + HTTPS file)
  • TLS-RPT configured
  • BIMI configured (if DMARC is quarantine/reject)
  • Valid PTR/rDNS for each sending IP

Further Reading