Complete Email Security DNS Records: From SPF to BIMI Explained

Mention “email security” and most people think SPF, DKIM, DMARC. Fully protecting your domain from spoofed mail, your inbox from unencrypted traffic, and your brand from impersonation actually takes eight separate DNS records: SPF, DKIM, DMARC, MTA-STS, TLS-RPT, DNSSEC, DANE (TLSA), and BIMI. A small or mid-sized business doesn’t need all eight at once — but saying “three records is enough” without knowing what each one does, and which ones actually matter for you, leaves gaps you won’t notice until something goes wrong.

Record	Example value	What it does
SPF (TXT)	v=spf1 include:_spf.google.com -all	Lists which servers are allowed to send mail for your domain
DKIM (TXT)	selector._domainkey.yourdomain.com	Adds a digital signature to outgoing mail, proves it wasn’t altered in transit
DMARC (TXT)	_dmarc.yourdomain.com → v=DMARC1; p=quarantine; rua=...	Tells receivers what to do when SPF/DKIM fail, and collects reports
MTA-STS (TXT+HTTPS)	_mta-sts.yourdomain.com	Stops inbound mail from falling back to an unencrypted connection
TLS-RPT (TXT)	_smtp._tls.yourdomain.com	Reports TLS connection failures
DNSSEC	DS record at the parent zone	Cryptographically signs DNS answers so they can’t be spoofed
DANE / TLSA	_25._tcp.mx.yourdomain.com	Pins your SMTP server’s TLS certificate via DNS
BIMI (TXT)	default._bimi.yourdomain.com	Shows your brand logo in the recipient’s inbox

SPF: the syntax is simple, the limit isn’t

An SPF record is a single-line TXT record: v=spf1 include:_spf.google.com include:yourprovider.com -all. The difference between -all and ~all at the end looks minor but matters a lot in practice. -all means “reject anything not on this list” (hard fail); ~all means “allow it through, but flag it as suspicious” (soft fail). When you’re first setting up SPF, starting with ~all to watch traffic before moving to -all is the safer path — otherwise a sender you forgot about (your ERP, a shipment-tracking notification, a form-submission service) suddenly starts getting rejected.

SPF’s real trap isn’t syntax, it’s the limit. Section 4.6.4 of RFC 7208 caps SPF evaluation at 10 DNS lookups total; include, a, mx, ptr, exists, and redirect mechanisms all count toward that number, even when nested inside each other (ip4/ip6 don’t count, since they need no DNS lookup). Exceed the limit and the record returns permerror — receiving servers can skip SPF evaluation entirely, which means your record is effectively dead. Add Google Workspace, a marketing platform, an invoicing or shipping system, and a form service, and you can hit that cap with three or four include statements without trying. The fix is either “flattening” nested include chains down to their actual IP ranges, or regularly pruning includes you no longer use.

DKIM: selectors, key length, third-party senders

DKIM attaches a digital signature to every outgoing message; the recipient verifies it against the public key published at selector._domainkey.yourdomain.com. The selector is the tag that lets a single domain hold more than one DKIM key at a time — which is why your marketing email, your ERP, and your invoicing system shouldn’t share one. If each signs with its own selector, revoking one (say, a vendor relationship that ends) doesn’t touch the others.

For key length, RFC 8301 now recommends 2048 bits; 1024-bit keys still technically work but are considered crackable and no longer meet Google’s and Yahoo’s bulk sender requirements. A field note worth knowing: a 2048-bit public key exceeds the 255-byte limit of a single DNS TXT string, so the record has to be split into chunks automatically — enter it as one manual line and verification fails silently. There’s no fixed rule for key rotation, but rotating annually, keeping the old key live for two or three weeks alongside the new one before removing it, is a reasonable practice.

DMARC: don’t jump to reject before you’ve read the reports

DMARC sits on top of SPF and DKIM and answers “what happens when both fail”: p=none only observes, p=quarantine sends mail to spam, p=reject blocks it outright. In May 2026, DMARC’s technical specification moved from RFC 7489 to RFC 9989/9990/9991 (collectively “DMARCbis”) — the rules stayed the same, but the protocol is now on the IETF’s formal standards track.

The pct tag controls what percentage of mail the policy applies to (default 100) — starting at pct=10 and ramping up over a few weeks is a common way to enforce gradually. Alignment (aspf/adkim) can be r (relaxed) or s (strict): relaxed allows a subdomain to match the organizational domain (mail.yourdomain.com counts as aligned with yourdomain.com); strict requires an exact match. Most setups start relaxed, because strict can break legitimate sending paths, like third-party marketing tools.

