Your Email Security Is a DNS Configuration Problem

Every email authentication control you deploy is a DNS record. Not "backed by" DNS, not "uses" DNS. It is a DNS record, and when email security breaks, it almost always breaks at the DNS layer, not the protocol layer.

That reframing is worth more than it sounds. Teams burn hours reasoning about DMARC policy semantics when the real problem is a DKIM key that got split across two TXT strings incorrectly, or an SPF record that quietly blew past its lookup budget. If you treat email auth as a set of protocols, you debug at the wrong altitude. Treat it as DNS hygiene, and the failures get obvious.

Here is the whole stack, and where each piece actually lives.

The Controls Are All Just Records

• SPF is a TXT record at your domain apex: v=spf1 include:... -all. It lists who may send.
• DKIM is a TXT record at <selector>._domainkey.yourdomain holding a public key: v=DKIM1; k=rsa; p=<base64>.
• DMARC is a TXT record at _dmarc.yourdomain: v=DMARC1; p=reject; rua=.... Policy plus reporting.
• MTA-STS is a TXT record at _mta-sts.yourdomain (v=STSv1; id=...) that points at a policy file served over HTTPS. Half DNS, half web server, which is its own trap (below).
• TLS-RPT is a TXT record at _smtp._tls.yourdomain: where to send TLS failure reports.
• BIMI is a TXT record at default._bimi.yourdomain pointing at your logo, plus a VMC over HTTPS for the verified checkmark.

Then the plumbing everyone forgets is also DNS: MX for routing, PTR for reverse DNS on your sending IPs, A/AAAA for the hosts. Your entire email security posture is a handful of DNS records that have to be correct, resolvable, and consistent with each other. That is the job.

Where It Actually Breaks

None of the following are protocol misunderstandings. They are DNS mechanics.

The 255-byte string limit. A single character string in a TXT record maxes out at 255 bytes (RFC 1035). A 2048-bit DKIM public key is longer than that, so it has to be published as multiple strings that the resolver concatenates back together. Split it in the wrong place, or let a DNS panel add a stray space or drop a quote, and the key no longer parses. The signature was fine; the record is broken. opendkim-genkey pre-splits the value for exactly this reason.

The SPF ten-lookup budget. SPF is not just text. Every include, a, mx, ptr, and exists term, plus a redirect, forces a DNS lookup during evaluation, and RFC 7208 caps the total at ten. Go over and receivers return permerror, which in practice means SPF fails. The trap is recursion: one include: pulls in a provider's own record, whose includes count against your ten as well. Three includes on the surface can be eleven lookups once resolved. There is also a quieter limit of two "void" lookups (terms that resolve to nothing), so a stale include pointing at a dead domain can sink the whole record on its own.

CNAME delegation chains. Providers rarely hand you a key to paste. They hand you a CNAME so your selector delegates to their DNS and they can rotate keys without touching your zone. Fine, until the chain breaks, loops, or someone tries to CNAME the apex, which the DNS spec forbids because the apex already carries SOA and NS records. A broken selector CNAME means DKIM cannot resolve, the signature cannot be verified, and DMARC loses its aligned identifier.

Organizational-domain resolution. DMARC alignment and policy discovery both need to know your registrable domain, so that news.example.com and example.com count as the same organization. That determination has historically leaned on the Public Suffix List, which is how a resolver knows example.co.uk is registrable but co.uk is not. A stale or missing PSL, a real problem in some self-hosted DMARC filters, makes relaxed alignment behave like strict and reject legitimate subdomain mail. DMARCbis moves this to a DNS tree-walk, but either way it is a lookup problem, not a policy problem.

TTL and caching. DNS changes are not atomic. You fix an SPF record, but resolvers that cached the old one keep serving it until the TTL expires, so mail intermittently passes and fails for hours while you swear the record is correct. Lower the TTL before you make a change, not after.

Wildcards and non-existent records. A wildcard *.yourdomain TXT can accidentally answer a _dmarc or _domainkey query with the wrong content, and the difference between an empty TXT and NXDOMAIN matters to an SPF evaluator that is counting void lookups. Absence is a value here, not a no-op.

MTA-STS split brain. This one earns its own paragraph. The policy that says "require TLS" lives in a file at https://mta-sts.yourdomain/.well-known/mta-sts.txt. The DNS TXT record only carries an id. Senders cache your policy and only refetch the HTTPS file when that DNS id changes. So if you tighten the policy on the web server but forget to bump the id in DNS, every sender that already cached you keeps enforcing the old version. Two sources of truth, one of them DNS, and they have to move together.

Large answers and truncation. Publish a 4096-bit DKIM key and your TXT answer can outgrow a UDP DNS packet, forcing a fallback to TCP that some resolvers and middleboxes handle badly. 2048-bit is the common default partly to stay out of this failure mode. The cryptography did not fail; the transport did.

Debug at the DNS Layer

The practical upshot: when authentication misbehaves, stop reading the protocol spec and go look at what actually resolves.

• dig +short txt yourdomain, read the SPF record, then follow every include and count the lookups.
• dig +short txt selector._domainkey.yourdomain and confirm the key is present, whole, and parses.
• Check that _dmarc.yourdomain exists and that your organizational domain resolves the way you think it does.
• Confirm the MTA-STS id in DNS matches the policy you are actually serving over HTTPS.
• Do all of it from more than one resolver, because caching means your answer is not everyone's answer.

A cross-record checker that pulls these together in one view (I build one at Relaymetry) saves the round-trips, but plain dig gets you there too. The point is the altitude. You almost never have an email authentication problem. You have a DNS record that is too long, delegated through a broken CNAME, over its lookup budget, or cached stale. Fix the records, and the protocols take care of themselves.