Shared email infrastructure is a double-edged sword. It gives small senders access to established IP reputation they couldn't build alone. But it also means one sender with a garbage list can drag down delivery rates for everyone else on those IPs.
This is not a theoretical problem. It happens constantly on every major ESP's shared IP pools. And most platforms handle it the same way: manual reviews, opaque suspensions, and days of silence while your campaign sits queued.
PushMail handles it differently.
The Real Problem With Shared Infrastructure
ISPs like Gmail, Microsoft, and Yahoo track email reputation at the IP level, not just the domain level. When an IP sends too many messages to invalid addresses, or when recipients mark too many messages as spam, the IP's reputation degrades. Every other sender on that IP suffers reduced inbox placement — even if their own list hygiene is perfect.
The math is brutal. A single organization sending to a purchased list with a 50% bounce rate can, within hours, cause deliverability problems for dozens of other senders sharing those IPs. The ISPs don't care that it wasn't your campaign. They see the IP, and they act on what the IP has done.
The only real defense is catching bad senders before the damage spreads.
The orgSendingHealth System
PushMail's answer to this problem is the orgSendingHealth system — an automated circuit breaker that monitors every organization's sending metrics in real time and pauses senders who cross defined safety thresholds.
The thresholds are not secret:
- Bounce rate above 8% (800 basis points over the last 7 days)
- Complaint rate above 0.3% (30 basis points over the last 7 days)
These numbers are derived from industry guidance and ISP postmaster documentation. Gmail's published recommendation is to keep complaint rates below 0.1% to maintain good standing. The 0.3% threshold gives senders meaningful headroom while still protecting the platform before permanent reputation damage occurs.
How the Circuit Breaker Works
Every bounce and spam complaint that flows through the platform triggers a health check for the sending organization. The check is a fast-path evaluation — it does not run on a schedule or wait for a batch job.
Here is what happens:
- A bounce or complaint event arrives via webhook from SendGrid.
- The system immediately queries the last 7 days of sending activity for that organization.
- It calculates bounce rate and complaint rate against total send volume.
- If either threshold is exceeded, sending is paused immediately.
- The pause is written to two places: KV for fast runtime enforcement, and D1 for persistence and audit history.
- The event is logged to the
orgHealthLogtable with full context — rates, thresholds, timestamp, and trigger event.
One important guard against false positives: the circuit breaker requires a minimum sample size of 10 sends before it can activate. An organization that has sent 3 emails and received 1 bounce has a 33% bounce rate on paper, but that number is statistically meaningless. The 10-send floor prevents new senders from being incorrectly flagged on their first few deliveries.
Two Layers of Enforcement
The health system operates at two levels, each serving a distinct purpose.
The KV cache layer is the runtime enforcement point. Every time the platform attempts to send an email for an organization, it checks KV first. This is a sub-millisecond lookup. If the organization is paused, the send is rejected immediately — no database query, no processing overhead. The KV entry has a 5-minute TTL, which means health status propagates across the platform within minutes of a pause being issued.
The D1 persistence layer is the source of truth. The full health record — current status, historical rates, pause reason, timestamps — lives in the database. This is what powers the dashboard view, enables admin review, and allows manual overrides when a sender has cleaned their list and is ready to resume.
The separation matters. KV keeps the enforcement path fast. D1 keeps the record accurate and complete.
What Happens When You Are Paused
Being paused is not the same as being silently blacklisted. PushMail does not drop your emails without telling you.
When the circuit breaker activates on your account:
- A webhook event is dispatched explaining the pause, including your current bounce and complaint rates.
- Your dashboard shows the exact metrics that triggered the pause — not a vague "policy violation" message.
- Your queued emails are held, not dropped.
- You can audit your list, remove problematic addresses, and request reactivation.
The system is designed to be corrective, not punitive. Most senders who get paused have a list hygiene problem they were not aware of. The automated pause gives them a clear signal, immediately, before the situation compounds.
Cross-Customer Suppression
The health system operates at the organization level, but PushMail's protection extends further through a global suppression list.
When an email address hard bounces for any PushMail customer, it is added to a global suppression list stored in KV. Every subsequent send attempt to that address — by any customer — is blocked before it ever reaches SendGrid.
This matters for new customers in particular. When you first start sending, you are building reputation from scratch. Without suppression data, your first campaign might hit a wave of bounces simply because those addresses have been invalid for years and your list vendor never cleaned them. PushMail's global suppression list means new senders benefit immediately from signals collected across the entire platform's history.
This is one of the actual advantages of shared infrastructure, when it is managed correctly.
How This Compares to Other Platforms
Most email platforms handle deliverability protection through manual review processes that are slow, opaque, and frustrating.
SendGrid suspends accounts manually after damage has already occurred. Reviews can take days. You may have no warning before your account is suspended and no clear explanation afterward.
Mailchimp's Omnivore system flags accounts for review but does not publish its thresholds. You do not know what triggered the flag, and the review process is not transparent.
Amazon SES is notorious for its account review process — slow, unresponsive, and with no clear timeline. Senders who breach thresholds often wait weeks for resolution.
PushMail's approach is automated, transparent, and immediate. The thresholds are published. The reason for any pause is explicit. The feedback loop is measured in minutes, not days.
Transparency as a Feature
Publishing your enforcement thresholds is not a vulnerability — it is a commitment. It tells senders exactly what responsible sending looks like and gives them a clear target to maintain.
PushMail's trust system is not designed to catch senders off guard. It is designed to protect the infrastructure, protect other senders on the platform, and give every organization the tools to understand and manage their own sending health before problems compound.
The developers building on PushMail are not email specialists by default. They are shipping products. The trust system is there so they do not have to become deliverability experts to send reliably.
If you want email infrastructure that protects your deliverability by design, get started at pushmail.dev.