Deliverability is a black box, and shared IPs let strangers tank you

Email deliverability is the odds that your message reaches the inbox instead of spam or the void — and on a shared-IP transactional service, those odds depend partly on strangers you’ll never meet. When your mail leaves from a pool of IP addresses shared with thousands of other senders, someone else’s spam run can drag down the reputation of the address your receipts go out on. And when placement drops, most providers give you a dashboard that says “delivered” and no way to see why the inbox didn’t agree.

I find this the most quietly infuriating part of the whole category. You do everything right — clean list, real content, low complaint rate — and your open rates still slide, and the support answer is a shrug wrapped in a status page.

The two problems, stacked

There are really two failures here, and they compound.

Problem one: shared IPs socialize other people’s mistakes. A shared sending pool is efficient — it’s why transactional email is cheap — but reputation at the receiving end (Gmail, Outlook, Yahoo) is computed per sending IP. When you share that IP, you share its reputation. If a co-tenant blasts a purchased list and racks up spam complaints, the mailbox providers throttle or spam-folder the whole IP for a while. Your password resets are now collateral damage for a campaign you never saw. One widely-shared account on Hacker News summed up the mood after months of this: at that point “you might as well have self-hosted” — the exact opposite of why you paid for a managed service.

Problem two: the black box. When placement drops, you want a cause. What you usually get is a delivery dashboard that proudly reports messages as “delivered” — meaning the receiving server accepted them — while saying nothing about whether they landed in the inbox or the spam folder, which are very different outcomes. When developers have pushed for specifics on throttling or a reputation dip, the answers trend toward the unhelpfully vague; more than one has been told a provider is unable to disclose specific reasons. Reports of Mailgun users watching inbox placement slide — one documented account went from the mid-50s into the mid-20s as a percentage — circulate precisely because there’s no in-product way to see it happening or to prove whose fault it was.

You can’t fix what you can’t see, and you can’t see what the provider won’t show you.

What actually helps

I’m not going to pretend deliverability is fully solvable — anyone who promises “100% inbox” is selling something. But a lot of it is boring fundamentals that providers should just handle for you, plus visibility they should just give you.

Get SPF, DKIM, and DMARC genuinely right. These three are the difference between a mailbox provider trusting your domain and treating you as a stranger. SPF says which servers may send for your domain; DKIM cryptographically signs the message so it can’t be tampered with in flight; DMARC ties them together and tells receivers what to do on failure. Misconfigure any of them and you’re penalized regardless of how clean your content is. This is table stakes, and it’s also where a lot of self-serve setups quietly break. MailKite generates and checks these records for you as part of domain onboarding — sending is gated until SPF and DKIM verify in DNS — so you’re not shipping mail on a half-authenticated domain and wondering why it’s in spam.

Run a monitored transactional stream — and keep it separate. Transactional mail (receipts, resets, confirmations) is your highest-trust, lowest-complaint traffic. It should not share reputation with bulk marketing blasts, yours or anyone else’s. A stream that’s watched — where anomalies surface instead of hiding behind a green “delivered” count — is worth more than a bigger sending quota.

Read the auth results on the mail you receive, too. Deliverability isn’t only outbound. When you receive email, the same SPF/DKIM/DMARC checks tell you whether an inbound sender is who they claim to be — and MailKite hands you that verdict in the webhook payload instead of making you compute it:

{
  "id": "msg_2Hk9…",
  "type": "email.received",
  "from": { "address": "ada@example.com" },
  "subject": "Re: invoice #1042",
  "auth": { "spf": "pass", "dkim": "pass", "dmarc": "pass", "spam": "ham" }
}

That auth block is the anti-black-box in miniature: a plain pass/fail you can act on. Reading it is a one-liner in your handler:

if (event.type === "email.received") {
  const authed = event.auth.spf === "pass" && event.auth.dmarc === "pass";
  // route, trust, or quarantine based on a verdict you can see —
  // not a green "delivered" badge that tells you nothing.
}

No guessing, no support ticket, no shrug. The full parsed-message shape and the same handler in five other languages are in the receiving docs.

The honest version

I can’t promise a stranger will never affect your placement — anyone selling transactional email at scale is doing some pooling, and reputation is ultimately the mailbox providers’ call, not mine. What I can argue for is the opposite of a black box: authentication that’s set up correctly and verified before you send, a transactional stream you can actually watch, and inbound auth results surfaced as data instead of hidden. Those don’t guarantee the inbox. They stop it from being a mystery.

FAQ

What is email deliverability, exactly? It’s the probability your message reaches the recipient’s inbox rather than the spam folder or nowhere. It depends on sender authentication (SPF/DKIM/DMARC), the reputation of the sending IP and domain, recipient engagement, and complaint rates — several of which you don’t fully control on a shared pool.

How can another company’s spam hurt my email? On a shared-IP service, mailbox providers compute reputation per sending IP. If a co-tenant on your IP sends spam and collects complaints, receivers can throttle or spam-folder mail from that whole IP — including yours — until reputation recovers.

Why do providers say a message was “delivered” when it went to spam? “Delivered” usually means the receiving server accepted the message, not that it reached the inbox. Inbox-vs-spam placement is a separate outcome many dashboards don’t expose, which is why placement can drop while your delivery stats stay green.

What can I actually control? The fundamentals: correct SPF/DKIM/DMARC, a clean and separated transactional stream, low complaint rates, and honest list hygiene. MailKite auto-configures and verifies the DNS records, and surfaces inbound auth results so at least the authentication side is visible rather than guessed.

---

Deliverability will never be fully in your hands — but it doesn’t have to be a black box. Point a domain at MailKite, get SPF/DKIM/DMARC verified up front, and read the auth verdict on every message you receive. Related: the inbound pillar on why receiving is the hard direction, and give your agent an inbox.