Checkpoint: deliverability decay

The rest of this course teaches systems. This part made a claim about all of them: none of it stays fixed. A passing record is a statement about today, your providers rewrite their side of the arrangement on their own schedule, the rulebook moves under everyone at once, and your list ages whether you touch it or not. I named the product after this idea, so let me say plainly what this checkpoint is: the place where the course's thesis stops being my argument and becomes your reflex, or doesn't.

You shouldn't take the thesis on trust, given that I sell monitoring, and the checkpoint is built so you don't have to. The drill asks whether the decay vocabulary is actually loaded, because "the SPF thing broke" and "a vendor restructured an include and blew our lookup budget" are different levels of employable. The scenario compresses a year of one domain's quiet rot into three decisions, each with at least one wrong turn that looks responsible while making things worse. And the lab has you produce the artifact this entire part has been circling: a monitoring plan for your own domain, written as a table, with an owner named in it.

If two drill definitions feel interchangeable, slow down there. That blur is where diagnoses go wrong.

Term drill

1/20

requirements wave

how often checks run; the longest a break can stay hiddenproviders raising the bar, reclassifying unchanged setups as substandardan include for a cancelled tool, still costing lookups and authorizationflagging any difference from the baseline, however valid the new record

Vocabulary first, then judgment. The scenario below is one domain's year, told in three visits, and every visit hinges on the same question in a different costume: which view of the setup do you trust, and when do you look? Read the feedback on every option, including the ones you rejected. In this scenario the rejected options are where the tuition is.

The setup that was perfect in January

In January you did everything this course teaches for your company's domain: records aligned, health check green, baseline values saved in a note, monthly reminder set. The company sends a weekly newsletter and transactional receipts. In March, the web agency replatforms the site and moves DNS to a new host as part of the job. They report a smooth launch: the site is up, campaigns keep sending, and the ESP dashboard still shows the domain verified.

What does the week after the migration ask of you?

Nothing yet. The project was the website; if the move had touched email, something would have bounced by now.Run the outside-in pass now, off schedule, and diff every record against the January baseline.Check the ESP dashboard: if the domain still reads verified, the records survived the move.Send the next newsletter as usual and watch open rates closely for a dip.

The lab

This lab produces the artifact the whole part has been arguing toward: your monitoring plan, on paper, specific to your domain.

Copy the table below into a note. Strike the rows that don't apply to you, add any tool that sends as your domain, and fill in the last column with a cadence you will actually keep. Then write one line under the table: who runs the pass, and on which day. A plan without an owner is an intention.

| What you check | With what (free) | How often | | --- | --- | --- | | SPF record, diffed against your baseline | dig or an online lookup | | | DMARC record, diffed against your baseline | dig, or the free health check | | | Each DKIM selector you depend on resolves to a usable key | dig, or the health check's selector probe | | | Your domain against domain blocklists | Spamhaus lookup, a multi-list checker | | | Sending IPs (from delivered headers) against IP blocklists | Spamhaus lookup | | | Authentication-Results on a real send from every tool that mails as you | your own mailbox at a major provider | | | Gmail's opinion of your domain | Google Postmaster Tools | | | New or unaligned sending sources | your DMARC aggregate reports or processor | |

Now the comparison, because it teaches in both directions. Inbox Decay splits this same work in two. From the domain alone, on a schedule, it re-checks that exactly one SPF record exists and parses inside the lookup budget, that DMARC exists and how strong the policy actually is, the MX records, the common DKIM selector names, general DNS sanity, MTA-STS and TLS-RPT, BIMI, and the domain's status on domain-level blocklists. Then, on every real email you send to your test address, it grades the path that mail actually took: the receiver-side SPF, DKIM and DMARC verdicts, the key quality of the selector that really signed, reverse DNS on the discovered sending IP, that IP against the IP blocklists, TLS across the hops, the one-click unsubscribe headers the bulk-sender rules demand, and the Return-Path domain, which quietly gets the full domain-level suite of its own. Almost no hand-written table remembers that the bounce domain exists, and it decays like everything else.

Honesty in the other direction: your table holds two rows no product takes off your hands. Nothing in our checks signs into Google for you or reads your aggregate report stream; Postmaster Tools and DMARC reports are receiver-published views, and opening them stays a human habit whichever way you monitor. The split that emerges is the honest one: records, paths, listings and baselines automate well, while the dashboards remain yours either way.

Can the DIY table match the automated coverage? On the checks themselves, mostly yes, and each row costs only minutes. Where it struggles is the two quiet columns: cadence and forever. A hand-run pass happens weekly if you're disciplined, which leaves any break up to a week of silence, and it happens forever only in theory, because the routine is itself a setup that decays: skipped in a launch week, then in a holiday week, then owned by someone who left. What the paid product buys is those two columns and nothing more mystical: re-checks on a schedule measured in days rather than in memory, and an alert that names the exact change with the fix attached. If your table has an owner who will genuinely run it, run it; this course means that. The product exists for the day that stops being true.

Then the Part 5 exam tests whether the whole decay argument stuck.