Why one-time fixes fail

A deliverability fix is a snapshot of a moving system. The forces that undo it, their timelines, and why nobody in a small company owns email health.

Last updated 19 July 2026

A deliverability fix is a photograph of a moving system. The audit can be thorough, the fixes correct, every check green on the day you close the ticket, and none of it tells you anything about your setup next quarter. One-time fixes don't fail because they were bad fixes. They fail because the thing they fixed keeps moving after everyone stops looking.

The cycle

Here's how it goes, and if you've been sending email for a few years you may recognize your own history in it.

Something hurts. Open rates dip, a campaign folders badly, a big client says "your invoice was in my spam". Someone runs a checker, or hires a consultant, or spends a weekend with header dumps and DNS lookups. Real problems get found, because there are almost always real problems: a second v=spf1 record from a tool added last spring, no DMARC record at all, a DKIM selector pointing at nothing. The problems get fixed. Everything turns green. There may even be a document.

Then attention returns to the actual business, which is where attention belongs, and the setup enters its quiet second life as a thing everyone believes is handled.

A year later the dip comes back. The next audit finds a different problem in the same domain, the fixing happens again, and the cycle has a name I use a lot: audit, fix, forget. The audit was competent both times. The fix held both times. The forgetting is the part that failed, because it converted a correct answer into a stale one and nobody was assigned to notice when.

Entropy keeps a calendar

"Things drift" sounds abstract, so let me put rough timelines on the specific forces that undo a fix. These are patterns, the kind we watch play out across sending domains, so treat the numbers as textures rather than laws.

Your website gets rebuilt more often than you think. A small company replatforms, redesigns, or changes hosting agency every year or two, and web work is when DNS gets opened and edited by people with no reason to know that TXT records carry your email authentication. If a fix was applied in January, the odds that someone has been inside the same DNS zone for unrelated reasons within eighteen months are high. The previous lesson's decay surfaces enter through exactly this door.

New tools arrive a few times a year. A CRM, a billing system that emails receipts, a survey platform, a cold outreach tool. Each one either authenticates properly against your domain or quietly sends "as you" without authorization, and each setup session is a fresh visit to the DNS editor by someone following a vendor's paste-these-records instructions under time pressure. The second-SPF-record mistake is born in precisely these sessions.

The rulebook itself moved twice recently. Gmail and Yahoo's bulk sender requirements took effect in February 2024, and Microsoft phased in equivalent requirements for its consumer Outlook domains from 2025 (the full rules are covered in section one; Google's version is published in its sender guidelines). A setup audited as perfect in 2023 met a different exam a year later, records untouched. There is no reason to assume the rulebook is finished moving.

And your providers migrate on their own schedule. ESPs rotate infrastructure, retire record schemes, and rebrand entirely: Kit was ConvertKit until recently, Brevo was Sendinblue, and Brevo's newer accounts get different record names than its older ones. You don't get a vote on the timing, and sometimes you don't get an email either.

Put those four on one calendar. The question stops being whether your fixed setup will drift and becomes which quarter.

Nobody owns this

There's a structural reason the forgetting always wins in small companies, and it's worth naming plainly: email health has no owner.

The marketer owns campaigns and is judged on their results, but has usually never logged into the DNS host and shouldn't have to. The web person, or the agency that built the site, owns DNS but thinks of it as website plumbing; a DKIM selector means nothing to them, and honestly, why would it? If there's an IT function at all, it owns mailboxes and laptops, and considers marketing mail to be marketing's problem.

So every one of the decay surfaces falls into the seams between these people. The person most likely to cause the damage (whoever edits DNS) is the person least likely to feel it, and the person who feels it (whoever watches open rates) is the person furthest from the cause and least equipped to connect a spring website migration to a summer engagement slump. When the symptom finally surfaces, there's no shared vocabulary to even discuss it with. I've watched this conversation fail in both directions.

If you've read this far into a deliverability course, I have news: at your company, the owner is probably becoming you.

What I'm selling, and what I'm not

Time to declare the obvious bias. Inbox Decay is a monitoring product. This whole section argues that setups decay and that point-in-time fixes have a shelf life, and yes, that argument leads somewhere I make money. You should weigh everything I say here with that in mind.

So here's the version of the thesis that survives even if you never give us a cent: the practice that matters is continuous outside-in verification. Outside-in means checking what public DNS and delivered mail actually say, the way receivers see it, rather than trusting your ESP's setup screen. Continuous means on a schedule, forever, because the previous sections just established that "verified once" expires.

You can run that practice entirely by hand. Put a monthly reminder in your calendar to run the free health check on your sending domain. Re-run it after any website work, and after any tool is added or removed. Read what changed since last time. That's the whole discipline, it costs nothing, and if you do it faithfully this course has done its job.

What the paid product adds is honestly described as one thing: it removes the human from the remembering. Monitoring re-checks your domains daily and emails you when something changes, with the fix attached, so detection stops depending on whether anyone felt like checking that month. What it cannot do, and no tool can, is stop the decay itself. Your records will still get edited, your providers will still migrate, the rules will still tighten. Monitoring only shortens the time between something breaking and you knowing, from weeks down to a day. Given the symptom lag from the last lesson, that gap happens to be where most of the damage lives.

Next: how each record actually rots

The thesis is now on the table: setups drift, fixes expire, and in most companies nobody is watching the gap. What the argument still owes you is mechanism. The next module walks the specific failure paths record by record: how SPF records rot as includes pile up toward the 10-lookup limit and second records sneak in, how DKIM breaks when selectors vanish and keys age, how DMARC policies drift out of sync with what actually sends, and the decay that happens entirely outside your DNS. That's where the abstract word "drift" turns into named records you can go look at on your own domain.

Terms from this lesson

audit-fix-forget cycle - the recurring pattern where a real problem gets competently found and fixed, attention moves on, and drift silently restores the problem in a new form.
point-in-time audit - a one-off inspection of an email setup; accurate for the day it runs and increasingly stale afterward, because the system it measured keeps changing.
entropy source - any recurring force that degrades a working setup: web work touching DNS, new tools, rule changes, and provider migrations are the big four.
ownership gap - the structural hole in small companies where the marketer doesn't own DNS and the web person doesn't own email, so email health belongs to nobody.
outside-in verification - checking your setup from public DNS and delivered mail, the vantage point receivers actually use, instead of trusting your provider's dashboard.
continuous monitoring - outside-in verification repeated on a schedule, so a change gets detected close to when it happens instead of when its symptoms surface.

Check yourself

1. Why does a competent, correct deliverability fix stop protecting you?

2. Which of these is an entropy source with a realistic recurring timeline?

3. What is the ownership gap in a typical small company?

4. What does continuous monitoring actually change about decay?