Research

One customer's list got your whole platform blocked. What to do, in order.

If you send email on behalf of your customers, the order you do things in matters more than any single action — because the expensive mistake is also the most tempting one.

Rodney Palmer · Northline Standard · 23 August 2026

If you run a platform that sends email on behalf of your customers, this is the shape of the bad morning: delivery falls off, support tickets arrive from customers who did nothing wrong, and somewhere in your system is one tenant who uploaded a list they should not have.

The order you do things in matters, because the expensive mistake — pausing everything while you figure it out — is the one your instincts will reach for first.

1.Work out what is actually happening before you do anything

Three different failures look identical from the support queue and need different responses.

Deferrals (4xx). The receiving side is throttling you, not rejecting you. Mail is queued, not lost. This is usually reputation-driven and often recovers within hours or days once volume and complaint rates normalise. Do not requeue aggressively — hammering a provider that is asking you to slow down makes it worse.

Hard rejections (5xx) with a blocklist reference in the string. Read the actual bounce text; it usually names the list and often includes a lookup URL. That tells you who to talk to, which is a different conversation from a reputation problem.

Your own provider putting the account under review. This is not a mailbox provider — it is your ESP's internal enforcement, with its own thresholds. Amazon publishes theirs, which makes them a useful yardstick even if you are elsewhere: a bounce rate of 5% or greater puts an account under review and 10% or greater can pause it; complaint rates of 0.1% and 0.5% do the same. Measure yourself against those numbers before assuming you are fine.

2.Find the tenant

This is the part that takes longest, and how long depends entirely on decisions you made months ago.

If you have per-tenant sending separation — SendGrid subusers, Mailgun subaccounts, Postmark servers, SES tenants — you have per-tenant statistics. Sort by hard-bounce rate and complaint rate, not by volume. The offender is frequently not your biggest sender.

If you do not, you are working from logs, and you can only segment by whatever tenant identifier you put into the message envelope or headers. If you did not put one there, that is today's real lesson and it is worth fixing before the incident is even closed.

Then check recency. When did that tenant's list last change? A list uploaded in the last week and sent to for the first time is the answer far more often than anything subtle.

3.Stop that tenant, not everyone

The reflex under pressure is to pause all sending. That converts one customer's mistake into an outage for every customer you have, and it does not make the reputation recover faster.

Pause the tenant you identified. If you are on SES, tenant-level policies can do this automatically — Standard pauses on high-severity reputation findings, Strict on any finding — and the pause applies to that tenant without touching anyone else's sending. On SendGrid, Mailgun and Postmark the separation exists but the decision is yours to make and execute; there is no automated reputation trigger to lean on.

Suppress rather than delete. You will need the record in step 4, and a purged list is a record you no longer have.

4.Talk to whoever blocked you, briefly and specifically

Whether it is a blocklist operator, a mailbox provider or your own ESP, they want the same three things, and they want them short:

1. What caused it — specifically. “A customer uploaded a purchased list of 40,000 addresses on the 14th.”
2. What you did — past tense, already done. Suspended, list removed, sending stopped.
3. What prevents recurrence — a mechanism, not an intention. A rate cap, a new-tenant volume ramp, a verification step.

Point three is the one that gets read. Apology is not a control and remorse is not a mechanism. Nobody on the other end is interested in how sorry you are; they are deciding whether letting you through again creates work for them next month.

With Google and Microsoft specifically, there is usually no one to negotiate with. You fix the cause, you send well for a while, and reputation recovers on its own schedule.

5.Tell your other tenants before they ask

They will find out. Every one of them can see their own delivery falling.

Say what happened, what you did, when you expect it to clear, and what you are changing. Do not name the tenant who caused it — to the others you are the platform, and the platform having a customer problem is a very different message from the platform naming and shaming its customers.

6.Fix the four things that made it expensive

Not the block — the block was going to happen eventually. The reason it cost a whole day.

Per-tenant sending identity, from day one. Even if you never isolate IPs, being able to segment by tenant is the difference between step 2 taking twenty minutes and taking six hours.

A per-tenant metric with a threshold and an alarm. Aggregate rates hide exactly the thing you need to see — one tenant at 30% bounce disappears inside a healthy platform average.

Something at signup. Verify the sending domain. Ask how the list was built, in a form field, and keep the answer. Cap new tenants until they have earned volume. None of this is expensive, and all of it is easier to add before you have ten thousand tenants.

Log the consent event. This is the one almost nobody does, and it is the subject of the next section.

7.The part most platforms have not read

Somewhere in your provider's terms is language making all of the above your responsibility rather than theirs. This is not a criticism of the providers — the position is defensible, and several of them publish genuinely helpful guidance on how to meet it. But it is worth knowing precisely, because most platform teams have never looked.

Twilio SendGrid's Email Policy (last updated 9 April 2026) asks customers to “use reasonable efforts to… detect and remove your End Users and customers who violate this Email Policy.” That “reasonable efforts” qualifier is real and worth reading carefully — it is not an absolute duty, and anyone quoting the clause without it is overstating the position. The Terms of Service (last updated 16 July 2026) are firmer: §2.2 requires you to “be solely responsible for all acts, omissions, and activities of your End Users.”

Mailgun's Acceptable Use Policy (revised 16 January 2023): “You are responsible for violations of this AUP by anyone using your Services with or without your permission, including any use on an unauthorized basis as a result of your failure to use reasonable security precautions.”

Postmark publishes a guide on how to vet new customers before letting them send, on the reasoning that “sending on behalf of someone who causes consistent deliverability issues could ultimately affect your own standing in Postmark, resulting in temporary sending suspensions until the issue is resolved.”

Amazon sets out its enforcement thresholds publicly and is candid about the division of labour once they trip. Asked whether it will help diagnose the problem, the SES documentation answers: “Typically we can give you only a high-level overview of your issue (for example, that you have a problem with bounces). You'll need to investigate the root cause on your end.”

And there is one obligation in there that surprises people

Twilio requires you to “retain proof of all affirmative consents obtained from recipients at least until the recipient withdraws its affirmative consent” and, on written request, to “promptly provide proof of a recipient's affirmative consent and the date and the method through which that recipient's email address was obtained.”

Mailgun's equivalent sits under a heading about what must be produced in the event of an escalated abuse complaint — so it is triggered rather than arbitrary — but once triggered it has no notice period at all: “At any given moment, you must be able to provide information regarding all email addresses… to which you've sent emails… including the basis of the obtained consent, when and how the email address… was collected.”

If you are multi-tenant, think about where that consent event actually happened. It happened inside your customer's signup flow, on their site, possibly years ago. There is a reasonable chance you never recorded it, because until the request arrives there is no reason to.

Worth saying plainly

Most of this is not hard. It is just work that has no owner until the morning it does — and by then you are doing it under time pressure with your customers watching.

If your platform sends on behalf of customers and you have been through some version of this, I would genuinely like to hear how it went — what broke, who found out first, how long it took to identify the tenant, and what you had to produce afterwards. I am researching how platforms actually handle this rather than how they are supposed to, and there is very little written about it.