← Blog/Deliverability

ESP blocks vs blacklists: different problem, different fix

October 15, 2026·6 min read·By MailPilot

Two different systems, one similar symptom

When mail stops arriving, it's tempting to treat "blocked" as a single problem with a single fix. In practice, a mailbox provider (ESP) block - Gmail or Microsoft 365 deciding not to deliver your mail, based on their own internal reputation scoring - and a third-party blacklist listing - an independent organisation like Spamhaus or Validity flagging your IP or domain as a published spam source - are different mechanisms, detected through different tools, with different remedies.

How ESP blocks work

Mailbox providers maintain their own internal reputation scoring for every sending domain and IP they see, based on signals including spam complaint rate, engagement, authentication results, and sending pattern. When that internal score drops low enough, the provider blocks or heavily filters mail from that source - this decision is entirely internal to the provider and isn't published anywhere you can look up directly. You usually find out through bounce messages referencing the provider's own block reason, or through a tool like Google Postmaster Tools or Microsoft's SNDS that exposes some of that provider's internal signal.

How blacklist listings work

A blacklist (or "DNSBL") is maintained by an independent third party - not the mailbox provider itself - that monitors spam traps, honeypots, and complaint feeds across the internet and publishes a list of IPs or domains it has identified as spam sources. Mailbox providers and spam filters can choose to consult these lists as one input into their own filtering decisions, but a blacklist listing doesn't directly block mail on its own - it's a signal providers can use, with varying weight, with their own filtering systems. You check blacklist status directly against the specific list's own lookup tool, since there's no single central blacklist.

The practical difference in diagnosis and fix

ESP blockBlacklist listing
Who maintains itThe mailbox provider itself (Gmail, Microsoft, etc.)An independent third party (Spamhaus, Validity, etc.)
How you detect itBounce message reason codes, Postmaster Tools, SNDSDirect lookup against that specific blacklist's tool
ScopeSpecific to that one providerCan affect any provider that consults that list
Typical fixFix the underlying reputation cause (complaints, engagement, pattern); wait for internal score to recoverFix the cause, then actively request delisting through that list's own process
Recovery speedGradual, tied to sustained clean sendingCan be faster once delisted, but recovery from the underlying cause still takes time

Why this matters practically

If you're blocked at Gmail specifically and spend time checking Spamhaus, Validity's Heatwave, and other blacklists, you may find nothing - because the problem is Gmail's own internal scoring, not a published blacklist listing at all. Conversely, treating a blacklist listing as something that will resolve on its own, the way an ESP's internal score gradually recovers, misses that most blacklists require an active delisting request once the underlying cause is fixed.

A third category: real-time content and behaviour filtering

Beyond standing ESP-side reputation scores and third-party blocklists, some filtering decisions happen in real time against the specific content and behaviour of an individual message or sending burst, rather than against an accumulated reputation history - a message that trips a real-time content heuristic can get filtered even from a sender with an otherwise clean reputation and no blocklist listing anywhere. This is harder to diagnose because it doesn't show up in Postmaster Tools, SNDS, or any blocklist lookup - the clearest evidence is usually a specific message or campaign getting filtered while the sender's broader metrics look unaffected.

If you've ruled out both an ESP-side reputation problem and a blacklist listing but a specific send still isn't landing, consider the message's own content and structure as a distinct, third possibility, and test a structurally different version of that specific message through a seed-list check before assuming the cause must be reputation-related. Keep a simple internal log of past delivery incidents and which of these three categories - ESP-side reputation, third-party blocklist, or real-time content filtering - turned out to be the actual cause each time, since patterns in your own history often narrow down the likely cause faster than starting the diagnosis fresh every time.

What not to do

Do not assume a blacklist delisting automatically restores placement at every provider - some providers weight that specific list heavily, others barely consult it, and an ESP's own internal score may still need to recover separately. Do not skip checking a provider's own tools (Postmaster Tools, SNDS) because "the blacklists are clean" - an ESP block can exist entirely independent of any published blacklist. Do not assume one blacklist's clean result means you're clear of all of them; check the specific lists relevant to your sending.

MailPilot tracks per-mailbox bounce, complaint, and inbox placement signals that reflect ESP-side reputation directly, which helps distinguish an internal provider block from a separate blacklist issue when mail stops arriving somewhere specific.

MailPilot

Ready to reach the inbox every time?

Automated email warmup across real peer mailboxes. Live inbox placement monitoring. Free 7-day trial - no credit card required.

Start free trial
Reach the Inbox, Every Time
Connect unlimited inboxes for warmup. Free 7-day trial, no credit card.
Try for Free
WORKS WITH
OZOHO
inbox placement99.2%
free trial7-day
companies trust us340+

Start for free - no credit card required.

Get started freeBook a demo