The complete guide to email DNS records

Seven kinds of DNS record decide whether your mail is delivered, trusted, private in transit, and eligible for a logo in the inbox. Here's each one, what it does, what receivers do with it, and how they chain into a working setup.

MX — where mail for your domain goes

MX records point inbound mail at your mail server. They say nothing about sending. A common beginner mistake is “fixing” deliverability by touching MX — receivers never consult MX for outbound mail.

yourcompany.com.  3600  IN  MX  10 mx.yourcompany.com.

SPF — which servers may send as you

One TXT record listing the servers allowed to send mail claiming to be from your domain. Receivers check the connecting server against it. Two hard rules: a single SPF record per domain ( publishing two is a syntax failure ), and 10 DNS lookups maximum — nested include: chains that exceed it fail for everyone.

yourcompany.com.  3600  IN  TXT  "v=spf1 include:yourmailhost.com -all"

DKIM — the cryptographic signature

Your mail server signs every message with a private key; the public key lives in DNS at selector._domainkey.yourcompany.com. Receivers verify the signature — proof the message wasn't tampered with in transit, and the strongest alignment signal for DMARC. Each sender uses its own selector, which is why big providers publish several.

s1._domainkey.yourcompany.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBg..."

DMARC — the policy that ties them together

DMARC adds the alignment requirement ( the From domain must match what passed SPF or DKIM ) and lets you choose the consequence of failure: monitor ( p=none ), spam-folder (quarantine ), or bounce ( reject ). Its rua address receives the aggregate reports that show who's sending as you. The full rollout playbook is its own guide: DMARC explained.

MTA-STS — forcing TLS for inbound mail

A DNS TXT record at _mta-sts.yourcompany.com that tells senders: “my MX supports TLS 1.2+, here's the policy.” Senders fetch the policy over HTTPS and refuse cleartext delivery to you. It closes the downgrade-stripe attack where an attacker forces an unencrypted hop. Details in What is MTA-STS?

TLS-RPT — the delivery-error reports

The companion to MTA-STS at _smtp._tls.yourcompany.com. When a sender fails to deliver to you over TLS, you get a report — the only visibility you have into whether your TLS posture actually works in the wild.

BIMI — the logo, earned

BIMI displays your verified logo next to mail in supporting inboxes. The catch: most providers require DMARC at p=quarantine or p=reject first, plus a Verified Mark Certificate you buy. It's the last record, not the first — a reward for finishing your authentication rollout, not a shortcut.

How they chain together

1. Sender connects → receiver checks SPF ( is this server allowed? )
2. Receiver verifies DKIM ( is the signature valid? )
3. Receiver applies DMARC ( did either PASS align with the From domain? what does the policy say about failures? )
4. Inbound to you: senders enforce MTA-STS, report failures via TLS-RPT
5. Fully authenticated mail may earn BIMI branding

Miss a step and the chain breaks at that step. You can check where any domain's chain stands — SPF, DKIM, DMARC, MX, MTA-STS — free with the email deliverability checker. On SuperMailOS, every one of these records is generated from the mail server's zone and verified during domain setup, so the chain is complete on day one.