Why shared ESPs ban cold email

Every major shared-infrastructure email provider forbids unsolicited bulk mail, and every one of them says so in language you can read for yourself. The reason is structural rather than moral: on a shared platform your mail leaves from the same IP addresses as everyone else’s, so your complaint rate lands on their reputation. Below is the current text of five policies, quoted directly, plus the two things you can legitimately do instead.

What is a shared IP pool, and why does one sender break it for everyone?

Sign up for a transactional email API and you are typically not given an IP address of your own. You are given a slot in a pool. Amazon states it plainly in the SES developer guide:

When you create a new Amazon SES account, by default your emails are sent from IP addresses that are shared with other SES users.

Amazon SES Developer Guide, "Dedicated IP addresses for Amazon SES"

The same page carries a comparison table, and its most useful row is "IP addresses & reputation isolated from other SES customers". For shared IP addresses the answer is "No". That is the entire problem in one table cell.

You can see the pools from outside. For a customer’s mail to pass SPF, the customer’s record has to authorise the provider’s sending addresses — normally with an include: pointing at a record the provider maintains — so every shared pool has a public inventory sitting in DNS.

$ dig +short TXT sendgrid.net | grep spf1
"v=spf1 ip4:167.89.0.0/17 ip4:208.117.48.0/20 ip4:50.31.32.0/19 ip4:198.37.144.0/20 ip4:198.21.0.0/21 ip4:192.254.112.0/20 ip4:168.245.0.0/17 ip4:149.72.0.0/16 ip4:159.183.0.0/16 ip4:134.128.64.0/19 ip4:134.128.96.0/19 include:ab.sendgrid.net ~all"

$ dig +short TXT pm.mtasv.net | grep spf1
"v=spf1 include:spf.mtasv.net -all"

$ dig +short TXT spf.mtasv.net
"v=spf1 ip4:50.31.156.96/27 ip4:104.245.209.192/26 ip4:50.31.205.0/24 ip4:147.160.158.0/24 -all"

Add up the eleven ranges in the first record and they cover 235,520 addresses, before the include: expands. The second lookup is the host Postmark documents as the Return-Path CNAME target for a customer domain, pm.mtasv.net; it delegates to spf.mtasv.net, whose four ranges total 608 addresses. Those are the addresses each provider is authorised to send from rather than the number in rotation on any given day — SPF tells you the boundary, not the occupancy, and a record like this covers a provider’s sending infrastructure as a whole, dedicated IPs included — but the shape is clear. A finite, published set of IPs carries the mail of every customer on the platform.

Mailbox providers score reputation at the IP and the domain level, and they publish the numbers they score against. Google’s sender guidelines tell senders to "Keep spam rates reported in Postmaster Tools below 0.10% and avoid ever reaching a spam rate of 0.30% or higher." Read that page carefully: 0.10% is the monitoring guidance, while the stated requirement — listed under Requirements for all senders, which apply to anyone sending to personal Gmail accounts, and repeated in the section for senders of 5,000 or more messages a day — is to "Keep spam rates reported in Postmaster Tools below 0.3%." When one tenant on a shared IP pushes the pool toward those numbers, the filtering that follows is applied to the IP. It is not applied to the tenant who caused it. Everyone else’s password resets can start landing in spam.

Postmark opens its acceptable use section by describing exactly this dependency:

Email Service Providers (ESPs) like Postmark are unique in that we are only as good as the reputation and sending practices of our customers. A single bad actor can take down a good portion of an ESP’s reputation, but it takes everyone as a whole to create an exceptional reputation over time.

Postmark Terms of Service, Section 5 (Acceptable Use Policy), effective 10 December 2024

What do the acceptable use policies actually say?

Here is the operative language from five providers, quoted from their own pages as they stood in September 2026. Dates are the last-revised dates each policy carries.

Resend’s is the only one of the five that uses the phrase "cold outreach" outright, which removes any argument about interpretation. It sits under the heading Prohibited Sending Purposes, first item, labelled Spamming.