Here’s what we’ve learned running our own domain: at Xen, we tighten DMARC gradually. We don’t move to p=reject until rua reports have accumulated enough that we know exactly which system is sending what, and why. Skip straight to reject without reading the reports first, and there’s usually some forgotten system — a form notification, a scan-to-email printer, an old integration — that quietly stops delivering. Nobody notices until an invoice or a proposal never reaches the other side.

MTA-STS and TLS-RPT: protecting inbound, not outbound, traffic

SPF, DKIM, and DMARC verify who sent the mail; MTA-STS (RFC 8461) guarantees whether it was encrypted in transit. The _mta-sts.yourdomain.com TXT record announces that a policy file exists; the actual policy is published over HTTPS at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. There are three modes: testing (report problems without blocking delivery), enforce (reject mail if TLS or certificate validation fails), and none (opt out). TLS-RPT (RFC 8460) uses _smtp._tls.yourdomain.com to specify where TLS connection failures should be reported. The right sequence is: run testing for a few weeks, and if nothing breaks, move to enforce. Switching straight to enforce can cause inbound mail to be silently rejected during a temporary certificate hiccup.

DNSSEC, DANE, and BIMI: not always necessary

DNSSEC cryptographically signs DNS responses so they can’t be tampered with — and it’s a prerequisite for DANE. In Türkiye, DNSSEC is supported for .tr domains through TRABİS, but it isn’t mandatory; your registrar needs to be able to manage the DS record via an API, and not every provider offers that. DANE (a TLSA record at _25._tcp.mx.yourdomain.com) pins your SMTP server’s TLS certificate through DNS, so you’re trusting DNS instead of a certificate authority. In practice, DANE doesn’t work without DNSSEC, and for most small and mid-sized businesses, it doesn’t reduce risk much beyond what MTA-STS already covers. It’s meaningful for government, financial services, or a high-target sector; for an ordinary commercial domain, it can sit at the bottom of the priority list.

BIMI puts your brand logo next to your domain name in the inbox, but the prerequisite is steep: DMARC needs to be at least at p=quarantine, ideally p=reject. If you hold a registered trademark, you’ll also need a Verified Mark Certificate (VMC); 2026 pricing varies by issuer but generally runs in the range of roughly $1,000–$1,750 a year. Gmail and some other major providers will sometimes display the logo without a VMC, but there’s no guarantee. I think that cost makes sense for high-volume senders where brand recognition in the inbox delivers a visible payoff; for a small business, moving DMARC to reject is already the more valuable step, and it comes before BIMI anyway.

Don’t leave domains that never send mail undefended

If your company owns a domain purely for brand protection and never sends mail from it — a parked domain — or a separate marketing subdomain, leaving it blank is a security gap. Adding v=spf1 -all (a null SPF record) and v=DMARC1; p=reject; (a null DMARC record) to a domain that never sends mail shuts the door on anyone spoofing it from the start.

Common mistakes

• Publishing two separate SPF TXT records: the SPF standard expects exactly one; a second record triggers permerror — merge every include into a single record.
• Putting the DMARC record on the wrong subdomain: writing dmarc.yourdomain.com instead of _dmarc.yourdomain.com (missing the leading underscore) makes the record invisible to receivers.
• Leaving your ERP, printer, or invoicing system out of SPF: forgetting to add the scan-to-email or notification traffic from your accounting software or multifunction printer to SPF usually surfaces later as “invoices aren’t reaching customers.”

Frequently asked questions

What’s the minimum before I can say I have “email security”? Without the first three — SPF, DKIM, DMARC — there’s no authentication at all. MTA-STS and TLS-RPT are the “nice to have” layer on top; DNSSEC, DANE, and BIMI depend on your scale and sector.

Should I set DMARC straight to p=reject? No. Start with p=none to collect reports, identify your full list of legitimate senders, then ramp up gradually with pct before moving to quarantine and reject.

What do I lose if I skip MTA-STS? Some of your inbound mail could travel over an unencrypted connection, and anyone intercepting traffic on the same network or an insecure Wi-Fi could read it. Most major providers already attempt opportunistic TLS, but there’s no guarantee — MTA-STS is what makes it mandatory.