Who actually sends your newsletter? (and why your deliverability isn't in your hands)

You write a newsletter, you hit send, and a few minutes later it's in someone's inbox. Simple. But there's a question almost nobody asks, and the answer changes how you should think about the whole thing: when you click that button, who actually puts your email on the wire?

Most people assume it's the tool they're using. You signed up for a newsletter platform, you pay it every month, so surely it's the one sending. Usually it isn't. The tool wrote the message and rendered it nicely, but the actual work of relaying it out to Gmail and Outlook was handed to something else entirely. And you almost certainly weren't told what.

The reseller reality

Sending email at scale from raw servers is genuinely hard, and the big cloud providers block it by default because their addresses get abused constantly. So building your own sending infrastructure, the kind that mailbox providers will trust, is expensive and slow. Most newsletter tools, reasonably enough, decide not to. Instead they sit on top of one of a small number of large shared sending platforms and pass your mail through it.

This is a structural fact about the category, not an accusation aimed at any one product. It's just how the market is built. A large share of the newsletter and email tools you can name are, underneath the dashboard, a nice interface wrapped around someone else's sending pipeline. Two or three big backends carry an enormous fraction of the world's outbound email, and a long list of well-known tools are their customers. You're paying your tool, your tool is paying a backend, and the backend is the one that actually talks to Gmail.

None of that is inherently wrong. Reselling infrastructure is a normal way to build a product, and for a lot of tools it's the only sane way to ship at all. It's how the modern software stack works: almost everything is built on someone else's something. The problem here is specific. Email is one of the few places where the layer you're sitting on doesn't just serve your traffic, it lends you its reputation, and reputation is shared. That's the difference between reselling storage and reselling sending. Nobody else's files make your files load slower. Other people's spam absolutely can make your newsletter land in the junk folder. The problem is what that quietly does to your deliverability, and the fact that you have no window into it.

What a shared pool actually is

Here's the part that matters. Those big backends don't give each small customer their own dedicated sending address. That would be uneconomical and, for low-volume senders, actually counterproductive. Instead they group many customers together onto shared pools of sending IPs. Your newsletter goes out from the same addresses as a lot of other people's mail.

Mailbox providers like Gmail and Outlook decide whether to trust incoming email largely by reputation, and a big input to that reputation is the sending IP. So when you're on a shared pool, the reputation you're judged by isn't purely yours. It's the pool's. You inherit the aggregate behavior of every other sender on it.

Think about what that means. Somewhere on your pool there might be a company running an aggressive discount-code blast to a list they bought. Someone whose confirmation flow is broken so they're pumping mail at addresses that bounce. Someone who just triggered a complaint spike because their "weekly digest" turned into a daily one without asking. You will never know these people exist. You did not choose them, you cannot see them, and you certainly can't make them behave. But when their numbers go bad, the pool's reputation dips, and your carefully written, fully opted-in newsletter can land in spam because of a stranger you've never heard of.

This is deliverability outsourced twice over. Your tool outsourced its sending to a backend, and that backend pooled you in with people whose sending habits are now partly your problem. Two layers of decisions, both made above your head, both affecting whether your readers ever see you.

To be fair, the good backends work hard to keep their pools clean. They monitor complaints, they suspend bad senders, they try to sort the careful customers from the reckless ones. It genuinely helps, and it's a real part of what your tool is paying for on your behalf. But it's damage control, not immunity. You're still riding on a shared reputation, which means you're relying on someone else's moderation being fast enough and strict enough, every single day, to protect a number that decides whether your work reaches people. That's a lot of trust to place in a system you can't see and didn't choose.

Why this got sharper in 2024

It used to be that shared-pool reputation was a slow, background thing. Then the rules got explicit. In February 2024, Gmail and Yahoo rolled out bulk-sender requirements that turned deliverability from a soft art into a hard gate. If you send in any real volume you now need SPF, DKIM, and DMARC set up correctly, a working one-click unsubscribe, and, crucially, you need to keep your spam-complaint rate low. The widely cited threshold is to stay under 0.3 percent, and you really want to be nowhere near it.

Complaint rate is the interesting one here, because on a shared pool it isn't entirely yours to control. You can run an immaculate list and still be sitting behind IPs whose aggregate complaint numbers are being pushed up by other senders. The mailbox providers are increasingly precise about who they trust, and that precision cuts against you when your reputation is blended with strangers. The stakes of who you share a pool with went up the day those rules landed, and most people on shared pools have no idea they're exposed to it.

The frustrating part is that there's usually nothing you can do about it from inside the tool. There's no dashboard toggle for "please don't pool me with people who buy lists." You don't get told who else is on your IPs, you don't get told when the pool's reputation moves, and you often can't even find out which backend you're on. Your inbox placement is being decided by inputs you can't see and can't touch.

The alternative: owning the pipeline

So what's the other option? A platform that runs its own sending pipeline instead of reselling someone else's, and that isolates each customer's reputation rather than blending everyone together.

When your sending reputation is isolated, the math changes in your favor. Your inbox placement reflects your list quality and your sending behavior, and nothing else. If you keep a clean, opted-in list and send mail people actually want, that shows up as good reputation that belongs to you. If someone else on the platform makes a mess, it stays their mess. Their bad week can't spill onto your Tuesday send. You stop being quietly liable for the behavior of people you never met.

That's the whole benefit, and it's a real one: predictability. You get to be judged on your own work. When your open rate moves, it's because of something you did, a subject line, a send time, a change in what you're writing, and not because of noise from a pool you can't see. That makes the problem debuggable, which the shared-pool version fundamentally isn't. For a newsletter, where the entire value is the relationship between you and readers who chose to hear from you, having that relationship gated by anonymous strangers on a shared IP is exactly the wrong trade.

This is something we learned by doing it the hard way. In our early days we leaned on third-party sending providers like everyone else, and over time we decided that wasn't good enough for the people relying on us. We didn't want our customers inheriting anyone else's reputation problems, so we brought the sending in-house and built it so each customer's reputation stands on its own. We're not going to bore you with how it works under the hood. The point isn't the plumbing. The point is that when you send, the only sending behavior that affects you is yours.

What this means for you

You don't need to become an expert in any of this. You mostly need to know the question exists, because most people never learn to ask it. Next time you evaluate a newsletter tool, the useful thing to find out isn't the feature list. It's who actually sends your mail, and whether your reputation is yours alone or quietly pooled with everyone else's.

That's the part Yellaro takes off your plate entirely. We run our own sending pipeline, we isolate your reputation so your inbox placement depends on you and nobody else, the pricing is flat, and it's EU-hosted. You write the newsletter and never have to think about any of the above. See how it works.