Twilio’s policy goes on to anticipate the workarounds. Alongside the purchased-list clause it separately prohibits "Sending emails to email addresses that you obtained from the Internet or social media or to generic email aliases (e.g., webmaster@domain.com or info@domain.com) without obtaining prior affirmative consent" — which covers scraping and the info@ blast in one line. It then names the evasion tactics, defining snowshoeing as "sending spam emails across multiple domains or IP addresses to dilute reputation metrics and evade filters". Rotating domains is not a loophole; it is a specifically enumerated violation.

Mailgun extends the rule past sending into verification. Section 5 forbids using the service to "validate email addresses that were purchased, rented or similarly obtained from a third party", and to "harvest or generate email addresses or otherwise determine the existence of unknown email addresses". Cleaning a scraped list on the platform is treated the same as mailing it.

Is the consequence a warning, or termination?

Both exist. What matters is that the numeric thresholds are low and several policies explicitly reserve the right to skip the warning.

Take the arithmetic seriously. A 0.08% complaint ceiling is eight complaints in ten thousand messages. On a two-thousand-address list, two people pressing "report spam" puts you at 0.1% — over the line at every provider in that table. At least some of this enforcement runs without a human in the loop: Amazon’s wording is that "If your complaint rate is 0.1% or greater, we automatically place your account under review." The other four do not describe their mechanism. Either way, the question is not whether someone at the provider finds your campaign objectionable. It is whether a rate crosses a threshold.

Amazon is unusually direct about who the enforcement is for:

In many cases, when we detect an issue with an account, we place that account under review. In other cases, we pause the account’s ability to send email. We take these actions to protect each account’s sender reputation, and to prevent other SES users from experiencing service interruptions and deliverability issues.

Amazon SES Sending review process FAQs

Cold lists sit badly against those thresholds by construction. The recipient has no prior relationship with the sender, so a "report spam" click is a reasonable thing for them to do, and addresses gathered without consent bounce more often than addresses someone typed into a form. How much worse depends entirely on the list, and any multiplier quoted without a methodology is worth ignoring.

Is cold email illegal, or just against the rules?

Different questions, and the distinction matters. In the United States, CAN-SPAM is an opt-out regime rather than an opt-in one. The FTC’s compliance guide lists the requirements — accurate header information, a non-deceptive subject line, clear disclosure that the message is an advertisement, a valid physical postal address, and a clear opt-out honoured within 10 business days — and prior consent is not among them. The same guide notes that "Each separate email in violation of the CAN-SPAM Act is subject to penalties of up to $53,088".

So a cold email carrying a real postal address and a working unsubscribe can be lawful under US federal law and still be a breach of contract with your ESP. The acceptable use policy is deliberately stricter than the statute, because the provider is protecting a shared asset the statute knows nothing about. Elsewhere the default can invert. UK guidance from the Information Commissioner’s Office summarises the position under PECR as "You must not send marketing emails or texts to individuals without specific consent", with a limited soft opt-in for your own previous customers, while "You can send marketing emails or texts to companies." Which of your recipients count as individuals rather than companies is one of the questions that decides whether a campaign is lawful there, and other jurisdictions differ again.

What can you use instead?

Two approaches are consistent with the policies above. They suit very different volumes.

Send from your own mailbox, through the provider’s API

Microsoft 365 and Google Workspace both expose a send-only API on the mailbox you already own. In Microsoft Graph the action is sendMail, and the reference lists Mail.Send as the least privileged delegated permission for it. A successful call returns 202 Accepted.

POST https://graph.microsoft.com/v1.0/me/sendMail
Authorization: Bearer {token}
Content-type: application/json

{
  "message": {
    "subject": "Meet for lunch?",
    "body": { "contentType": "Text", "content": "The new cafeteria is open." },
    "toRecipients": [ { "emailAddress": { "address": "frannis@contoso.com" } } ]
  },
  "saveToSentItems": "false"
}

HTTP/1.1 202 Accepted

