Email Monitoring: What to Watch When You Send at Scale

Email monitoring at sender scale is closer to systems monitoring than to marketing analytics. The job is to detect, in near real time, when something has shifted in how mailbox providers are treating your mail — and to alert the right person before the problem cascades. Most teams I audit have built strong marketing dashboards and almost no infrastructure monitoring. By the time a 0.4% complaint rate shows up in the weekly digest, Gmail has already filtered three days of campaigns.

This guide is the email monitoring stack I set up for clients — what to instrument, what thresholds to alert on, and which tools actually do what.

The four layers of email monitoring

Useful email monitoring covers four signal sources:

Layer	What it tells you	Primary source
ESP send data	Volume, accepted, bounce reasons, complaint webhooks	Your sending platform
Authentication	SPF, DKIM, DMARC pass rates, alignment issues	DMARC aggregate (RUA) reports
Mailbox provider feedback	Reputation, spam complaint rate, spam-trap hits	Google Postmaster, Microsoft SNDS
Inbox placement	Per-provider inbox vs spam vs missing	Seedlist testing services

Monitor only the first layer (your ESP dashboard) and you'll miss most reputation issues until users start complaining. Add all four and you can usually catch a problem the same day it starts.

ESP-layer monitoring

Your sending platform reports the most immediate signals — what happened at the SMTP transaction:

• Sent / accepted / deferred / bounced, with bounce reason codes
• Complaint feedback via Feedback Loops (Gmail, Yahoo, Microsoft via JMRP/CFL)
• Delivery latency (queue depth, time to acceptance)

What to alert on:

• Hard bounce rate above 2% on a campaign
• Soft bounce rate trending above 5%
• Complaint rate above 0.10% on any campaign
• Deferral rate above 5% (often a rate-limiting signal)

Most ESPs expose these via webhook. Pipe them into your monitoring tool of choice — Datadog, Grafana, or a custom dashboard backed by Postgres works fine.

Authentication monitoring via DMARC

DMARC aggregate reports (RUA) are the single most undervalued monitoring signal. Every major mailbox provider sends you XML reports daily summarizing authentication results for mail claiming your domain. They show:

• Every IP sending as your domain (authorized or not)
• SPF and DKIM authentication results
• DMARC alignment outcomes
• Disposition (none, quarantine, reject)

Tools that parse DMARC aggregate reports:

Tool	Strength
Mailhardener	Strong DMARC, BIMI, MTA-STS in one UI; reasonable pricing
Dmarcian	Established, strong forensic (RUF) handling
Postmark DMARC Monitoring	Free tier, focused dashboard
Valimail	Enterprise, full DMARC enforcement automation

Alert on:

• New IPs sending as your domain (unauthorized senders)
• DMARC failure rate above 1% from any aligned source
• DKIM-pass-but-SPF-fail patterns (often indicates relay/forwarding issues, not authentication problems)

Practitioner note: First time a client turns on DMARC aggregate parsing, they almost always find at least one shadow IT sender — typically a SaaS tool someone signed up for that's been sending notifications from their domain for months. The monitoring data is more revealing than most internal audits.

Mailbox provider monitoring

Two providers expose direct sender feedback: Google and Microsoft. Both are free, both require setup, both should be checked daily for any sender above 50K/month.

Google Postmaster Tools (via web UI or Postmaster API):

• Domain reputation (Bad / Low / Medium / High)
• IP reputation (per IP if you have dedicated)
• Spam rate
• Authentication results
• Delivery errors
• Encryption (TLS)

Setup is covered in the Google Postmaster Tools guide. The API was finally released — automate the pull, don't rely on someone logging in weekly.

Microsoft SNDS (web UI scrape):

• IP-level data for Outlook.com/Hotmail
• Color code (green/yellow/red) summarizing health
• Spam-trap hits
• Complaint rate
• Filter result distribution

SNDS still has no official API, which is why most monitoring tools scrape it. The Microsoft SNDS guide walks through registration and interpretation.

Practitioner note: Microsoft SNDS spam-trap hits are the earliest warning signal you'll get for list quality decay. I've seen the spam-trap count tick up two weeks before Outlook reputation collapsed and we started seeing spam folder placement. If you treat that column as a leading indicator, you can intervene before the cascade.

Inbox placement monitoring

ESP-level "delivered" doesn't tell you whether the message went to inbox or spam. The receiving server returns 250 OK and then quietly routes to wherever filters decide. Seedlist testing is how you measure actual inbox placement.

Major seedlist providers:

Tool	Coverage	Notes
GlockApps	Gmail, Outlook, Yahoo, Apple, B2B	Strong free trial, broad provider coverage
Mail-Tester	One-off testing	Free, simple, less granular
Litmus Spam Testing	Major providers	Strong if you already use Litmus for rendering
Inbox Insights (Validity)	Enterprise panel data	Real user data, not just seeds

Run seedlist tests weekly on representative campaigns and per-domain (not per-account if you operate multiple sending domains). Alert on:

• Inbox placement below 90% at any major provider
• Spam folder placement above 5% at any provider
• "Missing" placement above 5% (often indicates filter blocking before placement)

Building the monitoring stack

For a sender doing 200K to 5M sends per month, I recommend:

ESP webhooks  →  Datadog / Grafana / custom dashboard
DMARC RUA     →  Mailhardener or Dmarcian
Postmaster    →  Postmaster API pull → same dashboard
SNDS          →  Mailhardener (scrapes) or manual weekly check
Seedlist      →  GlockApps weekly automated tests

For larger senders (10M+/month), Validity Everest or an enterprise DMARC stack becomes worthwhile. For smaller (under 100K/month), Mailhardener + free Postmaster + monthly GlockApps is sufficient.

The deliverability monitoring tools comparison covers vendor specifics. The multiple domain monitoring piece is required reading if you operate more than three sending domains.

Alert thresholds that actually fire

A monitoring system that doesn't alert is wallpaper. The thresholds I use:

Metric	Warning	Critical
Complaint rate (any provider)	0.10%	0.30%
Hard bounce rate	1.5%	3%
DMARC failure rate	1%	3%
Postmaster domain reputation	drop one tier	drop to Bad
SNDS color	yellow	red
Inbox placement	below 92%	below 80%

Route warnings to the deliverability lead and critical alerts to on-call. Don't dump everything into the same channel.

What email monitoring is not

Worth clarifying because the search results conflate three different things:

• Sender-side email monitoring (this guide) — observability for your outbound sending program
• Employee email monitoring — workplace surveillance / DLP tools (Teramind, etc.)
• Email server uptime monitoring — SMTP server availability checks (LogicMonitor, SolarWinds)

If you found this guide looking for employee monitoring or SMTP server uptime, those are different products entirely.

If you're operating at scale and need an outside set of eyes on your monitoring setup — or help building it from scratch — book a consultation. I configure monitoring stacks for SaaS, ecommerce, and agency clients and the setup pays for itself the first time it catches a problem early.

Sources

• Google Postmaster Tools
• Microsoft SNDS
• RFC 7489: DMARC
• RFC 6591: Authentication Failure Reporting
• M3AAWG — DMARC Training
• Yahoo Postmaster

---

v1.0 · May 2026