Deliverability is a black box, and shared IPs let strangers tank you
On a shared sending pool, a stranger's spam run can drag down the IP reputation your receipts go out on, while the dashboard still says 'delivered.' What you actually control: correct SPF/DKIM/DMARC, a separate monitored stream, and reading inbound auth results as data.
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 reason splits cleanly in two: your mail is judged by two separate reputations, and you own exactly one of them.
Before the argument, the concrete part, because it’s the one lever you fully control. Deliverability has exactly one input you own outright: proving your domain’s identity. Three DNS records do it, and three dig calls prove they resolved:
; SPF — authorize who may send as your return-path (bounce) domain
myapp.ai. TXT "v=spf1 include:spf.yourprovider.com ~all"
; DKIM — publish the public key your outbound mail is signed with
sel._domainkey.myapp.ai. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ…"
; DMARC — require SPF or DKIM to align to your visible From:, set policy + reports
_dmarc.myapp.ai. TXT "v=DMARC1; p=none; rua=mailto:dmarc@myapp.ai"dig +short TXT myapp.ai # SPF
dig +short TXT sel._domainkey.myapp.ai # DKIM (swap in your selector)
dig +short TXT _dmarc.myapp.ai # DMARCRunning your own dedicated IP instead of a provider’s pool? Then SPF is an ip4: mechanism pointing straight at that address, and the reputation it earns is entirely yours to warm and keep warm. Either way, start DMARC at p=none so you collect the aggregate reports without bouncing real mail, read them until every legitimate stream aligns, then tighten to p=quarantine and eventually p=reject. Nothing else in this post matters if these three don’t resolve.
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. The bitter one-liner you’ll see in threads about this: at that point you might as well have self-hosted, which is 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 push for specifics on throttling or a reputation dip, the answers trend toward the unhelpfully vague, often some version of “we can’t share specifics.” Threads about placement quietly sliding on shared pools circulate precisely because there’s no in-product way to watch it happen, 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.
Everything worth doing lives in those blue stages. You own the authentication and your domain’s reputation; the shared IP is the one stage you can’t reach, which is exactly why getting the rest airtight matters so much.
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:
Misconfigure any one and you’re penalized regardless of how clean your content is. This is table stakes, and it’s where a lot of self-serve setups quietly break: a second stray SPF record, an unaligned subdomain, a DMARC parked at p=none forever. MailKite (which we build) generates these records and gates sending until SPF and DKIM actually verify in DNS, so you can’t ship mail on a half-authenticated domain by accident. It’s nothing you can’t get elsewhere: Postmark and SES will hand you the same three records to paste. The only difference is whether they’re verified for you or left as a checklist you might get wrong.
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. And you don’t need a vendor’s blessing to watch reputation directly: Google Postmaster Tools and Microsoft SNDS report your domain and IP reputation, spam-complaint rates, and authentication pass rates straight from the two largest mailbox providers, for free. Wire both up whoever you send through. They’re the closest thing to prying open the black box yourself.
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.