Monitoring Deliverability: The Signals That Matter

Deliverability monitoring means watching a small set of signals that predict whether mailbox providers will keep accepting your mail, and catching a problem while it is still a trend rather than a cliff. The signals split into two kinds: leading indicators that move before delivery suffers, and lagging indicators that confirm damage after it has happened. The discipline is to act on the leading ones. The core data sources are Google Postmaster Tools, your DMARC aggregate reports, and your own MTA logs, and the metrics that matter most are spam complaint rate, authentication pass rates, bounce rate, and reputation as the provider reports it.

The reason the split matters is timing. By the time your bounce rate spikes or mail starts landing in spam folders, the reputation decision has already been made. Leading indicators, complaint rate creeping up, authentication starting to fail on a slice of traffic, a new IP warming poorly, give you the window to fix the cause before the provider acts on it.

Leading versus lagging indicators

Leading indicators move first and let you intervene:

• Spam complaint rate, the share of delivered mail that recipients mark as spam. This is the single most predictive number, because providers weight it heavily and it rises before reputation collapses.
• Authentication pass rates for SPF, DKIM, and DMARC. A drop here, say a new sending source that is not DKIM-signed, precedes deliverability loss.
• Sending reputation as the provider scores it, which trends down ahead of visible failures.

Lagging indicators confirm what already happened:

• Bounce rate, especially hard bounces to invalid addresses, which signals list-hygiene problems after they have started costing you.
• Inbox versus spam placement, which you only observe after the provider has filed the mail.
• Blocklist appearances, which show up after the behavior that triggered them.

You monitor both, but you steer on the leading set.

Google Postmaster Tools, post-v2

Google Postmaster Tools is the authoritative window into how Gmail sees your mail, and it changed significantly in the move to v2. The standalone Domain Reputation and IP Reputation dashboards that older guides describe are gone. They were replaced by a Compliance Status dashboard tied to Gmail's bulk-sender requirements, and a Deliverability analysis section that Google added in mid-2026. The data in the deliverability view is shown for mail authenticated with DKIM, which is one more reason DKIM alignment is non-negotiable.

The metric to watch above all is the user-reported spam rate. Google's guidance is explicit:

• Keep it below 0.10%. This is the target.
• 0.30% is the red line. At or above it, Gmail's delivery-mitigation protections for your domain are switched off, and your mail is exposed to full filtering.

The rate is computed only over mail that reached the inbox, so a number near zero combined with poor placement can mask a problem, which is why you read it alongside the compliance and authentication status rather than in isolation.

To get any of this you must verify the sending domain by publishing a TXT record Google gives you:

; Postmaster Tools domain verification
example.com.   IN   TXT   "google-site-verification=<token-from-postmaster-tools>"

The Compliance Status view then reports whether you meet the bulk-sender rules: SPF and DKIM present and aligned, a DMARC policy published, TLS used in transit, and one-click unsubscribe (RFC 8058) on marketing mail. Treat anything short of full compliance as a deliverability incident in progress.

Authentication pass rates

SPF, DKIM, and DMARC are not set-and-forget. New sending services, a forwarded campaign, a changed envelope-from, any of these can quietly start failing alignment for a slice of your traffic. The number to track is the percentage of your mail that passes DMARC through DKIM alignment, because DKIM survives forwarding where SPF often does not. A pass rate that drifts from 100% toward 95% is a leading indicator that a sending source has fallen out of alignment, and it will reach Gmail's filters before it reaches your bounce report.

DMARC aggregate reports

DMARC aggregate (RUA) reports are the cross-provider view that Postmaster Tools cannot give you, because every reporting receiver sends them, not just Gmail. You request them with a single record:

; request daily DMARC aggregate reports
_dmarc.example.com.   IN   TXT   "v=DMARC1; p=quarantine; rua=mailto:[email protected]; ri=86400;"

Each report is an XML summary, per source IP, of how much mail claimed to be from your domain, whether SPF and DKIM passed, and whether each result aligned with the From domain. Parsing these (through your own tooling or a DMARC platform) surfaces three things you cannot see anywhere else: a forgotten or unauthorized sending source, a third party sending on your behalf without alignment, and outright spoofing of your domain. Reviewing aggregate reports is how you move a policy from p=none to p=quarantine to p=reject with confidence that you are not about to block your own legitimate mail.

Complaint and bounce rate from your own logs

Your MTA and ESP feedback loops give you the rest. Complaint rate from provider feedback loops (FBLs) should sit well under 0.1%. Bounce rate, broken into hard bounces (invalid recipient, fix list hygiene) and soft bounces (temporary, monitor for patterns), tells you whether your list is decaying or a destination is deferring you. A sudden block of 4xx deferrals from one provider, read straight from the logs, is often the earliest sign of a reputation hit, earlier than the dashboards update.

A working monitoring posture pulls these together: Postmaster Tools for Gmail's spam rate and compliance status, DMARC aggregate reports for cross-provider authentication and spoofing, and your own logs and FBLs for complaints and bounces, reviewed on a cadence rather than after an incident.

In a deliverability interview, the answer that demonstrates real operating experience is: watch leading indicators (complaint rate, authentication pass rate, reputation) so you act before delivery drops, keep the Gmail spam rate under 0.10% and never let it touch the 0.30% line where mitigation turns off, know that Postmaster Tools v2 replaced the reputation dashboards with a compliance and deliverability view, and use DMARC aggregate reports as the only cross-provider lens on authentication and spoofing. Saying that, and naming the exact thresholds, is what shows you have actually held a sender's reputation steady, not just read the docs.