---
title: "Email Deliverability Monitoring: 7 Signals to Track"
description: "Email deliverability monitoring: the protocol signals that predict spam-folder placement, the metrics to track, and the tools that surface each one."
publishedAt: 2026-06-22
tags: ["deliverability", "monitoring", "email-authentication", "dmarc", "sender-reputation"]
faq:
- question: "How do you monitor email deliverability?"
answer: "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."
- question: "What is the best tool to check email deliverability?"
answer: "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."
- question: "What email deliverability metrics should I track?"
answer: "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."
- question: "Where did Google's domain reputation dashboard go?"
answer: "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."
- question: "Does DMARC affect email deliverability?"
answer: "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."
---
# 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.
That 40.8%-have-no-authentication figure comes from our
[email authentication research](/research/email-authentication/), and the same
dataset drives our deep dive on the
[DMARC enforcement gap](/blog/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](/blog/emails-going-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.
- **February 2024** — Gmail and Yahoo begin rejecting non-compliant bulk mail.
- **May 5, 2025** — Microsoft follows for senders above 5,000 messages a day,
returning `550; 5.7.515 Access denied, sending domain does not meet the
required authentication level`.
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.
"You don't know if you don't monitor… identifying falling signals is your best
way to identify if and when you have a deliverability issue." — Al Iverson,
Industry Research and Community Engagement Lead at Valimail (author of Spam
Resource), in [Email Love, 2025](https://emaillove.com/email-peeps-59-al-iverson).
## How do you monitor email deliverability?
You monitor email deliverability by instrumenting four feeds and watching them on
a cadence:
1. Route DMARC aggregate (RUA) reports to a parser and watch the pass-rate trend
plus any new unknown sources.
2. Stand up Google Postmaster Tools (Spam Rate, Compliance Status, and
Authentication).
3. Register sending IPs in Microsoft SNDS and wire JMRP complaints to
suppression.
4. 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](/tools/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](/learn/dmarc/). To turn raw RUA
XML into a readable trend without building a parser, our
[free DMARC report analyzer](/tools/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](https://support.google.com/a/answer/14668346) 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](/tools/blacklist-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](/learn/mta-sts/) and
[TLS-RPT overview](/learn/tls-rpt/) for setup.
- **[ARC (RFC 8617)](/learn/arc/)** 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](/learn/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)](/learn/dane/)** 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](https://www.m3aawg.org/);
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.
DMARCguard is our product. The competitor data below was verified on
**2026-05-31** from each vendor's own pricing and documentation. We frame this as
"which tool surfaces which signal," not "best tool" — there is no single winner.
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](/blog/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](/tools/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](/blog/emails-going-to-spam/) for the remediation half
of this pair.