Building a Deliverability Monitoring Stack

Postmaster Tools, SNDS, FBLs, DMARC reports, TLS-RPT, bounce logs, engagement data: the full observability stack, what each layer catches, and the alerts worth paging on.

Over the past year this publication has covered a dozen data sources one at a time: Postmaster Tools and SNDS, feedback loops, DMARC aggregate reports, TLS-RPT, bounce classification, per-provider engagement. Each article ended with some version of wire this into your monitoring. This one is the wiring diagram: how the pieces compose into a stack that detects incidents in hours instead of weeks, and what is actually worth alerting a human about.

The four layers

Layer one is your own telemetry: submission counts, delivery and bounce events with parsed SMTP codes, deferral rates by provider, and engagement events, all segmented by stream and mailbox provider. It is the fastest layer, minutes behind reality, and the only one you fully control. Layer two is provider dashboards: Postmaster Tools and SNDS, authoritative but delayed by one to three days and thresholded by volume. Layer three is the report streams that arrive as email: DMARC aggregates, TLS-RPT, and FBL complaints, each covering territory nothing else sees. Layer four is external probing: seed tests and blocklist monitors, which answer questions your own traffic cannot.

The layers differ in latency and authority, and the practical rule follows: layer one detects, layers two through four confirm and localize. An incident response that waits for Postmaster Tools to move has already lost two days; one that trusts a single seed test without checking deferral logs chases ghosts.

Consolidating the streams

The architecture is unglamorous: everything lands in one queryable store. ESP webhooks and MTA logs flow in as events. parsedmarc ingests the DMARC and TLS-RPT mailboxes. The FBL pipeline from our feedback loops article writes complaint events. Postmaster Tools data arrives via its API where available; SNDS exports via its CSV endpoint. A nightly job pulls seed results and blocklist checks. None of these integrations is more than a day of work, and the compounding value is that questions spanning sources, did the Gmail spam rate move when the new template shipped, become single queries.

Alerts worth waking up for

The failure mode of monitoring projects is alert inflation: every metric gets a threshold, everything pages, and within a month everyone ignores the channel. Deliverability data is noisy by nature, volume varies, providers hiccup, single campaigns skew ratios, so the alerting principle is deltas and combinations, not levels. A 0.15% spam rate is context; a spam rate that tripled week over week while volume held steady is a signal.

The weekly review beats the perfect dashboard

Alerts catch discontinuities; drift needs a human on a cadence. The weekly ritual that keeps programs healthy is thirty minutes over five charts: volume and deferrals by provider, complaint rates against the 0.1% line, engagement by provider cohort, DMARC source triage (anything new claiming your domain), and the reputation dashboards. The DMARC triage loop from the aggregate reports article and the SPF budget check from the lookup limit article both live inside this ritual. Write down what you saw; the incident three months from now will want the baseline.

Quarterly, audit the plumbing itself: FBL registrations still active, seed panels still rotating, CNAME delegations still pointing at live vendors, alert thresholds still matched to current volume. Monitoring decays quietly, and a stack that was accurate at 100k daily messages mismeasures at a million.

From detection to response

The stack's purpose is to feed the incident response playbook with a head start. Every alert in the set above maps to a first move already documented in this series: deferrals to throttling and provider-specific diagnosis, trap hits to cohort quarantine, permerrors to DNS repair, blocklistings to the remediation sequence. The monitoring is complete when the on-call person can go from page to correct first action without a meeting, which is a documentation standard, not a tooling one.

Build layer one this month if you have nothing else; it detects most incidents first. Add the report streams next, because they are free and irreplaceable. The dashboards and seed panels can follow. A modest stack watched weekly outperforms a comprehensive one nobody reads, in exactly the way that matters: the gap between when something breaks and when you know.