For the past couple of years, deliverability teams have been trading the same complaint: emails that pass SPF, DKIM and DMARC cleanly, sent from domains with years of good standing, are still getting kicked back with temporary errors. No spam flag, no misconfiguration, nothing in the DMARC report to explain it. Just an intermittent, seemingly random failure to deliver.
A paper headed to the MADWeb 2026 workshop in San Diego claims to have found the culprit, and it isn’t the authentication standards. It’s the DNS underneath them.
“The Fragility of DNS-Based Security Under Imperfect DNS Operation,” by Tino Hager of Mailtower.app and Professor Ronald Petrlic of the Nuremberg Institute of Technology, is built on data from a European DMARC service provider plus four months of controlled testing — 109,649 identical emails sent hourly from six domains to Microsoft- and Google-hosted accounts. The setup was deliberately boring: same server, same signatures, clean IP, domains in active use for years. If those messages failed, it wasn’t the sender’s fault. And a number of them did.
The provider split
The first thing the data showed was a stark divide between receivers. Microsoft-hosted recipients accounted for the overwhelming majority of the unexplained temp errors. Google Mail recipients barely registered. Same emails, same authentication, wildly different outcomes — which told the researchers the problem lived in how the receiving infrastructure fetched DNS data, not in the records themselves.
The DKIM key-length trap
Here’s where it gets uncomfortable. The industry has spent years pushing senders toward longer DKIM keys, and 2048-bit RSA is now the de-facto standard. Germany’s federal security agency wants 3000+ bits as of 2025. But longer keys mean larger DNS responses, and large responses are exactly what breaks.
The numbers are the headline. A 1024-bit RSA key produced zero errors on both AWS Route 53 and Cloudflare. Move to 2048-bit and Route 53’s error rate jumped to 8–9%, while Cloudflare stayed at 0.1–0.2%. Push to 4096-bit and both providers landed at 11–13%. So a sender following best practice on key strength can quietly raise their own bounce rate — and the safest move from a deliverability standpoint is the weakest one cryptographically. That’s a genuinely bad trade-off to be forcing on people.
Why Route 53 and Cloudflare diverge
The DNS-host gap comes down to a small formatting choice. Route 53 follows the classic RFCs and includes the authority section (NS and SOA records) in its responses; Cloudflare uses “minimal responses” and leaves it out. That’s roughly 140 bytes of difference — enough to push a 2048-bit key’s response over the 512-byte UDP ceiling on Route 53 while Cloudflare’s slips under it. Once you cross that line, the response needs EDNS to travel over UDP, or it gets truncated and forced to TCP. The same DKIM setup, in other words, can behave completely differently depending only on where the DNS happens to be hosted.
The missing piece at Microsoft
So why Microsoft specifically? The researchers traced an Exchange Online domain’s mail path down to a delegated nameserver — ns1-proddns.glbdns.protection.outlook.com — and found it simply doesn’t support EDNS. That’s the missing puzzle piece. When a sender’s response is large enough to require EDNS, that nameserver can’t handle it, and the message fails.
The kicker: Microsoft has already shipped a fix without flipping it on for everyone. Its newer delivery domain, mx.microsoft, introduced in March 2024 and currently used when a customer sets up DANE, does support EDNS. The authors’ recommendation is blunt — Microsoft should just route all customers through it. EDNS has been supported in Windows Server since 2008. This is a 17-year-old feature missing from one server in the chain.
TXT sprawl and the Adobe problem
The paper’s other thread is SPF, and the villain there is DNS clutter. Every SaaS tool, security product and analytics platform that asks you to “verify your domain” drops a TXT record into your zone, and over the years those pile up. Individually harmless; collectively, a problem.
Adobe.com is the cautionary tale. As of December 2025 it carried 69 TXT records — 67 of them domain-verification tokens — totalling 5,455 bytes, with the full DNS response weighing in at 5,729. A zone that large forces every SPF lookup onto TCP, dragging performance and raising the odds of a temp error. To test the theory on their own infrastructure, the researchers padded one of their domains with artificial verification entries to cross the 1232-byte DNS Flag Day threshold. Their SPF temp errors promptly doubled. The practical lesson is one deliverability people will recognise: DNS hygiene is now authentication hygiene, and clearing out dead verification records isn’t just tidying up — it cuts failures. Their suggested fix is to park verification tokens on subdomains or behind CNAMEs so they never touch the SPF lookup.
The fix nobody will use
The most pointed finding is almost a footnote. There’s already a signing algorithm that sidesteps the whole mess: Ed25519-SHA256, recommended by Germany’s BSI, with a public key small enough to fit a single TXT record, no splitting, no TCP fallback, and stronger security than RSA besides. The researchers went looking for an email provider using it. They found none. Worse, when they tested whether Exchange Online and Google Mail would even verify an Ed25519 signature on incoming mail, both rejected it outright with a syntax error. The clean solution exists, it’s standardised, and the ecosystem won’t touch it.
Why it lands now
The timing is the whole point. Google, Yahoo and Microsoft have spent the last two years turning SPF, DKIM and DMARC from nice-to-haves into hard requirements. Strict enforcement was supposed to make email safer. What this paper shows is that strict enforcement also exposes every weak joint in the DNS plumbing those checks depend on — and the senders most exposed are exactly the large enterprises with sprawling zones, long keys, strict p=reject policies and high volume. Do everything by the book and you can still watch legitimate mail vanish into a temp error, for reasons invisible from your own records.
That’s the contribution: it takes a problem the community has been muttering about and ties it to something measurable. For anyone working in authentication or enterprise deliverability, it turns “the email just didn’t arrive and I don’t know why” into a checklist of things you can actually go look at.
The full paper is at https://madweb.work/papers/2026/madweb26-paper41.pdf
