Deliverability Metrics and Benchmarks

Mailbox providers infer whether email is wanted and expected from statistical signals (see Foundations of Email Deliverability). This article defines the metrics a sender must track and collects the numeric targets published by major ESP guides (AWS SES, Postmark, Twilio SendGrid, Klaviyo; open-rate bands from Braze and Bird). Where numbers differ between sources, all are given with attribution. The canonical threshold table below is the single reference other operations articles cite. For the dated, vendor-attributed industry survey figures these targets sit against — Validity seed-measured inbox/spam/missing rates by provider and industry, plus per-industry engagement benchmarks — see Deliverability Benchmarks.

Message lifecycle events

Twilio SendGrid enumerates nine primary events in a message's lifecycle. The names are vendor UI labels, but every sending infrastructure produces equivalent states:

Event	Definition
Processed	Message received by the sending system and queued for delivery
Dropped	Not sent at all (e.g., address on a suppression list, prior bounce, spam-flagged content)
Deferred	Receiving server temporarily refused; delivery is retried (SendGrid retries for up to 72 hours)
Bounce	Receiving server rejected the message; often indicates invalid or outdated addresses
Delivered	Accepted by the receiving server — note this does not mean Inbox; it may still land in Spam
Open	Recipient (or a proxy — see below) rendered the message
Click	Recipient clicked a tracked link
Spam report	Recipient marked the message as spam (a complaint)
Unsubscribe	Recipient clicked an unsubscribe link

Bounces

A bounce occurs when an email cannot be delivered to the intended recipient.

• Hard bounce — a permanent failure: the address or domain doesn't exist, authentication failures (SPF/DKIM/DMARC misalignment), severe reputation/blocklist issues. SMTP reply codes in the 5.X.X range (e.g., 550).
• Soft bounce — a temporary failure: mailbox full, receiving server overloaded or temporarily unavailable, temporary content/reputation blocks. SMTP reply codes in the 4.X.X range (e.g., 421, 451, 452). Sending systems typically retry soft bounces at intervals over several days before giving up.

(Code 250 = message accepted, delivery complete.)

High hard-bounce rates tell receivers you don't know your recipients — a strong negative reputation signal. Hard-bouncing addresses must be removed immediately and never re-sent to; see List Hygiene and Sunset Policies.

Bounce composition (transactional mail)

Postmark's transactional bounce data breaks down as: 80% hard bounces, 10% soft bounces, 3.5% spam complaints/ISP blocks, 2.5% delayed, 2.5% auto-responders, 1.5% other (DNS errors, DMARC rejections, challenge verification, unsubscribes). Automation effort should therefore focus on hard-bounce handling first.

Complaints

A complaint occurs when a recipient clicks "Mark as Spam" (or equivalent) in their mail client. Some — not all — mailbox providers report complaints back to senders via a feedback loop (see Sending Infrastructure Practices). Accumulated complaints tell the provider you are sending spam, directly harming deliverability and sender reputation.

Opens and clicks — measurement caveats

Open rates are inflated by Apple Mail Privacy Protection (MPP) and Gmail image prefetching, which fire the open pixel without a human reading the message. SendGrid's guidance: identify proxy opens (e.g., by prefetch user agents in event data) and prioritize click and conversion metrics over open rates when judging engagement.

Canonical threshold table

This is the KB's canonical cross-source threshold reference — other operations articles cite it rather than restating numbers. Where sources genuinely differ, the spread is given with attribution: a stricter vendor "house number" is labelled as such, not promoted to consensus.

Reading thresholds by scope (read this first)

The numbers below partly disagree because they are not the same measurement. A rate depends on three things, and two thresholds only compare if all three match:

• Who measures it — the mailbox provider (Gmail, Yahoo: what their users do) versus the sending side (your ESP/MTA: what your logs and feedback loops see). A provider only sees complaints its own users file; a sender only sees bounces and FBL returns.
• The reputation entity (network vs IP vs domain) — reputation is tracked at all three at once. Blocklists list IPs (Spamhaus SBL/CSS) and domains (DBL) separately; Gmail Postmaster Tools reports IP reputation and domain reputation on separate dashboards; AWS SES enforces at the account level to protect its shared-IP network.
• The denominator — complaints or bounces ÷ sent vs ÷ delivered vs ÷ inboxed. Gmail's spam rate is user-reports ÷ mail delivered to the inbox (and only DKIM-authenticated mail), so a low Gmail number can hide mail Gmail already routed to spam; SES and Klaviyo measure ÷ delivered. Same raw events, different percentage.

Scope	What it is	Who measures it	Example threshold
Network / shared pool	aggregate reputation of an ESP's shared IP space	sending infrastructure (AWS SES, per account)	SES pause at 0.5% complaint / 10% bounce
IP	reputation of a single sending IP	blocklists; provider IP-reputation dashboards	Spamhaus listing; Gmail IP Reputation dashboard
Sender domain	reputation of the From / DKIM domain the recipient sees	mailbox provider (Gmail/Yahoo, per domain)	Gmail 0.1% target / 0.3% ceiling (÷ inboxed)

Which line you act on depends on your role:

• Sender (you own the domain): the per-domain mailbox-provider ceiling sets your inbox placement — keep the Gmail/Yahoo complaint rate under 0.1% and never near 0.3%. Your ESP dashboard's numbers are an early warning, not the target.
• ESP operator (shared platform): one number cannot protect every scope — you need three guards: (1) a network/pool guard protecting shared-IP reputation (the SES-style per-account line), (2) a per-domain guard so each customer stays under the Gmail/Yahoo ceiling, and (3) a tighter per-tenant/IP guard to catch a bad sender before either of the others trips (well below 0.3%, near 0.1% or your own house line). See Account Enforcement, Outbound Monitoring, and Multi-Tenant Architecture.
• Compliance: a rising complaint rate is a consent-quality signal before it is a deliverability one — sustained complaints above ~0.1% point to a permission or expectation problem, not a technical one (see Consent Methods).

