Monitoring for decay

Monitoring for deliverability decay comes down to one rule: verify from the outside. The only view of your setup that decides anything is the one receiving mail servers get when your message arrives, and that view is built from public DNS, the message's own headers, blocklist lookups, and whatever reputation data receivers choose to publish back. Your ESP's dashboard and your DNS panel are inside views. So is your memory of the setup you did last spring. Every one of them can show green while receivers see broken.

The green checkmark is a memory

Most sending tools verify your domain once, at setup, and then display that result more or less forever. The dashboard isn't lying, exactly. It's answering a different question than the one you're asking. You want to know "is this passing now"; it's telling you "this passed at some point". Delete the DKIM CNAME during a website migration and the checkmark usually outlives the record it was vouching for.

It can be worse than stale. A domain can show as verified while the thing verification implies was never true. A failure our checkers catch regularly on Brevo setups: the account's verification code TXT record was added, the DKIM CNAMEs were skipped, and the dashboard reports the domain verified while every email still goes out signed with Brevo's domain instead of yours. The verified badge and the actual signing behavior are two different systems, and only one of them is visible to Gmail.

So the first principle of detection is to stop asking your tools how your tools are doing. Ask the network.

The four outside views

Everything a receiver knows about your domain, you can also see, from four places.

Public DNS, queried fresh from a resolver you don't control. This is where your SPF record, your DMARC record and your DKIM selectors actually live, and a dig command or any online lookup shows you exactly what a receiver retrieving them gets. Not what your DNS panel says you saved. What resolves.

The headers of a real delivered email. Send to a mailbox you control at a major provider and read the Authentication-Results header, the way you learned in reading email headers. spf=pass, dkim=pass, dmarc=pass: the receiver's own verdict on a real message, which catches everything the DNS view alone cannot, like a message that simply isn't being signed.

Public blocklist lookups. Spamhaus and its peers let you query a domain or IP directly. You are checking two distinct things (this distinction is easy to lose): your domain against domain lists like the Spamhaus DBL, and your sending IPs against IP lists like ZEN. The IPs you find in delivered headers, since on shared ESP infrastructure you rarely know them in advance.

Receiver-published feedback. Google Postmaster Tools shows Gmail's opinion of your domain reputation, and DMARC aggregate reports (the rua= stream you learned to read in reading DMARC reports) show which sources sent as your domain and whether they aligned. These are the only channels where receivers volunteer information back to you. Use them.

The watchlist

From those views, here is the concrete list worth re-checking. This is the standing checklist for a domain you care about:

• The SPF record, compared byte for byte against a known-good copy.
• The DMARC record at _dmarc.yourdomain.com, same treatment.
• Every DKIM selector you depend on still resolving and still returning a usable key.
• Blocklist status of the domain itself.
• Blocklist status of the sending IPs discovered from real delivered mail.
• Authentication results (spf, dkim, dmarc) on real sends through each tool that sends as you.
• Postmaster Tools domain reputation, for the Gmail slice of your audience.
• DMARC aggregate reports, watched for new sources and for alignment failures at known sources.

Byte for byte matters more than it sounds. A validator judges whether a record is legal; it can't judge whether the record is yours. If someone edits your SPF from ~all to +all, the record still parses, and a naive validity check shrugs. The alarm you actually want is "this record is different from the record you approved", whatever the difference is. Change is the signal. Interpretation comes second.

Cadence, or why the quarterly audit misses

Decay does not schedule itself around your calendar. The agency edits DNS on the day of the migration. The blocklisting lands the hour a neighbor on your shared IP misbehaves. If you audit quarterly and the break happens a week after the audit, you send broken mail for eleven weeks, and the first symptom you notice will be slipping engagement that someone blames on subject lines.

This is the whole argument of why one-time fixes fail, applied to detection. An audit is a snapshot; decay happens between snapshots. The economics point one way: a DNS query costs effectively nothing, so the only limit on cadence is whether anyone (or anything) is running the checks. Continuous is the goal. Weekly is the floor below which you are relying on luck.

An alert worth sending

Detection is only half the job, because an alert nobody acts on detects nothing. The design rule: an alert must name the record and the change, and hand you the fix. "Your DMARC record at _dmarc.example.com was v=DMARC1; p=quarantine; rua=mailto:... and now returns nothing; republish this value" is an alert someone fixes in ten minutes. "Attention needed on your domain" is an alert someone archives.

