How email authentication quietly breaks deliverability

Nothing bounced. The sending dashboard says one hundred percent delivered, and it is telling the truth: every message was accepted by the relay. Open rates have been sliding for a fortnight, and the only theory anyone has floated so far is subject-line fatigue.

What actually happened is that a marketing tool was added to the stack last month. It sends from your domain, so to make it work someone appended another include to the SPF record. That tipped the record over ten DNS lookups, the hard limit, and SPF now returns a permerror. DMARC, set to quarantine, started doing exactly what it was told to do. Gmail and Microsoft began routing your mail to spam.

Why nothing reports an error

Email authentication fails without a single error you can see. A 250 from the relay means the message was accepted for delivery, not that it reached an inbox. Whether it lands in front of someone or in a spam folder is decided downstream, by the receiver, silently. No bounce, no 500, no red light. From your side, the pipeline is perfectly healthy.

The signal nobody is reading

The evidence does exist. DMARC aggregate reports describe precisely which sources are failing alignment, in XML, delivered daily to an address that on most teams no human has ever opened. The other signal is engagement, and falling engagement looks like a marketing problem, not an infrastructure one.

So the team treats it as a marketing problem. They rewrite subject lines. They test send times. They prune the list. For a month the effort goes into the content of the emails, when the cause is a DNS record that crossed a lookup limit the afternoon a new tool was onboarded.

Most email-authentication incidents are investigated as a content problem first, because the infrastructure never raised its hand.

Why it is so easy to trip

Authentication drifts as a side effect of ordinary work. Adding a CRM, a help desk or an invoicing service that sends on your behalf almost always means touching SPF, and the ten-lookup ceiling arrives faster than anyone expects. A DKIM key gets rotated and not republished. A subdomain inherits no policy at all. None of these feel like changes to email. They feel like onboarding a tool.

What monitoring actually changes

The thing that catches this is watching the records the way a receiver evaluates them: counting SPF lookups against the limit, checking DMARC policy and alignment, and noticing the moment a record changes. The alert you want is "SPF crossed ten lookups today," fired the afternoon the new tool was added, not "open rates are down," noticed a fortnight later by someone in marketing.

Crowswatch watches SPF, DKIM and DMARC for drift and for the thresholds that break validation, so a deliverability incident surfaces as a domain event on day one, instead of a slow decline someone eventually blames on the copy.