Skip to content
← BlogDeliverability7 min read

How a sending domain actually ends up on a blocklist

Not a single bad email. Blocklisting is almost always one of four repeatable triggers: trap hits, complaint-rate crossings, volume anomalies, or borrowed reputation.

By Norbelys Chirinos, Co-founder

Founder-reviewed ·How we research and correct articles

Most senders picture blocklisting as bad luck — one wrong click, one flagged email, gone. It isn’t. Blocklists are pattern detectors, and the patterns they’re tuned for repeat the same handful of ways, over and over, across a wildly different set of senders. If you know the four actual triggers, you can see a listing coming days before your reply rate tells you something’s wrong.

Trigger one: you hit a spam trap

A spam trap is an email address that receives no legitimate use and exists specifically to catch senders who aren’t being careful about their list. There are two flavors, and they behave very differently.

A pristine trap was never a real inbox. It was planted — quietly seeded into a web page, a scraped directory, or a purchased list precisely so that anyone harvesting or buying addresses in bulk would eventually mail it. Nobody legitimately “acquires” a pristine trap through normal prospecting; landing on one is close to proof that a list came from scraping or a purchased database rather than research. That’s why hitting even a single pristine trap can trigger an immediate, severe reputation hit — Mailgun’s own deliverability documentation describes this as one of the fastest paths to a listing, precisely because there’s no benign explanation for how you got the address.

A recycled trap used to be a real inbox. Someone had it, stopped checking it, the domain eventually reclaimed it, and after a dormancy window — commonly six to twelve months of watching it bounce — a mailbox provider or blocklist operator quietly turns it back on as a trap. This is the one that punishes neglect rather than malice: a list you built honestly a year ago, never cleaned, now contains a handful of addresses that have become traps without changing owners in your CRM.

Trigger two: your complaint rate crosses a public threshold

This is the trigger with an actual published number attached to it. Google’s sender guidelines set 0.3% as the hard ceiling for spam complaints on bulk mail — cross it and you lose delivery protections — and recommend staying under 0.1% as a safety margin, as documented in Google’s own guidelines. That’s one complaint per roughly 300 to 1,000 emails sent, tracked inside Google Postmaster Tools and equivalent systems at other large providers.

The mechanism matters here: a complaint is the recipient clicking “report spam,” not a bounce, not a soft no, not silence. It’s the strongest negative signal a mailbox provider gets, because it comes from the human who actually looked at the message. Complaint rate crossing the threshold doesn’t get you blocklisted by a third-party operator directly — but it gets you throttled and filtered by the provider itself, and providers routinely feed sustained complaint data into the same blocklist ecosystem that flags you everywhere else.

Trigger three: your sending pattern looks like an anomaly

Reputation systems build a baseline for what “normal” looks like for a given domain or IP — typical daily volume, typical bounce rate, typical send times. A sudden departure from that baseline reads as a signal on its own, independent of content:

What counts as an anomaly, specifically

  1. A volume spike

    Jumping from 200 sends a day to 4,000 overnight looks identical to a compromised account or a rented list being burned through fast, whether or not that's what happened.

  2. A bounce-rate spike

    A double-digit bounce rate on a single send — commonly cited around 15% or higher — is treated as evidence of a stale or purchased list, and triggers throttling on its own before complaints even register.

  3. Off-pattern timing

    Mail sent in a burst at 3 a.m. from a domain that normally sends during business hours doesn't prove anything by itself, but it's one more input into an automated score.

  4. Authentication drift

    SPF or DKIM suddenly failing on a domain that previously passed cleanly reads as either a misconfiguration or a spoofing attempt — either way, providers treat it as risk until it's resolved.

None of these alone is usually fatal. Stacked together — new domain, volume spike, no warmup, a purchased list with 12% bounces — they compound into exactly the profile a blocklist operator is built to catch.

Trigger four: you inherit someone else’s reputation

This is the one senders have the least visibility into. Shared sending infrastructure — a shared IP pool, a shared subdomain, a badly configured open relay somewhere upstream — means your mail can be judged partly on traffic you never sent. If another tenant on the same shared IP is sloppy, their complaint rate and trap hits can drag down deliverability for everyone sharing that resource, and in the worst cases, the IP itself lands on a blocklist regardless of your own individual sending discipline.

The same logic applies to compromised accounts: a mailbox with weak credentials that gets taken over and used to blast spam poisons that domain’s reputation immediately, often before the legitimate owner even notices the account was breached.

This is also why a listing can feel wildly disproportionate to what an individual sender actually did — a domain with perfect list hygiene and a careful ramp can still get caught in a shared-IP listing triggered entirely by another customer of the same infrastructure. It’s one of the strongest arguments for sending infrastructure where reputation is isolated per sender rather than pooled across an entire shared block, since pooled reputation means you’re only ever as clean as the worst account sharing your resources.

How fast a listing actually happens

There’s no waiting period once a trigger fires. A pristine trap hit can result in a listing within hours, since it requires no accumulation of evidence — a single event is enough. Complaint-rate and volume-anomaly triggers are slightly slower because they depend on a pattern forming over a batch of sends, typically visible within a day or two of a bad campaign going out, not weeks later. That speed is exactly why reactive monitoring — checking a blocklist status after reply rates have already cratered — is consistently too late to prevent the damage; the useful window is before the trigger fires, not after.

Common questions about getting blocklisted

Can one bad email really get an entire domain blocklisted?

Yes, specifically in the pristine-trap case — because there's no legitimate way to have obtained that address, a single hit can be treated as strong evidence on its own, independent of everything else on the list.

Does a small sending volume protect against blocklisting?

It reduces exposure but doesn't eliminate it — complaint rate and trap hits are measured as a percentage or as absolute triggers, not scaled purely by size, so a small but careless list can still cross a threshold.

If my domain gets listed, does starting a new domain fix it?

It can reset the specific listing, but it doesn't fix the underlying cause — a fresh domain with the same list-hygiene or volume habits that caused the first listing will usually repeat the pattern, just on a delay while the new domain builds initial history.

What actually protects you

None of these four triggers are exotic. They’re the predictable output of list hygiene, ramp discipline, infrastructure isolation, and credential security — which is exactly why they’re preventable rather than just survivable after the fact.

Norbelys builds against all four directly instead of leaving them to manual discipline. Suppression lists permanently retire hard bounces and unsubscribes so a stale address never gets a second chance to become a recycled trap. Every new sender goes through a warmup ramp instead of a volume spike on day one. DMARC monitoring surfaces authentication drift before it becomes a spoofing complaint, and dashboard-visible spam-rate tracking means you see a complaint-rate climb the same week it happens, not the week your open rate quietly collapses.

If you’re currently piecing this together across a spreadsheet, a separate warmup tool, and whatever your ESP happens to expose, see what a single system for domain health, suppression, and warmup looks like on Norbelys pricing — every plan includes warmup and DMARC monitoring, not just the enterprise tier. Start sending from a protected domain instead of finding out about a listing from a dead reply rate.