Deliverability rate vs delivery rate, and what changes when an agent reports them

Deliverability rate vs delivery rate, defined

Deliverability rate (also called inbox placement rate) is the percentage of sent emails that reach the inbox, as distinct from delivery rate, which only counts messages the receiving server accepted. Delivery rate is accepted divided by sent. Deliverability rate is inboxed divided by sent. An AI agent asked "how did the send do" reports whichever number the API calls delivered, so the report has to say what was counted, and out of how many.

One more trap sits inside the delivery rate itself: the "delivered" count can come from two different places, and both get the same label.

What changes when an AI agent reports deliverability

An agent working in Claude, ChatGPT or Cursor that sends through MCP or the email API gets back an API response for each message. That response means the message was queued, not that a receiving server accepted it. When the agent is asked for a summary, the easy number is API responses over sent, and the easy label is "deliverability". A count of API responses is a sent count, not yet a delivery rate, and even a true delivery rate says nothing about which folder the mail landed in. Email for Claude covers the setup for one agent client.

An agent report on email performance needs three things a person might skip:

• The count accepted by the receiving server and the inbox estimate are kept apart, and the report says which one it has. Usually it only has the first.
• Every rate says what was counted, and out of how many, for example 4,930 delivered of 5,000 sent.
• A delivery rate is never called a deliverability rate. If no inbox measurement was taken, the report says so.

Deliverability rate moves after the damage is done. The checks that protect it sit before the send, not in the report: nitro_get_status for account readiness and sender identity, and nitro_review_delivery for a read-only spam and preflight review of the draft.

What is a good deliverability rate?

The bar: the DMA's 2026 benchmarking puts the average delivered rate at 99.2%, while Validity puts global inbox placement near 87%. George Hartley, Nitrosend's co-founder, sets out both figures in the Email Marketing Bible, with a plain line: "delivered" is not "inboxed". Compare a delivery rate with the first figure and a deliverability rate with the second.

That gap is why a 99% delivery rate can hide a spam problem. A campaign can show 99% delivery and a far lower deliverability rate if much of it landed in spam. The inbox placement guides cover the fuller distinction, and the email deliverability hub shows how the two numbers fit the wider diagnosis. The mechanics of acceptance are covered on email delivery, and how to calculate inbox placement rate has its own page.

Engagement feeds the gap too. In a 2020 video George put it this way: the more unopened emails you leave in inboxes, the worse your deliverability gets. A delivery rate does not show that decay. An inbox placement reading can.

How to measure and improve deliverability rate

Measure it with a seed-list inbox test, since logs only give delivery rate. Improve it the usual way: authentication, reputation, and list hygiene, starting with email validation before a list is imported. The email deliverability best practices page lists the steps in order.

For Gmail specifically, Google Postmaster Tools gives you the reputation and spam-rate side that a seed test cannot see, and the provider rule changes tracked in email deliverability news move the thresholds those numbers are judged against.

For a low deliverability rate, the Email Marketing Bible sets out a step-by-step triage: authentication first, then reputation, then content, then the AI-mediated inbox, where Gemini summaries sit between your email and the reader and open rate is treated as noise.

How to read a delivered count in Nitrosend

nitro_get_insights returns email analytics with trends, benchmarks and recommendations, so an agent can pull sent, delivered, bounced and complaint counts for a period and compare them over time. The same numbers apply to transactional email (the glossary definition covers what counts as one). A receipt filtered to spam looks like a broken product.

Before any number is trusted, check where "delivered" came from. A delivered count built from provider delivery confirmations is the authoritative one. A count derived from completed sends is a sent count under another label, which is what the figure above shows. Either way it is still a delivery rate, not a deliverability rate.

Worked example: an agent writes the weekly send report

The prompt: "Write this week's email report. How did the sends do, and is next week's newsletter safe to go?"

Before. Left unguided, an agent adds up the API responses from the week, divides by the number of sends, and writes "Deliverability: 99%". A count of API responses is a sent count, not yet a delivery rate, the report does not say what was counted or out of how many, and next week's newsletter goes out on the strength of it.

After. With the Nitrosend MCP tools, the agent works through a fixed sequence:

1. nitro_get_status confirms which account and sender identity the report covers.
2. nitro_get_insights pulls the last 7 days: sent, delivered, bounced and complaints, with the trend against the week before.
3. The agent writes the delivery rate as delivered over sent with both counts shown, and labels the deliverability rate "not measured" unless an inbox test or Postmaster reading exists for the week.
4. nitro_review_delivery checks next week's newsletter draft for spam signals and preflight problems. It reads only, and sends nothing.
5. nitro_send_test_message puts one copy of that draft in the test inbox for a person to open.
6. The person approves the newsletter with nitro_control_delivery, and the agent does not schedule it on its own.

The report line changes from "Deliverability: 99%" to "Delivery rate 98.6% (4,930 delivered of 5,000 sent). Deliverability rate not measured this week." The second line is less flattering and it is the one a person can act on. To fill in the missing number, run an inbox test before next week's send.

Where it goes wrong when an agent reports deliverability

• A sent count labelled delivered. The agent counts API responses and calls them delivered. Queued by the API is one step earlier than accepted by the receiving server, and neither is the inbox.
• Spam-folder delivery counted as success. A message filtered to spam is still delivered. A report that treats delivered as the goal reports a spam problem as a good week.
• A rate over a tiny send. 100% of 12 test sends says nothing about a list. The report should show the count next to every rate so a reader can see when the sample is too small to mean anything.
• A benchmark that counts something else. An agent compares its delivery rate to an industry inbox placement figure, or the reverse, and reports a gap that is only a change in what was counted. The DMA's 99.2% delivered and Validity's near 87% inbox placement measure different things.
• Open rate read as inboxing. Opens are noise in the AI-mediated inbox, so a rising open rate is not evidence the deliverability rate went up.
• A backlog that hits the daily allowance. On the Free plan the daily allowance runs from 100 to 5,000 recipients per rolling 24 hours. A new account starts at the low end and rises with sender standing, so an agent that batches a backlog of sends may hit the limit. The tiers are on the pricing page.

FAQ

Go deeper