Shared IPs have a reputation problem
Ask any deliverability nerd about shared IPs and you will get a wary look. The logic is simple: when many senders share one IP address, one careless sender can poison the well for everyone. Mailbox providers score the IP, not the individual account, so a single bad actor mailing a scraped list can drag thousands of honest senders toward the spam folder.
That logic is sound. It is also a choice, not a law of physics. A shared IP is only as risky as the company running it, and we decided early that we would rather do the hard work of curation than ship every new account straight to production infrastructure. This post explains exactly what that hard work looks like.
The short version: we approve every sender by hand before they can send a single email, we watch reputation signals around the clock, and we act fast — up to pausing a sender — the moment something looks off. Clean shared IPs are a discipline, not an accident.
Why IP reputation is a shared responsibility
Mailbox providers like Gmail, Outlook and Yahoo keep a rolling scorecard for every IP they see. Complaint rates, spam trap hits, bounce behavior, engagement — all of it feeds a reputation that decides whether your message lands in the inbox, the promotions tab, or the void. On a shared IP, every customer contributes to that scorecard, whether they mean to or not.
This cuts both ways. If you let anyone send anything, the shared IP becomes a race to the bottom and your good customers eventually leave. But if you curate carefully, the opposite happens: the pool becomes more trustworthy over time, and everyone on it benefits from volume and history they could never build alone. Most senders do not need a dedicated IP — they need a well-run shared one.
That is the deal we make with our customers: we handle the reputation battle for you, and in exchange we are strict about who gets a seat at the table.
Step 1: Human review of every sender
There is no instant, fully automated activation for sending on our pooled IPs. When you sign up, you can explore the API and send to a sandbox right away — but real outbound traffic starts only after a human on our team has looked at your account.
That review is deliberately unglamorous. We look at what you are sending, how you collected your recipient list, whether your domain has authentication set up, and whether your use case matches what you told us at sign-up. A receipt for an order is a very different animal from a cold outreach blast, and we treat them differently.
- Every new sender answers a short questionnaire about list origin and message type.
- We verify SPF, DKIM and DMARC records before the first real send.
- High-volume or bulk-adjacent use cases get a second pair of eyes, always.
- Accounts that smell like purchased lists simply do not get approved. No appeals by volume.
Yes, this costs us real time and real salaries. It is still the cheapest insurance we have ever bought.
Step 2: Continuous monitoring
Approval is not a one-time event. Every message that crosses our pooled IPs feeds into a monitoring pipeline that watches complaint rates, bounce patterns, blocklist mentions and provider-specific feedback loops. Our threshold for intervention is far lower than what a mailbox provider would punish — we would rather overreact quietly than underreact publicly.
Here is a slice of what our reputation monitor logged on a recent Tuesday morning. A broadcast stream crept above the complaint threshold, and the system responded before a human even had coffee:
# sampled every 60s across all pooled IPs
09:41:07 probe mx.pooled-04.postedapi.org ok score=99.2
09:42:11 probe mx.pooled-04.postedapi.org ok score=99.2
09:43:02 alert stream=broadcast/acme-news complaints=0.31%
09:43:04 action throttled broadcast/acme-news to 50% of quota
09:44:40 ticket #48211 opened — looping in the customer
Slightly simplified, but only slightly. The throttle happened ninety seconds after the alert.
Notice what did not happen: the rest of the pool kept sending at full speed. Because broadcasts travel on their own stream and their own IPs, a problem in one lane never becomes a problem in the other.
Step 3: Swift, decisive action
Monitoring without consequences is just very anxious observability. When our signals say a sender is sliding, we act in a fixed order: throttle first, contact the customer second, suspend only if the pattern continues. Throttling buys time without punishing recipients, and it keeps a small problem small.
One careless sender can undo the trust that thousands of careful senders spent years building. We treat every dip in reputation as an incident, not a statistic.
In practice, most cases end at the conversation. A surprising number of incidents turn out to be a well-meaning customer who imported an old list or turned a welcome drip into a marketing blast. We would much rather fix the source than cut anyone off — but we will cut someone off, and every customer knows it.
The bottom line
Shared IPs do not have to be a gamble. Run them like a private club instead of a public pool: approve deliberately, watch obsessively, and act before mailbox providers force your hand. That is how a shared IP earns a sender score most dedicated IPs would envy — and it is why our customers sleep fine at night.
If this sounds like the kind of plumbing you would rather not think about, good news: thinking about it is our whole job. Start for $1.90 and send your first email on infrastructure that somebody is actually watching.
PostedApi