Complaint (spam) rate

Line	Value	Scope — measured by	Denominator
Consensus healthy target	< 0.1% (≤ 1 per 1,000)	sender-side account/list — AWS SES, Postmark, SendGrid	÷ delivered
Klaviyo house number (stricter)	< 0.01% (≤ 1 per 10,000)	sender-side account/list — Klaviyo (deliberately conservative, not consensus)	÷ delivered
"High" in practice	even 0.08% can be high	sender-side — SendGrid	÷ delivered
Gmail/Yahoo violation ceiling	0.3% — must never be reached	mailbox provider, per sender domain — Google/Yahoo Feb 2024 bulk-sender rules	÷ inboxed (Gmail: DKIM-authed mail delivered to inbox)
SES enforcement (network/pool)	review at 0.1%, pause at 0.5%	infrastructure, per AWS account — protects the shared-IP network, not a deliverability-safe target; see Account Enforcement	÷ delivered

These lines are not directly comparable — the Gmail/Yahoo 0.3% ceiling is measured by the provider ÷ inboxed mail per domain, while the sender-side and SES numbers are ÷ delivered at account/pool scope. Because Gmail's denominator excludes mail already sent to spam, your ESP dashboard reading 0.1% ÷ delivered can coexist with a Gmail spam rate already near the 0.3% wall. Practical takeaway: senders anchor on the per-domain < 0.1% provider target; ESP operators set their own pool and per-tenant auto-pause lines below the 0.3% ceiling (near 0.1%), never at SES's looser 0.5% network line.

Bounce rate

Line	Value	Source / meaning
Klaviyo house number (aspirational)	total bounce < 1.0%	Klaviyo — stricter than consensus
Healthy during warm-up	< 2%	Postmark (domain warm-up guide)
Operating ceiling	keep under 5% hard-bounce	AWS SES ("reasonable and attainable goal, but isn't a universal rule across all ISPs"); Postmark (domain-wide)
Absolute ceiling	never exceed 10%	Postmark — investigate immediately at/above this
SES enforcement	hard-bounce under review at 5%, may be paused at 10%	AWS SES (per account, network/pool scope); see Account Enforcement

Scope note: bounce rate is inherently a sender-side metric — no mailbox provider publishes a bounce ceiling, because bounces are what your MTA observes, not what recipients do. So all lines above are sender-measured; they differ by entity scope (Klaviyo/Postmark quote per-list/per-domain quality lines; SES enforces per-account to protect its shared-IP network) and by denominator (hard-bounce ÷ sent vs total-bounce ÷ delivered). Contrast complaint rate above, where the binding ceiling is set by the mailbox provider per domain.

Open rate (MPP-era)

Post–Apple Mail Privacy Protection, a raw open rate is a pixel-load rate inflated by machine opens (see Open and Click Tracking Mechanics and Tracking and Measurement Distortion). Read every open benchmark against whether it is machine-included (raw pixel loads, MPP-inflated) or machine-excluded (prefetch/bot-filtered "human" opens):

Basis	Healthy	Spam-folder warning	Source
Machine-included (raw)	≥ 33%	—	Klaviyo
Machine-excluded (human / non-prefetch)	> 25% (Braze) · > 35% (Bird) = widespread inbox placement	< 20% suggests spam-folder placement	Braze, Bird — see Open and Click Tracking Mechanics

The older GreenArrow "5%–20%+ for good senders" band predates MPP and is directionally stale as a raw-open benchmark (see Two Worlds); do not use it to judge a modern Apple-heavy list. Regardless of the number, judge audience engagement on clicks/conversions, not opens; use the open-rate trend only as a coarse placement signal.

Corrective-action triggers

Postmark's domain warm-up guide pairs metric breaches with concrete volume responses (useful during any ramp-up — see also IP Warm-Up):

Trigger	Action
Bounce rate exceeds 3%	Reduce volume 40–50%
Open rate falls below 10%	Reduce volume 25–30% and refocus on engaged subscribers
Spam complaints exceed 0.1%	Immediately identify and pause the affected segments
Throttling / deferrals from a provider	Reduce daily volume 20–30% or spread sends across more hours
Listed on a major blocklist	Stop sending immediately; delist; restart at significantly reduced volume

General rule from the same guide: never increase volume until you've reviewed performance per receiving provider; if engagement and bounce rates look normal, the next day's increase is likely safe.

Content quality as a metric input

Beyond behavioral rates, receivers run content filters over every message. AWS SES's guidance for staying on the right side of them:

• Modern content filters adapt continuously; they don't use a fixed rule set. Third-party seed/content testing services can identify triggering content before a send.
• Check every URL in the message against DNS-based blocklists (DNSBLs) such as URIBL.com and SURBL.org.
• Avoid link shorteners — when a shortening service is abused by spammers and denylisted, every message linking through it is filtered.
• Test that every link points where intended.
• Link to up-to-date Privacy Policy and Terms of Use pages from each email.
• For high-frequency content (e.g., daily deals), vary the content of each deployment — repetitive identical content reads as spam.

Postmark adds: avoid shortened URLs (especially bit.ly), limit image-heavy layouts, and always include a plain-text alternative to the HTML part. Content filtering can be triggered by tiny changes — in one Postmark case, adding a phone number to a template triggered Gmail spam filtering — so when placement drops after a template change, revert changes incrementally to isolate the cause.

Related

• List Hygiene and Sunset Policies — what to do with the addresses behind bad metrics
• Sending Infrastructure Practices — feedback-loop wiring and reputation monitoring tools
• Foundations of Email Deliverability — why these signals exist