Ask anyone in email what good deliverability means and you will get the same answer: land in the inbox, stay out of spam. That is the number everyone tracks, reports, and sells against. It is also half the story. Placement tells you where a message ended up. It says nothing about how long the recipient waited for it. For a newsletter, nobody notices the difference. For a password reset or a login code, the wait is the whole experience, and almost nobody measures it.
The Metric Almost Nobody Publishes
Every deliverability tool measures placement. Seed-list tests fire a message at a panel of mailboxes and report how many reached the inbox. Postmaster Tools shows you reputation, spam rate, and authentication. All of it is worth watching. But it answers one question, where did the mail land, and skips the one your users actually feel: how long did it take to show up?
Speed gets left out because it is hard to measure honestly. You cannot estimate it from logs. You have to send real mail to real mailboxes and read the clock on the far side, over and over, around the clock. That is more work than printing a number on a slide, so most senders do not bother.
For Transactional Email, the Wait Is the Product
Reset a password and watch what you do. You sit on the inbox waiting for the code. Two seconds and the product feels solid. Forty seconds and you are reloading the page, opening spam, second-guessing whether you typed the right address. Maybe you ask for another code and now two are racing. By the time slow mail lands, you have already decided the app is flaky.
That is the part people miss. A transactional email is not a notification about the task, it is part of the task. Signing in, paying, verifying an account, all of it waits on the message. When the message is slow, the work stalls, and it shows up later as abandoned signups and support tickets that say I never got the email. Usually they did. It just arrived late enough to feel like never. A code that lands in two seconds and one that lands in forty are different products, even if a placement report files them both under delivered.
What Time to Inbox Means
We call the number Time to Inbox. It is the time from a send request reaching our servers to the message showing up in the recipient's inbox, the whole trip rather than our part of it. The definition matters, because the easy way to look fast is to time something shorter than what the recipient actually sees.
Where the clock stops is everything. It stops when the message is in the inbox, not when the receiving server agrees to take it. A 250 OK over SMTP means the mailbox accepted the bytes and nothing more. After that, the message can sit in a queue, run through filtering, or wait behind other mail before a person ever sees it. Stop timing at the 250 and you are measuring your own handoff, not your recipient's wait.
This is also why most speed claims are noise. A vendor quoting milliseconds is usually timing how fast its API takes your request. One quoting messages per second is describing throughput. Both sound impressive, and neither is the number someone staring at an empty inbox cares about.
How We Measure It
The method is dull, which is the point. Every 15 minutes, day and night, we send real emails to real mailboxes at Gmail, Outlook, Yahoo and iCloud. When one arrives, we read its timestamps and work out how long the trip took, from our servers to the inbox. Same test, same way, every time.
Two rules keep us honest. Only mail that reaches the inbox counts, so a message that lands in spam or fails cannot quietly improve the average, though we still log those separately. And we keep every provider on its own line instead of blending them into one flattering headline, because Gmail and Yahoo behave nothing alike and the average would bury the gap.
In practice, delivery to the big providers runs in seconds, not minutes. Gmail is usually the quickest, often a couple of seconds. Yahoo is usually the slowest, and the most variable hour to hour. The figure moves with the receiving provider, the message itself, and the network, so we do not iron out the spikes. They are real, and hiding them would defeat the point. You can watch it move on our live email delivery speed page.
Why We Publish It Live
Anyone can put lightning fast on a marketing page. It costs nothing and proves nothing. We would rather hand you a live page that updates every 15 minutes and would embarrass us the day our numbers slipped. A claim you cannot check is just marketing. A bad number in public is something we have to go and fix, which is exactly why we put it there.
Speed comes from infrastructure, not adjectives. We keep these times down by running our own outbound infrastructure on an anycast network, sending each message from the data center nearest the recipient over the cleanest path to their provider. Landing in the inbox still comes first, and that is mostly about domain reputation and authentication rather than raw speed. But once your mail reliably lands, how fast it lands is the next thing people notice. So we measure it, and we leave the result on a page anyone can open.
Want delivery your users do not have to wait for?
JetEmail runs its own outbound infrastructure, publishes its live Time to Inbox, and sets up authentication when you onboard, so your mail lands fast and in the inbox. Start free, or watch the live numbers first.