The failure mode has a name: alert fatigue. Every vague alert you receive and safely ignore trains you to ignore the next one, and eventually the one you ignore is real. If you build your own monitoring, be stingy. Alert on change and on failure, never on "still fine", and put the fix in the message body so acting on it costs nothing.

What monitoring can't see

Honesty about limits, because this course has been honest everywhere else. Outside-in monitoring cannot see placement: whether a given message landed in the inbox or the spam folder at a given provider is simply not published anywhere you can query. (Seed-list services claim to measure it by sending to panels of fake mailboxes; I've called that theater before and I'll stand by it.) It also can't see engagement. Opens and complaints live in your ESP's stats and in Postmaster's coarse aggregates. No DNS query will surface them.

What monitoring catches is the technical layer: records, signatures, listings, alignment. That happens to be exactly the right layer to automate, because it's the layer that breaks silently. A list-quality problem announces itself in your own campaign numbers. A vanished DKIM CNAME announces itself nowhere at all until placement has already sunk.

Where Inbox Decay sits in this

Stated plainly: the product is this lesson, implemented. It re-checks the domain-level watchlist on a schedule, grades real emails you send to a test address so the path-level results come from actual delivered messages rather than DNS guesswork, stores the known-good record values, and sends break alerts that say what changed and when we first saw it, with the fix attached. The full check list is in every check, explained and the alert behavior in monitoring and alerts. The free health check runs the domain-level pass once, on any domain, which makes it a fine way to establish your first known-good baseline.

You could also build all of this with dig and a cron job that diffs against your baseline. Genuinely. This lesson is the spec if you want to. The parts that resist a weekend script are the real-email grading and the discipline of never letting the cron job rot, which is its own small irony given the subject matter.

Before you move on: write your plan

The watchlist above is generic. Your domain's version of it is not, and writing it down is the exercise this whole section has been building toward. Ten minutes, four steps:

1. List every tool that sends as your domain. Your DMARC aggregate reports are the honest inventory here; memory is not.
2. Turn the watchlist into your watchlist: your SPF record, your DMARC record, the exact DKIM selectors each tool uses, domain and IP blocklist status, and Postmaster Tools if Gmail is a meaningful slice of your audience.
3. Capture the known-good baseline. Run the free health check, then save today's record values somewhere that survives a laptop change.
4. Pick a cadence and name the owner, human or machine, who runs the pass. If the honest answer is "nobody", write that down anyway and sit with it.

A plan that names records, values, cadence and an owner is a monitoring plan. Anything less is an intention.

The Part 5 checkpoint turns this spec into your own written plan; for the day the plan fires, repairing a decayed setup is the runbook, in the order that doesn't make things worse.

Terms from this lesson

• outside-in verification - checking your email setup from the receiver's vantage point (public DNS, delivered headers, blocklist lookups, receiver feedback) instead of trusting your tools' own status displays.
• watchlist - the fixed list of records and statuses you re-check on every monitoring pass for a domain.
• byte-for-byte comparison - alerting on any difference between a record's current value and a stored known-good copy, rather than only on values a validator flags as illegal.
• known-good baseline - a saved snapshot of your records at a moment you verified everything passing, used as the reference for change detection.
• cadence - how often monitoring checks run; the gap between checks is the maximum time a silent break can go unnoticed.
• alert fatigue - the trained habit of ignoring alerts caused by receiving vague or unactionable ones; the reason an alert must name the record and the change, with the fix attached.
• Google Postmaster Tools - Google's free dashboard showing Gmail's view of your domain's reputation and spam complaint rate.

Check yourself

1. Your ESP dashboard shows your domain as verified. What does that actually tell you?

The domain passed the provider's own check at some point, which may no longer reflect DNS realityYour emails are currently passing SPF, DKIM and DMARC at receiversYour domain is not on any blocklistReceivers will trust the provider's verification when filtering

2. Why compare records byte for byte against a known-good copy instead of just re-validating them?

Validators are too slow to run on a scheduleDNS providers forbid repeated validation queriesA harmful edit like changing the SPF qualifier to +all can still be a perfectly valid recordByte comparison also detects blocklistings

3. Why does a quarterly audit systematically miss decay?

Audits can only check DKIM, never SPFBreaks happen at arbitrary times, so a break just after an audit runs unnoticed until the next oneDNS records can only be queried once per quarterQuarterly audits are too expensive to run properly

4. Which of these can outside-in monitoring NOT observe?

Whether your DMARC record has changedWhether a delivered message passed DKIMWhether your sending IP is on a Spamhaus listWhich folder a given message landed in at a given provider