Shared sending IPs are the default for most product teams. You sign up with a provider, send a few thousand messages a day, and the console shows green. Authentication aligns. Complaint rates sit under the thresholds everyone quotes. Seed tests look acceptable. Then one morning Gmail starts folding your password resets into spam, and nothing on your side changed.
What changed was a neighbor.
Receivers do not score mail in the vacuum most dashboards imply. They score domains, and they score the infrastructure those domains ride. On a shared IP, your domain reputation and the IP reputation are coupled. You can keep your own house clean and still inherit damage from whoever else is transmitting from the same address. The coupling is quiet until it is not. By the time placement falls, the damage has usually been accumulating for days.
How the coupling actually works
An IP has a sending history. Receivers keep that history. They care about volume shape, complaint density, bounce patterns, trap hits, and whether the traffic looks like human-requested mail or cold spray. When many unrelated senders share one IP, those signals mix. A receiver looking at the address does not always wait to separate your transactional stream from the neighbor who just loaded a purchased list. Aggregation is cheaper than perfect attribution, and cheap tools win at the scale of the big inboxes.
Shared pools try to contain this with policy. Providers throttle abusive accounts, eject bad actors, and rotate IPs when a pool gets dirty. That help is real. It is also incomplete. Ejection takes time. Rotation moves you onto a fresh address that has no trust of its own. Policy reviews lag the first wave of spam complaints. In the gap between a neighbor going bad and the provider finishing remediation, your mail is already paying the cost.
The failure mode that catches careful teams is the one that never looks dramatic in their own metrics. Their complaint rate stays low because their recipients asked for the mail. Their bounce rate stays low because their addresses are valid. Their authentication is correct. None of that protects an IP that just absorbed a spike of spam reports from a different customer on the same pool. From the receiver's point of view, the IP has become riskier. Your clean domain is still attached to it.
I have watched this play out on transactional streams that should have been boring. Signup confirmations, invoice receipts, password resets. Volume was stable. Content was stable. Engagement was fine. Placement still fell because a marketing tenant two seats over started a campaign that receivers classified as bulk abuse. The shared IP's complaint density jumped. Gmail and Microsoft tightened filtering on everything leaving that address. The transactional tenant saw the effect first, because people notice when a password reset goes missing.
What "fine" hides in the dashboard
Most sending consoles report what you control: your volume, your bounces, your complaints, your authentication status. They rarely surface neighbor risk in a way an operator can act on. You see your slice of the pool. You do not see the pool.
That gap produces false confidence. Teams check blocklists and find nothing. They run seed tests from a handful of accounts and get inbox. They read their own complaint rate and decide the infrastructure is healthy. All of those checks can pass while an IP is already under pressure from adjacent traffic. Blocklists are lagging indicators. Seed panels are tiny samples. Per-tenant complaint rates ignore shared-IP aggregation. The dashboard looks fine because it is measuring the wrong unit.
A more useful set of questions is structural. How many unrelated brands share the IP? How does the provider isolate abusive volume? How fast do they rotate or quarantine when a tenant spikes complaints? Can you get a dedicated IP without waiting for a volume threshold that only makes sense for newsletters? Are transactional and promotional streams forced onto the same address? If the answers are vague, you are accepting neighbor risk whether you named it or not.
Dedicated IPs are not magic. A dedicated address with no warm history can land worse than a healthy shared pool. Warm-up still matters. Volume consistency still matters. List hygiene still matters. The point of dedicated infrastructure is control of the reputation surface, not automatic inbox placement. You trade the neighbor problem for an ownership problem: you are responsible for every complaint that hits that address. For teams with mixed product and marketing traffic, that trade is usually worth making once volume is steady enough to keep the IP warm.
If you stay on shared IPs, segregate streams as far as the provider allows. Keep password resets and receipts off the same address as newsletter blasts when you can. Use separate domains or subdomains with their own DKIM alignment so domain reputation has somewhere to stand if the IP wobbles. Monitor placement on the messages users actually need, not only campaign seeds. A missing receipt is a support ticket. A missing newsletter is a shrug. Treat those differently in your alerting.
What to do when the neighbor already burned it
Once placement drops and you suspect shared-IP contamination, stop rearranging copy. Subject line A/B tests will not repair an IP that receivers have marked as noisy. Check whether your provider has rotated you, quarantined a neighbor, or opened a remediation ticket. Ask for the IP's recent complaint and volume profile if they will share it. Parallel-path critical mail through a second provider or a dedicated address while the primary pool recovers. Recovery on a burned shared IP is mostly waiting for the bad actor to leave and for receiver scores to decay. That can take longer than your product team has patience for.
Document the incident with timestamps, affected message types, and which receivers tightened. The next time someone argues that shared infrastructure is "good enough forever," you will want that record. Shared IPs are a reasonable starting point. They are a poor permanent home for mail that has to arrive.
The uncomfortable conclusion is ordinary. Inbox placement depends on infrastructure you do not fully control whenever you share an IP. Your authentication can be perfect. Your list can be clean. Your volume can be honest. A neighbor can still burn the address out from under you. Plan for that coupling before the morning the password resets disappear, because by then the only options left are slow ones.