ESP Blacklist Issues: AWS SES, SendGrid, and Mailgun Reputation Problems

Using an email service provider (ESP) like AWS SES, SendGrid, or Mailgun is supposed to make deliverability someone else's problem. Most of the time it does. But shared infrastructure cuts both ways: when another customer on your IP pool misbehaves, your mail can land in junk, bounce, or get blocked outright.

Here is how shared pools actually work, what to look for when something goes wrong, and how to get unstuck on each of the big three ESPs.

How Shared IP Pools Work at Major ESPs

When you send through an ESP on a standard plan, your mail goes out from a pool of IP addresses shared with dozens or hundreds of other senders. The ESP assigns outbound IPs based on factors like your sending volume, destination mailbox provider, content classification, and historical reputation.

ESPs segment pools to isolate risk. AWS SES, for example, routes transactional mail through different ranges than marketing mail. SendGrid has separate pools for free accounts, paid shared users, and dedicated IP customers. Mailgun does the same and also splits pools by region.

Segmentation helps, but it does not eliminate risk. If one sender in your pool blasts a dirty list or triggers a spam trap, the IP they used can end up on Spamhaus, SORBS, or a mailbox provider's internal blocklist. If the ESP was routing your mail through that same IP when the listing happened, your delivery suffers too.

Why ESP IPs Get Blacklisted

The usual suspects:

• A noisy neighbor on a shared pool. Another customer sends to a purchased list or hits spam traps.
• Compromised accounts. An attacker gets ESP API keys and uses them to send phishing.
• Sudden volume spikes. A legitimate sender ramps too fast without warming, and the pool catches reputation damage.
• Content-based listings. Some blocklists flag IPs based on URLs or attachments seen in outbound mail.
• Feedback loop complaints. High complaint rates from Yahoo, AOL, or Microsoft trigger listings at the mailbox provider level even when public DNSBLs stay clean.

Diagnosing ESP-Related Delivery Problems

Before you blame the ESP, confirm the problem is actually on their side.

Step 1: Identify which IP sent the message

Look at the Received headers on a failed or junked message. You will see the outbound IP the ESP used. That is the IP you need to investigate, not your ESP's website or control panel IP.

Step 2: Check that IP against blacklists

Run it through a multi-blocklist scanner. Spamhaus ZEN, Barracuda, and SpamCop are the ones that matter most for inbox placement. See /resources/email-blacklist-monitoring for a list of the lists worth tracking.

Step 3: Check authentication

SPF, DKIM, and DMARC must all align. A blacklist listing is only one cause of delivery trouble; broken auth looks similar from the outside. Pull the raw headers and verify each check passed.

Step 4: Read the bounce message

ESPs surface SMTP-level rejection codes. A 550 5.7.1 from Google with a URL pointing to postmaster.google.com is a reputation issue at Google, not a public blocklist. A 521 5.2.1 referencing Spamhaus is a DNSBL hit. Treat them differently.

For the deeper background on how mailbox providers score senders, read /guides/ip-domain-reputation and /resources/ip-reputation-explained.

AWS SES: Sandbox and the Reputation Dashboard

New SES accounts start in the sandbox: you can only send to verified addresses, and your daily quota is tiny. Getting out requires a production access request where AWS reviews your use case. Skip this step and you will think SES is blacklisting you when it is really just holding you in the sandbox.

Once you are in production, your primary diagnostic tool is the SES reputation dashboard under Account dashboard. It tracks two metrics AWS cares about:

• Bounce rate. Anything above 5% puts your account under review. Above 10% and AWS will pause sending.
• Complaint rate. Target under 0.1%. Above 0.5% triggers review.

If either metric climbs, AWS sends warnings before they act. Do not ignore them. Investigate the list you sent to, pull addresses that generated complaints, and clean them before sending again.

SES also exposes virtual deliverability manager on some accounts, which gives per-ISP placement data. Use it to see whether the problem is specific to Gmail, Outlook, or Yahoo rather than universal.

SendGrid: IP Warmup and Reputation

SendGrid ties deliverability closely to the reputation score on its dashboard. The score is based on bounces, blocks, spam reports, and invalid sends over the last 30 days. Drop below 80 and you should pause and investigate.

If you are on a shared pool and getting junked, the first question SendGrid support will ask is your reputation score. If it is healthy, they will move you to a cleaner IP range. If it is not, they will tell you to fix your sending practices.

For anything beyond low marketing volume, SendGrid strongly recommends a dedicated IP with automated warmup. The warmup feature throttles sends over 30 days to build reputation gradually. Skipping warmup on a brand new dedicated IP is the most common self-inflicted SendGrid problem.

Mailgun: Deliverability Tools and Pools

Mailgun separates its shared pool into sending tiers and offers a deliverability dashboard that shows inbox, spam, and missing placement by mailbox provider. It pulls seed-list data so you can see what Gmail and Outlook are actually doing with your mail, not just whether it was accepted.

Mailgun's logs are the best in the business. Every event (accepted, delivered, opened, failed) is queryable for days. When a recipient complains, pull the log, find the exact payload, and you can usually spot the problem in minutes. Pair it with their email validation API to clean lists before you send.

For dedicated IPs, Mailgun requires sustained volume (typically 100k+ per month) to justify the cost and keep the IP warm.

When to Use a Dedicated IP

A dedicated IP only helps if you send enough to maintain reputation. Rough rule: 50,000+ emails per month, consistently. Below that, your IP looks idle to mailbox providers, and idle IPs lose trust. You are better off on a well-managed shared pool. Read /resources/what-is-a-clean-ip for the reputation mechanics.

If you are above the threshold and growing, a dedicated IP gives you control. Nobody else can drag your reputation down, but nobody else will prop it up either. Warm it properly, follow the guidance in /resources/bulk-email-without-getting-blacklisted, and monitor daily.

When to Switch ESPs

Switching ESPs is not a fix for bad sending practices. It is a reset button that can buy you one clean start. Use it only after:

1. You have cleaned your list and removed everything that bounced or complained.
2. You have fixed SPF, DKIM, and DMARC.
3. You understand why the old ESP's reputation went bad so you do not recreate it.

If you check all three boxes and the old ESP still refuses to move you to a cleaner pool, switching is reasonable. Otherwise you are just moving the problem.