Testing rented sending against our own: 16.8 versus 55.6 percent inbox placement
Same list, same week, three sending setups, placement measured on our own seed inboxes. The third-party relay reached the inbox 16.8 percent of the time. The rented pool reached 55.6. Our own cluster beat both.
The problem with renting sending infrastructure is that you cannot inspect it. This article is the three ways that blindness shows up, the test that made us stop renting, and enough of the measurement mechanics that you can run the same test on your own stack.
Four measurements, usually reported as one
Before the test makes sense, you need the ladder it measures against. “Delivered” hides four different events, and they differ substantially.
Acceptance by the sending infrastructure is the easiest of the four to obtain, and it is the one most commonly reported. A vendor dashboard telling you a message was “delivered” is telling you a server accepted it. It says nothing about whether the message reached the inbox or a spam folder.
When a sending tool reports 99 percent delivery, it usually means 99 percent of messages were accepted by some server, somewhere. A message sitting in a spam folder was “delivered.” The number that pays for anything is how many landed where a person looks, and most tools cannot tell you that, because measuring it requires mailboxes on the receiving side.
One related habit we keep: we trust clicks over opens. Apple and security scanners prefetch images, so opens inflate for reasons unrelated to reading.
What renting hides: warmup pools
Traditional warmup pools create artificial traffic between a relatively fixed group of participating mailboxes. That differs from normal outbound email, where recipients are spread across a much broader and changing set of accounts.
Providers have access to sender and recipient relationship data, sending patterns, bounce behaviour, and engagement signals. A highly repetitive network of accounts mailing one another may therefore be distinguishable from ordinary traffic. We saw domains develop reputation problems after taking part in warmup pools.
We also found that mailboxes inside some pools expire. Messages sent to those inactive accounts bounce, and the bounces still count against the sending domain’s reputation. The service meant to build reputation was spending it.
Our conditioning traffic now goes to real recipients, and it counts inside the same daily limits as everything else we send.
What renting hides: shared relays
With a rented relay, your mail may go out through infrastructure that other customers also use. Your deliverability can be affected by activity you cannot see or control. There is no way to audit the neighbours, because the neighbours are the vendor’s customer list.
A shared relay is an apartment building with one street address. If one tenant gets the address a bad name, every tenant’s mail suffers, and the building manager does not publish a tenant list. Owning the building is more work. It is also the only way to know who lives there.
The test
We ran all three setups against the same list during the same week, and measured placement using our own seed inboxes.
A seed test works like this: you keep a set of mailboxes you control at the receiving providers you care about, add those addresses to the send, and record where each message actually lands, inbox, tab, or spam. No vendor self-reporting anywhere in the loop. It is the difference between asking the courier whether the parcel arrived and asking the person it was addressed to.
The third-party SMTP relay reached the inbox 16.8 percent of the time, with 73.8 percent landing in spam. The rented mailbox pool reached 55.6 percent, with 39.8 in spam. Our own sending cluster performed better than both.
| Setup | Inbox | Spam |
|---|---|---|
| Third-party SMTP relay | 16.8% | 73.8% |
| Rented mailbox pool | 55.6% | 39.8% |
| Our own sending cluster | best of the three | lowest of the three |
This was one test, on one list, in one week, not a general benchmark (the address-ownership article covers the architecture behind the third setup). It was enough for us to move our own sending onto the third setup. In a later test on our own system, every Outlook Workspace seed landed in the inbox on a domain that was new at the time, against 16.8 percent for a rented relay tested the same way. One test, one domain, one point in time, and we publish it with exactly that caveat.
Check it for yourself
Your DNS already admits whose infrastructure your mail rides on.
# The SPF record names every sender allowed to speak for your domain
dig TXT yourdomain.com +short | grep spf
# "v=spf1 include:sendingvendor.com ~all"An include: pointing at a sending vendor means your deliverability shares a fate with every other customer behind that include.
Who this applies to
The seed test applies to anyone who sends: it is an afternoon of setup and it replaces every argument about deliverability with a measurement. The rent-versus-own decision applies once volume matters to revenue. Renting is a reasonable trade while the cost of leaving is small; the point of this article is to know what the trade is before it grows.
Still open
This was one list, one week, one pair of vendors. We have not repeated it across seasons or list types, and seed mailboxes measure placement, not engagement, so a seed panel can drift from what real recipients see. We treat the result as decisive for our stack and indicative for anyone else’s.
On the graph8 API
Sending through the graph8 platform rides the cluster this article describes, and the parts a builder needs are exposed rather than hidden: mailbox inventory and warmup state are readable over the API and MCP, so an application can check the health of its sending capacity instead of trusting it. Placement on our side is measured with seed inboxes we control, which is where the numbers in this article came from.
The principle
Acceptance is not arrival. Measure placement yourself, with seed inboxes you control, or you are reading the vendor’s grade of their own homework. The test is cheap to run and it ends the argument.