Email Delivery Reports: What to Track and What to Ignore

A useful email deliverability report answers one question: are my messages reaching the inbox, and if not, why. Most reports I see from clients answer neither. They lead with open rate (broken since Apple MPP), bury complaint rate (the metric that actually matters), and never reference Google Postmaster Tools or Microsoft SNDS at all.

This guide walks through the email delivery report I actually use during audits — which metrics belong, which are vanity, and how to wire them together so the report drives a decision instead of decorating a slide.

What an email deliverability report actually measures

Deliverability is the gap between what your ESP says happened and what mailbox providers say happened. Your ESP sees: sent, accepted, bounced, complained. It does not see: filtered to spam, promotions tab placement, image-blocking, or provider-side reputation scoring.

A real email delivery report pulls from four sources:

Source	What it tells you
ESP send logs	Volume, bounce categories, complaint webhooks
Mailbox provider tools	Google Postmaster, Microsoft SNDS, Yahoo CFL
DMARC aggregate reports	Cross-sender authentication and alignment
Seedlist tests	Inbox vs spam placement at major providers

If any of those four is missing, your report is incomplete. Most ESP-native dashboards only cover the first one.

Metrics that drive decisions

These are the numbers I check first on any new audit, in order:

1. Complaint rate per provider. Google enforces a hard 0.30% threshold under the Gmail bulk sender rules and starts filtering well before that. Microsoft acts on roughly the same band. Track this per provider, not in aggregate.
2. Authentication pass rate (SPF, DKIM, DMARC). From DMARC aggregate reports, broken down by source. Any third-party sender below 99% needs investigation.
3. Google Postmaster domain and IP reputation. Anything below "Medium" is a problem. "Bad" means active spam folder placement.
4. Microsoft SNDS color (red/yellow/green) and complaint rate. Color codes summarize spam-trap hits and complaint volume.
5. Bounce rate by category. A spike in 550 5.1.1 (user unknown) means your list hygiene slipped. A spike in 421 4.7.0 means rate limiting or temporary block.
6. Seedlist inbox placement. From GlockApps, Mailgenius, or Litmus seedlists — measured weekly, not after each send.

Practitioner note: I weight Microsoft SNDS heavier than most people do. It's the only direct signal Microsoft gives you, and the spam-trap hits column will flag list quality problems three or four weeks before Outlook starts spam-foldering. If you're not on SNDS yet, that's your first homework.

Metrics that mislead

• Open rate as an absolute number. Apple MPP pre-loads images, so any list with iOS share above 30% will show inflated, unreliable opens. Use it for relative campaign comparison only.
• "Delivered" without complaint context. A 99.5% delivered rate with a 0.5% complaint rate is a worse outcome than a 92% delivered rate with a 0.05% complaint rate. The first one is on track to get blocked.
• Spam score tools. Tools that rate your HTML "spam score" out of 10 do not reflect how Gmail or Outlook filters work. Ignore them.
• Sender Score (Validity). Useful as a directional signal, but it's IP-based and most modern infrastructure is reputation-by-domain.

How to wire the report together

I build deliverability reports as a single sheet with three tabs: provider view (Gmail, Microsoft, Yahoo, Apple, B2B), trend view (rolling 4-week complaint and authentication rates), and incident log (any reputation drops, blocklist hits, or threshold breaches).

For the data layer:

• ESP exports via API into a warehouse (BigQuery or Postgres works fine)
• Google Postmaster Tools pulled with the Postmaster API
• Microsoft SNDS scraped (no API, unfortunately) or via tools like Mailhardener
• DMARC aggregate reports parsed via Mailhardener, Dmarcian, or Postmark

The deliverability monitoring tools guide covers vendor selection in more depth. If you're managing more than one sending domain, you'll want a multi-domain monitoring layer that rolls up across all of them.

Practitioner note: The single biggest reporting upgrade most clients make is adding DMARC aggregate report parsing. You suddenly see every IP and source sending as your domain — including the ones you didn't authorize and the ESPs your marketing team signed up for without telling IT.

Reporting cadence and thresholds

Set thresholds, not just trend lines. Alert on:

• Complaint rate above 0.10% on any provider (well below Google's 0.30% enforcement)
• DMARC failure rate above 1% from any aligned source
• Google Postmaster reputation drop of one tier
• Microsoft SNDS color change to yellow or red
• Bounce rate above 2% on any campaign
• Inbox placement below 90% on any major provider in seedlist

For monthly executive reporting, lead with the inbox placement number and the complaint rate. Those two predict revenue impact. Everything else is supporting evidence.

Common reporting mistakes

• Reporting at the account level instead of per-sending-domain when you operate multiple brands or subdomains. Reputation lives at the domain, not the account.
• Omitting transactional and marketing in the same report. They should be separated — they have different baselines.
• Conflating "sent" with "attempted." If your ESP suppresses 8% of your list before send, the denominator matters.

If your team is debugging current placement issues, start with why emails go to spam and the Gmail complaint rate threshold deep-dive before redesigning the report.

If you need help building a deliverability reporting stack that actually drives decisions, book a consultation. I set up DMARC aggregate parsing, Postmaster Tools integration, and weekly inbox placement reporting for agencies and SaaS teams every month.

Sources

• Google Postmaster Tools — Sender Guidelines
• Microsoft SNDS Documentation
• M3AAWG Sender Best Common Practices
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• Apple — About Mail Privacy Protection
• Postmark — Email Deliverability Audit Guide

---

v1.0 · May 2026