What is deliverability decay?

Deliverability decay is the slow, silent degradation of an email setup that was configured correctly at some point in the past. Nothing snaps. No error appears anywhere. The records you set up carefully in January are subtly wrong by October, and mail that used to land in the inbox slides toward spam so gradually that nobody can name the week it started. I named this product after the idea, because after enough time watching sending domains I believe it is the most under-appreciated fact in email: a correct setup does not stay correct. It drifts.

Nothing snaps

When your website goes down, you know within minutes. There's an error page, a screenshot in the team chat, a support ticket. The failure announces itself, loudly, to everyone at once.

Email has no error page. When authentication breaks, your ESP (the tool you send from) keeps sending exactly as before. The dashboard still says "sent" beside every campaign, and as you know from the first lesson of this course, "sent" only ever meant "handed off". What the receiving server does after the handoff is invisible to you. It can quietly route your mail to spam, or accept it and weight it down, and no system you look at every day will mention it.

So the failure mode of email is different in kind from the failure mode of almost everything else you run. A broken website is an outage. A broken email setup is a rumor. That difference is the whole thesis of this section.

I call it decay rather than breakage because of how it accumulates. It's rarely one dramatic event. It's a TXT record edited here, a provider migration there, a rule tightened somewhere you weren't looking, months apart, each one individually survivable. The setup doesn't fail; it erodes.

The four decay surfaces

Every case of decay I've seen enters through one of four surfaces. This lesson previews them; the next module gives each one the full treatment.

Your own DNS drifts

Your SPF, DKIM and DMARC records live in the same DNS zone as your website records, and that zone gets edited by people doing web work. A migration to a new host. A redesign. An agency "cleaning up" TXT records nobody could explain. A colleague adding a new tool and pasting the SPF include in as a second v=spf1 record, which, as you learned in the SPF lesson, makes SPF fail permanently for everything, because the standard allows exactly one record.

My favorite example, because it's so innocent: some DNS providers append your domain to a pasted CNAME name, so the k1._domainkey.example.com record Mailchimp asked for ends up living at k1._domainkey.example.com.example.com. It exists. It looks right in the dashboard. It answers at a name no receiver will ever query.

Nobody who does any of this thinks they touched email. That's the point. The full anatomy of this surface is in how SPF records rot.

Your providers change things under you

Your ESP and your DNS host are both moving targets. Providers rename their record schemes across account generations (Brevo's newer accounts use brevo1._domainkey where earlier ones used mail._domainkey), rotate keys, migrate the infrastructure your CNAMEs point at, and get acquired or rebranded with everything that follows. Most of these transitions are handled gracefully. Some are not, and either way, the setup instructions you followed three years ago may no longer describe what your provider expects from you today. How DKIM breaks over time covers this surface in detail.

The outside world moves

Sometimes every record on your side is byte-for-byte identical to the day you set it up, and your deliverability still got worse, because the bar moved. The clearest case: in February 2024, Gmail and Yahoo began enforcing requirements for bulk senders that left thousands of previously acceptable setups below the new bar, and Microsoft followed with its own enforcement for consumer Outlook domains from 2025. Blocklists update continuously. On shared sending infrastructure, a stranger's bad campaign can change the reputation of the IP you send from while you sleep. This is decay you don't control, and it deserves its own lesson because the instinct to respond by auditing your own records finds nothing wrong.

Your audience ages

The fourth surface has nothing to do with configuration at all. Every list decays as a physical fact: people change jobs and abandon the address, lose interest, stop opening. You learned in the sender reputation lesson that mailbox providers read recipient behavior as a verdict on you. So a list that has gone stale produces the same downstream signal as a sender doing something wrong: engagement decline reads as reputational decline. The filters cannot tell the difference, and honestly, from where they sit, there isn't one. This is the slowest surface and the hardest to reverse.

Why you never see it happening

Two mechanisms keep all of this invisible.

The first you already know: sending never stops. Authentication is evaluated by the receiver, after the handoff. A deleted DKIM record does not disable the send button, produce a bounce, or change anything in your ESP's UI. Green checkmarks all the way down, while the actual verdict is being rendered somewhere you can't see.

The second is lag. Reputation systems are moving averages, so filters respond to a new failure gradually rather than instantly, and the visible symptom (open rates sagging, replies drying up) emerges over multiple sends across weeks. By the time someone in the business says "our opens look soft lately", the causal change is a month or more behind them, buried under everything else that happened since. The natural diagnostic question, "what changed recently?", fails, because the honest answer is "we don't know, we weren't looking".

A pattern we see monitoring domains: the breakage date and the noticing date are almost never close together. The record broke during the website migration in March. The worried email about open rates gets written in May, and the migration doesn't come up in it, because why would it? Nobody connects web work in spring to email symptoms in early summer.

The bug is the assumption

Every setup guide, ours included, has the same implicit shape: complete these steps, see everything turn green, done. The steps are right. The "done" is the bug.

"Done" is a property of tasks. Email authentication isn't a task; it's a description of the current state of a system with four open surfaces to the outside world, and a DNS record is a claim about the present tense. "These are the servers allowed to send as me" is either true right now or it isn't, and the fact that it was true in January carries no weight with a receiver evaluating your mail in October.

Once you accept that, the practical questions rewrite themselves. "Is my setup correct?" becomes "when did I last verify that my setup is correct?". You can answer the second question for your own domain in about a minute with the free health check, which reads your records as they exist today, not as you remember configuring them.

The next lesson, why one-time fixes fail, takes the argument one step further: even a perfect audit with a perfect fix has a shelf life, and I'll put rough timelines on how long that shelf life tends to be.

Terms from this lesson

• deliverability decay - the gradual, silent degradation of a correctly configured email setup, accumulating through small changes rather than one visible break.
• decay surface - one of the four directions change enters a setup: your own DNS, your providers, the outside environment, and your audience.
• configuration drift - the widening gap between what your records actually say and what everyone believes they say, produced by edits nobody connects to email.
• silent failure - a failure that produces no error in any system you routinely look at; email authentication fails silently because the receiver renders the verdict, after handoff.
• symptom lag - the delay, typically weeks, between the moment a setup degrades and the moment its visible symptoms (falling opens, fewer replies) get noticed.

Check yourself

1. Why does a broken DKIM record go unnoticed for weeks in a typical company?

Mail keeps sending normally and the visible symptoms lag the causeESPs hide authentication errors to avoid alarming customersDKIM failures only affect a small fraction of messagesReceivers send a warning email that usually lands in spam

2. Which of these is NOT one of the four decay surfaces?

Your own DNS records get edited by people doing web workYour providers rotate keys and migrate infrastructureYour audience ages and engagement declinesYour email templates go out of fashion visually

3. Your records are byte-for-byte identical to the day you set them up, yet placement got worse. Which surface explains this?

Your own DNS driftedThe outside environment moved: requirements tightened or shared reputation shiftedYour ESP deleted your recordsThis situation is impossible if the records are unchanged

4. What does the "sent" status in your ESP dashboard actually confirm?

The message reached the recipient's inboxThe message passed authentication at the receiverThe message was handed off to the receiving serverThe message avoided every blocklist