Gmail is the same idea: POST to https://gmail.googleapis.com/gmail/v1/users/me/messages/send, and gmail.send is the narrowest of the four scopes Google lists as sufficient for that method. Mail sent either way leaves from Microsoft’s or Google’s own outbound infrastructure, authenticated as your tenant, at your own volume, under your own domain reputation. There is no shared-ESP acceptable use policy in the path because there is no shared ESP in the path. You are using your mail system for mail.

The ceiling is what keeps this honest. Microsoft’s own reference notes that a 202 does not mean delivered and that "Delivery of the message is subject to Exchange Online limitations and throttling". A mailbox is not a mass-mail channel, and treating it as one produces the same complaint rates that get accounts terminated elsewhere, only now it is your tenant. Decknative is built on this model — the customer connects their own Microsoft 365 or Google mailbox with send-only scope, a person approves every draft, and sends go out at mailbox pace under a per-day cap.

Run infrastructure you own and warm yourself

The other option is a mail server on IP addresses under your control, warmed by you and monitored by you. Two honest caveats. First, a dedicated IP bought as an add-on from a shared platform is not an exemption from that platform’s policy: nothing in the Resend, Postmark, Mailgun or Twilio text quoted above is scoped to shared IPs, and all of it governs use of the service. Second, dedicated IPs punish irregular sending. Amazon’s guidance is blunt about it: "If you don’t plan to send large volumes of email on a regular and predictable basis, we recommend that you use shared IP addresses."

Genuinely separate infrastructure moves the acceptable use question to whoever leases you the IPs, and moves warm-up, blocklist monitoring, feedback-loop registration and abuse handling onto you. That is real, ongoing work, and it is the right answer at volumes where nothing else fits.

Where is the line between transactional mail and cold outbound?

This is the part that gets lost in the argument. These providers are not against email. Transactional mail to your own users is the exact thing they are built for. Twilio draws the line inside its own definition:

Except for transactional emails (i.e., non-marketing emails that contain information about an action or transaction a recipient has taken or agreed to and, if applicable, updates or notifications to that recipient about that action or transaction), you must obtain affirmative consent prior to sending any emails to a recipient via the Email Services.

Twilio Email Policy, "Affirmative Consent (“opt-in”) Requirements"

Password resets, receipts, invoices, shipping notices, security alerts, one-time codes. Send those through a transactional ESP and you are the customer the platform was designed for. Mailgun even carves the same category out of its unsubscribe requirement: "Note that transactional and confirmation emails and SMS do not require an unsubscribe link."

The split many teams land on is two systems with two reputations: transactional mail through an ESP on a subdomain used for nothing else, and outbound prospecting from real mailboxes on a separate domain. When one of them has a bad week, the other keeps working.

How do you check a provider’s policy yourself?

Policies change and this page will go stale. Checking one takes a few minutes.

1. 01Find the acceptable use policy or the email policy, not the pricing page or a support article. It is usually linked from the footer under Legal, and is normally incorporated into the contract by reference.
2. 02Search the page for: unsolicited, purchased, rented, scraped, harvest, third-party list, affirmative consent, opt-in, complaint rate. Those nine terms find the operative clauses in every policy quoted here.
3. 03Read the numeric thresholds and check them against your own list. A complaint ceiling expressed as a percentage is the clearest statement of what the provider expects.
4. 04Note the last-revised date, and note who the policy names. Postmark’s terms are now written in the name of AC PM, LLC, and Mailgun’s AUP in the name of Sinch Email — the operator behind a brand can change, and the party you are contracting with is the one in the document.
5. 05Check whether the transactional carve-out exists and how it is defined, because that definition is what decides which of your messages are covered.
6. 06If a use case is genuinely ambiguous, ask support in writing before you send. An email from the provider saying yes is worth more than any reading of the policy, including this one.

The short version: the prohibition is real, it is written down, and it is enforced by automation against thresholds a cold list crosses easily. The provider is not the obstacle. The shared pool is.