What is email deliverability? The practical difference from Email client compatibility

What is email deliverability? Delivery is not inbox placement

It is broader than delivery. In provider event data, a message can be recorded as delivered when the recipient's mail server accepted it. Amazon SES, for example, defines a Delivery event as successful delivery to the recipient's mail server. That event does not tell you whether the receiving system later placed the message in the inbox, spam folder, or another category. So the useful mental model is not "sent versus delivered." It is a chain of separate gates.

The 4 gates between send and inbox

Gate 1: your sending system accepts the message

Your application or ESP accepts the send request. A successful API call proves only that the sending system accepted work. It does not prove that the destination server accepted the message.

Gate 2: the receiving server accepts or rejects it

During SMTP delivery, the destination can accept the message, temporarily defer it, or permanently reject it. A temporary failure may be retried. A permanent failure ends that delivery attempt unless something changes.

Gate 3: the mailbox provider filters the accepted message

After acceptance, a provider can place a message in the inbox, spam, another tab or folder, or apply other internal filtering. The sender usually cannot observe this decision perfectly for each message.

Gate 4: the recipient actually sees and values it

Inbox placement still does not guarantee attention. A recipient may ignore, delete, unsubscribe, or mark the message as spam. Those actions can affect future filtering and reputation.

A healthy program therefore needs to distinguish send acceptance, SMTP delivery, inbox placement, and recipient response instead of collapsing all 4 into one "delivery rate."

Why deliverability is a system, not one score

There is no universal deliverability score shared by Gmail, Yahoo, Outlook, and every other mailbox provider. Each receiver observes its own traffic and applies its own policies, models, reputation signals, and user behavior. A useful diagnostic frame is: provider × identifier × stream × time

• Provider: Gmail can behave differently from Yahoo or Outlook for the same campaign
• Identifier: a problem may attach more strongly to a domain, DKIM identity, return-path domain, IP, URL, or some combination
• Stream: promotional newsletters, password resets, receipts, and support mail can have different audiences and behavior
• Time: reputation and filtering are dynamic. A sudden volume spike or complaint burst can create a short-term problem that looks different from a long-running structural issue

This is why "our deliverability is 98%" is often an incomplete diagnosis. A high server-acceptance rate can coexist with poor Gmail inbox placement, while a small group of invalid addresses can produce a visible bounce-rate problem without affecting all providers equally.

Deliverability changes can be local even when the campaign was global

Suppose the same campaign goes to Gmail, Yahoo, and Outlook recipients. Gmail performance falls sharply while Yahoo and Outlook remain stable.

That pattern should change your first hypothesis. A global template bug or broken sending domain is still possible, but a provider-local signal such as Gmail-specific reputation, recipient behavior, or filtering is now more plausible than a universal failure. The diagnostic unit should therefore include at least:

provider × sender domain × sending IP/pool × stream × time window

Then compare a control cohort that did not degrade. The contrast often teaches more than the absolute metric. If one provider, one IP pool, or one stream diverged while the others stayed healthy, investigate what is unique to that slice before changing the entire program.

This is the same reason “our overall bounce rate is fine” can hide a serious incident. Aggregate metrics can average a damaged cohort together with a much larger healthy one.

Common failure patterns

What to monitor continuously

A useful operational dashboard should separate at least:

• send attempts
• receiver acceptance / delivery events
• temporary failures
• permanent failures
• complaint events
• unsubscribe events
• authentication pass and alignment health
• provider-specific compliance signals
• domain and IP changes
• volume by provider and stream
• clicks, conversions, and revenue where relevant

Open rate can remain a directional engagement signal, but it should not be the only engagement input because privacy and automated fetching can distort it.

The most important habit is segmentation. A single blended number across every provider, domain, IP, stream, and day is useful for a board slide and weak for diagnosis.

Worked example

Imagine an ESP reports:

• 100,000 messages submitted
• 99,000 Delivery events
• 500 hard bounces
• 500 still pending or otherwise failed

• A team might conclude that deliverability is 99%

Now suppose Gmail recipients say the newsletter is consistently in spam and Gmail's own diagnostics show poor compliance or complaint signals. There is no contradiction. The ESP's Delivery event means the recipient mail server accepted the message. The provider's filtering decision occurs after or around that acceptance path and is not represented by the same metric.

The right response is to segment the evidence by provider and investigate Gmail-specific authentication, complaint, volume, and audience signals. A 99% receiver-acceptance rate does not answer the inbox-placement question.

What Email deliverability requires

A practical Email deliverability rollout

Seven steps, in order.

1. 01
   A diagnostic sequence that avoids random fixesWhen a merchant says "email is going to spam," do not start by changing the subject line. Narrow the failure first.
2. 02
   1. Identify the affected provider and time windowAsk whether the issue is Gmail-only, Yahoo-only, Outlook-only, or broad. Compare the same stream before and after the change.
3. 03
   2. Separate rejection from placementIf the receiving server is rejecting or deferring messages, inspect SMTP errors and sending-provider events. If messages are accepted but recipients report spam placement, the investigation shifts toward filtering, reputation, complaints, authentication, and audience quality.
4. 04
   3. Identify the affected sender identitiesRecord: - visible From domain; - DKIM signing domain; - SPF / return-path domain; - sending IP or pool; - campaign or stream identifier. A domain problem and an IP problem can look similar at the user level but require different remediation.
5. 05
   4. Check provider-native evidenceUse the receiver's own tools where available. Gmail Postmaster data is scoped to personal Gmail traffic. Microsoft SNDS is scoped to Outlook.com IP reputation. Yahoo's Sender Hub and Complaint Feedback Loop provide Yahoo-specific signals. Do not treat any one tool as a universal reputation oracle.
6. 06
   5. Compare complaints, bounces, authentication, and volume togetherOne metric rarely explains a deliverability incident by itself. A complaint spike after a sudden volume increase means something different from a quiet domain with clean complaint data but repeated authentication failures.
7. 07
   6. Change the causal input, then re-measureIf the problem is a stale segment, stop sending to it. If a provider is throttling a new IP, reduce and stabilize volume. If DMARC alignment is broken, fix the sender identity. If a specific acquisition source creates complaints, isolate that source. Avoid cosmetic changes that do not address the evidence.

What passes and what does not

• Deliverability investigations become much faster when the evidence is matched to the layer of the problem
• A sender can therefore have perfect authentication and poor placement, or 99% SMTP acceptance and a major spam-folder problem. Those are not contradictions; they are measurements of different gates

Common mistakes

1. A sender jumps from 10,000 messages a day to 200,000 after importing an old list. Authentication remains perfect, but complaints, invalid addresses, and unfamiliar volume appear together. The solution is not another DKIM key. It is audience and volume control
2. On a shared pool, other senders can contribute to IP-level reputation. Gmail explicitly notes that activity from senders on a shared IP can affect other senders. The merchant still owns list quality and domain behavior, but the infrastructure dimension is not fully isolated
3. A large marketing campaign can create complaint and throttling pressure around the same identities used for password resets or receipts. Separating streams gives operators better diagnostics and can reduce blast radius when a marketing stream deteriorates
4. Gmail warns that its displayed spam rate can look low when Gmail is already routing many messages to spam, because fewer messages reach recipients' inboxes where they can be manually marked as spam. A low complaint rate is therefore not proof that reputation is healthy

Comparison

Questions we get asked