Email Deliverability Monitoring: What to Track and the Signals That Predict Spam
Email deliverability monitoring is the ongoing practice of tracking the signals — authentication pass rates, sender reputation, spam-complaint rate, blocklist status, and protocol health — that predict whether your mail lands in the inbox or the spam folder, so you can act before placement drops. It is not a one-time setup check. The major providers now track your rolling state and reject — not just filter — non-compliant bulk mail.
40.8% of the internet's top 5.5M domains have no email authentication at all — and only 12.8% enforce DMARC (p=quarantine or p=reject).
That 40.8%-have-no-authentication figure comes from our email authentication research, and the same dataset drives our deep dive on the DMARC enforcement gap — why so few domains move past p=none.
This guide is for the people who own that gap: IT admins keeping mail flowing for an SMB, founder-operators running their own sending, and DevOps/SRE teams that inherited deliverability as part of the infrastructure. You will get a signal map (what to watch, where it lives, and what a bad reading predicts), the metrics with real thresholds traced to primary provider docs, and a neutral five-tool comparison.
If your mail is already landing in spam, start with why your emails go to spam; this post is the ongoing-monitoring half of that pair.
What is email deliverability monitoring?
Email deliverability monitoring is the continuous tracking of the signals that determine inbox placement — distinct from a one-time deliverability test (a seed-list snapshot) and from authentication setup (a one-time DNS change). Monitoring is the rolling-state view; testing is a single frame; setup is the foundation you build once.
That distinction matters more in 2026 than it did two years ago. Gmail and Yahoo began rejecting non-compliant bulk mail in February 2024, and Microsoft followed on May 5, 2025. Domains sending more than 5,000 messages a day to Outlook.com, Hotmail.com, or Live.com now have non-compliant mail rejected outright.
The providers track the rolling state: Google restores mitigation eligibility only after a sender’s spam rate stays below 0.3% for seven consecutive days. Authentication is no longer a project you finish — it is a service you watch.
The providers also expose that live state back to you. Google Postmaster Tools surfaces your compliance status and spam rate; Microsoft SNDS shows per-IP color; DMARC aggregate reports show your alignment trend. Monitoring is the discipline of reading those feeds before placement drops.
How do you monitor email deliverability?
You monitor email deliverability by instrumenting four feeds and watching them on a cadence:
- Route DMARC aggregate (RUA) reports to a parser and watch the pass-rate trend plus any new unknown sources.
- Stand up Google Postmaster Tools (Spam Rate, Compliance Status, and Authentication).
- Register sending IPs in Microsoft SNDS and wire JMRP complaints to suppression.
- Run periodic blocklist and sender-reputation checks (Spamhaus ZEN/DBL, Validity Sender Score).
The staging that works is: instrument the live signals first, add the trend feeds second, then layer on hygiene. In week one, stand up Postmaster Tools and SNDS and read the Spam Rate and Compliance Status dashboards during active campaigns. In weeks two through four, route RUA to a parser and watch three things — aligned-pass percentage, any new high-volume unknown source, and alignment-failure spikes from known vendors. Ongoing, verify lists before each send to hold bounce rates down, because list quality is the upstream input that drives everything downstream.
Before you instrument anything, get a baseline. A free domain health check reads your DMARC, SPF, DKIM, MTA-STS, and BIMI records in one pass — no signup required — so you know which protocols are even reporting before you start watching the trend.
The deliverability signals that predict spam-folder placement
The signals that move first are authentication trends — DMARC RUA pass rate and new unknown senders — and seed-list slippage; user-reported spam rate and blocklist hits move later. Monitoring the leading signals buys you time to act before inbox placement drops. The ordering is well-documented; the timing in days is not, so we describe signals as leading or lagging, never “N days earlier.”
This is the part no top-ranking competitor publishes: a map of each signal, where to read it, the healthy threshold, and what a bad reading predicts.
| Signal | Where to read it | Healthy reading | What a bad reading predicts |
|---|---|---|---|
| User-reported spam rate | Google Postmaster Tools (Spam Rate) | Below 0.10%; never reach 0.30% | Graduated suppression; at 0.30%+ ineligible for Gmail mitigation |
| Authentication pass rate (SPF/DKIM/DMARC) | Google Postmaster (Authentication); DMARC RUA | Near 100% | Auth-driven filtering or rejection; 550 5.7.515 at Microsoft |
| DMARC aligned-pass % trend | DMARC RUA aggregate reports | Steady or rising | A sudden drop signals a key rollover, DNS error, vendor change, or spoofing |
| New / unknown sending source | DMARC RUA | None unexplained | Spoofing or shadow IT (a leading signal) |
| Per-IP reputation color | Microsoft SNDS | Green | Yellow = throttling; Red = blocking/severe filtering (consumer domains only) |
| Sender Score | Validity Sender Score | 80+ good; below 70 serious | Below 70 = serious inbox-placement problems (a lagging 30-day average) |
| Blocklist presence | Spamhaus ZEN / DBL | Not listed | A ZEN listing rejects roughly 85% of a relay’s traffic (Validity) |
| Bounce rate (hard / total) | ESP dashboard | Total below 2%; hard below 0.5% | List-quality damage; ESP account review (AWS SES: 5% = review, 10% = pause) |
| TLS / encryption % | Google Postmaster (Encryption); TLS-RPT | Near 100% | Compliance failure against sender guidelines; downgrade or STARTTLS-stripping |
Authentication pass rate and DMARC trends (the leading signal)
Authentication is the earliest signal because it breaks before reputation visibly drops. Treat DMARC (RFC 7489) aggregate (RUA) reports as an ongoing feed, not a setup check: watch the aligned-pass percentage trend, watch for new unknown sources, and watch for alignment-failure spikes. A steady upward trend means you are ready to tighten policy; a sudden drop predicts a misconfiguration, a SPF (RFC 7208) or DKIM (RFC 6376) key-rollover error, a DNS outage, or a vendor change — often before any reputation dashboard moves. Microsoft’s own guidance is explicit: “regularly review the DMARC Aggregate reports to monitor where email from your domains is coming from.”
For the full mechanics, see our DMARC overview. To turn raw RUA XML into a readable trend without building a parser, our free DMARC report analyzer does it in the browser.
One vendor study is worth flagging as directional: InboxEagle’s analysis of 2,229,783 emails found DMARC-failing mail landed in spam 30.75% of the time versus 16.7% for DMARC-passing mail. [Seed-test data, directional — not provider telemetry.]
Sender reputation and inbox placement
Sender reputation is a lagging signal — by the time it moves, the leading signals have usually already warned you — and in late 2025 it also got harder to read. When Postmaster Tools v1 shut down on September 30, 2025, Google retired the Domain Reputation and IP Reputation dashboards and replaced them with a binary Compliance Status (Pass or Needs Work). There is no longer a four-tier reputation thermometer to alert on. You triangulate instead: Spam Rate plus Microsoft SNDS plus Validity Sender Score plus DMARC RUA trends.
Sender Score is a 0–100, IP-based, rolling 30-day percentile. Validity’s own stated line is that a score below 70 “indicates that one or more of the key metrics… exceeds the acceptable thresholds… your email program needs improvement.” Treat it as an early warning, not a real-time gauge — it is a lagging average, and mailbox providers do not consume it directly. Start with the Google Postmaster Tools docs to wire up the free first-party feed.
Blocklist signals
A blocklist hit is a late-stage, high-severity signal: by the time you are listed, filtering is already happening. Spamhaus ZEN combines four IP blocklists (SBL, CSS, XBL, PBL); per Validity, a ZEN listing “will identify and reject roughly 85 percent of a typical mail relay’s incoming mail traffic” because most mailbox providers query it. A PBL listing alone “won’t immediately affect your deliverability.” The Spamhaus DBL lists domain names — and a listed domain anywhere in your mail can block the message. Delisting, once you have fixed the cause, takes a few minutes up to 24 hours.
Run an on-demand blocklist check the moment a placement drop appears unexplained — it is the fastest way to rule a listing in or out.
Named senders, not IP addresses
The real-world monitoring question is not “is an IP failing?” but “which of my senders is hurting me?” — and that is exactly where most tooling stops. DMARC RUA reports give you raw source IPs; mapping each IP back to the actual ESP is manual and, as EasyDMARC puts it, “cumbersome and requires manual checks.” DMARCguard’s sender identification names the service behind each IP — Mailchimp, SendGrid, Microsoft 365 — so a failing source is a name you recognize, not a number you have to look up.
This matters on shared IP pools, where a “noisy neighbor” can drag down everyone on the IP. SendGrid concedes “the lack of control over IP reputation” is “the major drawback to shared pools,” and Microsoft’s 451 4.7.x rate-limiting deferrals are triggered partly by “risky shared IP neighbors.” When the report says a shared-pool IP is throttled, naming the sender is the difference between knowing what failed and knowing who to call.
Encryption-in-transit signals: MTA-STS, TLS-RPT, ARC, BIMI, DANE
Encryption-in-transit and trust protocols — MTA-STS, TLS-RPT, ARC, BIMI, DANE — are real but secondary deliverability signals. Gmail surfaces a TLS percentage and treats TLS as a delivery requirement, but MTA-STS and DANE function mainly as security and regulatory (NIS2/DORA) controls, not documented inbox-placement levers. They belong in your monitoring, but with honest expectations about what each one does — and does not — do.
- MTA-STS (RFC 8461) and TLS-RPT (RFC 8460) govern encrypted transport. Our February 2026 scan found MTA-STS at just 0.3% of 5.5M domains. TLS-RPT works like DMARC reporting: receivers send JSON aggregate reports detailing which servers failed TLS and why, which is how you detect downgrade or STARTTLS-stripping attacks as an ongoing feed. See the MTA-STS overview and TLS-RPT overview for setup.
- ARC (RFC 8617) preserves the original SPF/DKIM/DMARC results across forwarders so legitimate forwarded and mailing-list mail can survive DMARC. Gmail and Microsoft honor it (Microsoft via configurable Trusted ARC Sealers), but Google is explicit that ARC does not auto-authenticate — receivers still run their own checks and decide whether to trust the chain.
- BIMI rewards sustained DMARC enforcement (p=quarantine or p=reject) with logo display. The widely-cited engagement-lift figures come from vendor surveys using mock emails, not live-inbox A/B data — even working-group member Valimail concedes the evidence is “primarily anecdotal.” Treat BIMI as a brand-trust play, not a guaranteed deliverability lift.
- DANE (RFC 6698 / 7672) is a security and reliability signal — DNSSEC-signed TLSA records that prevent STARTTLS downgrade and MITM — not an inbox-placement signal. Adoption is gated by DNSSEC complexity, which is why our scan found only 30 domains deploying DANE across 5.5 million.
| Protocol | RFC | Monitoring signal | Affects inbox placement? |
|---|---|---|---|
| MTA-STS | 8461 | Policy-enforcement state; downgrade attempts | No (security/compliance) |
| TLS-RPT | 8460 | TLS failure reports; STARTTLS-stripping | Indirect (TLS is a delivery requirement) |
| ARC | 8617 | Chain validation across forwarders | Indirect (helps forwarded mail survive DMARC) |
| BIMI | — | Logo display contingent on DMARC enforcement | No (brand trust; lift unproven) |
| DANE | 6698 / 7672 | TLSA validity; secure-transport state | No (security/reliability) |
The deliverability metrics to track (and their thresholds)
Four deliverability metrics have published numeric thresholds you can build alerts around: spam-complaint rate, bounce rate, authentication pass rate, and blocklist status. Everything else is interpretation; these are the lines with sources behind them.
| Metric | Threshold | Primary source |
|---|---|---|
| User-reported spam rate | Below 0.10%; never reach 0.30% | Google Email sender guidelines (2024) |
| Spam complaint rate (Yahoo) | Below 0.30% (vs inbox-delivered mail) | Yahoo Sender Best Practices (2024) |
| FBL complaint reports | Should not exceed 0.10% (1 per 1,000) | M3AAWG (2017) [older data] |
| Total bounce rate | Below 2% (review at 5%, pause at 10%) | AWS SES Reputation metrics |
| Hard bounce | Below 0.5% | AWS SES / cross-industry |
| Sender Score | 80+ good; below 70 = needs improvement | Validity |
Read the 0.3% spam rate as a ceiling, not a target. Yahoo’s Marcel Becker, who set it, was blunt about why: “We chose 0.3% because… 0.3% or below is the requirement for them already. If your traffic sustains a spam rate above 0.3%, you’re probably already in a world of hurt.” Good senders run well below it.
Bounce rate is the metric you control upstream, through list hygiene. ZeroBounce’s 2026 List Decay Report, analyzing more than 11 billion addresses verified during 2025, found “at least 23% of email lists degrade annually.” That is why verification belongs before each send, not after the bounces arrive. The foundational complaint norm — that feedback-loop reports “should certainly not exceed 0.1% (1 email for every 1,000 emails sent)” — comes from M3AAWG’s sender complaint-handling recommendations; note that document predates the 2024 bulk-sender regime.
Tools that surface each signal
No single tool monitors every signal. Google Postmaster Tools is free and Gmail-only; seed-list testers (GlockApps, MailReach) sample inbox placement; ESPs (Postmark) bundle monitoring with sending; Litmus/Everest is the enterprise platform; and DMARCguard monitors the protocol layer — DMARC, SPF, DKIM, MTA-STS, TLS-RPT, ARC, BIMI, DANE — and names the senders behind each IP. The right setup pairs tools by job.
| Tool | Free tier | Inbox placement | Blocklist | DMARC/SPF/DKIM | Advanced protocols | Named-sender ID | Lowest paid | Best for |
|---|---|---|---|---|---|---|---|---|
| Google Postmaster Tools | Yes (fully free) | No | No | Yes (Gmail only) | No (TLS % only) | No | Free | Gmail spam-rate + compliance |
| GlockApps | Yes | Yes (115 seeds) | Yes (50+) | Yes | Partial (BIMI checker) | Yes | $59/mo | Seed-list inbox testing |
| Postmark (DMARC Digests) | Yes (100 emails/mo) | No (removed) | Managed | Yes | Partial (BIMI/ARC) | Yes | $14/mo/domain | ESP-bundled DMARC monitoring |
| MailReach | No (warmup) | Yes (30+ inboxes) | Yes | Yes | No | No | $25/mo/mailbox | Cold-email warmup + spam tests |
| Litmus (from Validity) | No | Yes (Everest) | Yes | Yes | Partial (BIMI) | Partial | $500/mo | Enterprise testing + deliverability |
| DMARCguard | Yes (7 protocols free) | No (protocol-layer) | Yes | Yes | Yes (all 5) | Yes (named ESPs) | See pricing | 9-protocol monitoring + named senders |
The practical verdict: use Postmaster Tools for Gmail spam rate and compliance, a seed tester for periodic placement snapshots, and DMARCguard for the protocol and named-sender layer. One caution from the community — the r/Emailmarketing answer still recommending “SendGrid, Return Path, and 250ok” is a reminder that tool advice ages badly: Return Path and 250ok were both folded into Validity years ago. Date your sources. For a fuller head-to-head, see our roundup of the best DMARC monitoring tools.
Frequently asked questions
How do you monitor email deliverability?
Route DMARC aggregate (RUA) reports to a parser to watch pass-rate trends and unknown senders, stand up Google Postmaster Tools for spam rate and compliance, register sending IPs in Microsoft SNDS, and run periodic blocklist and Sender Score checks. Monitor leading signals — authentication trends and seed-list slippage — before lagging ones like spam rate and blocklists.
What is the best tool to check email deliverability?
No single tool covers everything. Google Postmaster Tools is free for Gmail; GlockApps and MailReach run seed-list placement tests; DMARCguard’s domain health check inspects DMARC, SPF, DKIM, MTA-STS, and BIMI in one pass — protocol-level signals that correlate with inbox placement. Pair tools by job rather than expecting one to do all of them.
What email deliverability metrics should I track?
Track user-reported spam rate (target below 0.1%, never reach 0.3%), authentication pass rate (near 100%), total bounce rate (below 2%), blocklist status, and Sender Score (80+ healthy). Spam rate carries Google’s only hard published ceiling; the rest are practitioner thresholds traced to AWS SES, Validity, and M3AAWG.
Where did Google’s domain reputation dashboard go?
Google retired the Domain Reputation and IP Reputation dashboards when Postmaster Tools v1 shut down on September 30, 2025, replacing them with a binary Compliance Status (Pass or Needs Work). Senders now triangulate using Spam Rate, Authentication, Microsoft SNDS, Sender Score, and DMARC RUA trends.
Does DMARC affect email deliverability?
DMARC affects deliverability indirectly: Gmail, Yahoo, and Microsoft now reject bulk mail (over 5,000 messages a day) that fails SPF, DKIM, or DMARC alignment — Microsoft returns 550 5.7.515. Authentication does not guarantee the inbox, but failing it guarantees filtering or rejection at the major providers.
Monitor the leading signals, not just the dashboards
Email deliverability monitoring is continuous, not a setup step. The leading signals — DMARC RUA trends, authentication pass rate, and seed-list slippage — move before the lagging ones (spam rate and blocklists), which is what gives you time to act. The thresholds that matter come from primary provider docs, not vendor blogs repeating each other. And the under-watched layer is protocol health: MTA-STS, TLS-RPT, ARC, and DANE are real monitoring inputs that no deliverability software or email deliverability platform on the typical tools list even surfaces.
DMARCguard monitors all 9 authentication protocols and names the senders behind every IP. If your mail is already getting filtered, circle back to why your emails go to spam for the remediation half of this pair.