You do not hunt spam traps

by Francis Rozange | Sep 8, 2026 | Email Marketing

Abstract 3D render: an almost invisible line of light across a dark corridor, particles caught on it

One day your messages stop arriving. You investigate, and you find your IP address listed by Spamhaus. The reason is two words: spam trap.

The immediate reaction is always the same: identify the traps in order to remove them from the list.

That is exactly what Spamhaus asks you not to do.

The trap is not the problem

The body’s position is published, and it is unambiguous: you should “view spamtraps as proof of a data collection or hygiene issue and not be misled into conducting a hunt for spamtraps”.

The reasoning is mechanical. A trap address has never been given to anyone: it appears on no form, subscribes to nothing, clicks nowhere. If it is in your database, it can only have got there one way, and Spamhaus names it: “the sender is either scraping addresses from the web or is buying lists from someone else who is scraping addresses”.

The trap is therefore not bad luck. It is a revealer, and it reveals one precise thing: an address entered your database without anyone putting it there.

Removing detected traps fixes nothing. It removes the witness and leaves the door open, and the door rarely closes by itself.

What the four lists actually are

The word “blacklist” covers very different mechanisms, and knowing which one listed you directs the fix.

The SBL targets IP addresses for snowshoe spam, hosting of resources used by spammers, spam support services, and security threats. It is the most editorial of the four.

The XBL is entirely automatic. It lists an address when Spamhaus has convincing evidence that the machine, or a device behind it, is compromised or infected. An XBL does not accuse your marketing: it flags a machine to clean.

The PBL lists ranges that should not send directly to the internet, typically residential and dynamic ranges. It is fed by Spamhaus and by the network operators themselves. Removing an individual address requires three simultaneous conditions: an active mail server on that address, correctly configured forward and reverse DNS, and outbound port 25 closed for any other use.

The DBL covers domains. Its criteria are not disclosed, it is highly automated, and most listings expire by themselves once the activity that caused them stops.

One point applies to all four, and bears repeating every time: “There is never any charge or fee associated with removing any Spamhaus listing. Any offer from anyone to remove any Spamhaus listing for a fee is a scam.”

Bounces, and the threshold that warns

Traps are the visible accident. Bounces are the continuous signal, and they can be read before the accident.

M3AAWG recommends removing addresses that fail repeatedly, with a quantified test: at least twice, over two weeks or more, across consecutive campaigns. In an older document on complaint handling, the body indicates that a hard bounce rate above 5 percent signals a list-building problem.

Five percent of addresses that do not exist means a database that was not collected where you think it was.

Note in passing a signal going dark: as of 22 July 2026, Microsoft no longer publishes trap hit counts in its network data service. The honest sender loses an indicator there, and will have to rely on their own bounces.

Prevention, as the bodies describe it

M3AAWG is explicit about when the problem gets fixed: “The best practice is to validate the email address as it is entered, and to prompt the subscriber to re-enter their address if validation fails.”

At entry. Not at send time, not six months later during a big clean-up.

Spamhaus goes further, and the passage deserves quoting out of honesty, because it inconveniences an entire industry, ours included: “There is no need to pay for expensive third-party services to clean data because the initial data is already clean”, provided collection uses double opt-in and bounces are removed promptly.

The sentence is right, and it has a precise scope: it concerns data you collected yourself. Repeatedly cleaning a file you should have collected properly is spending that replaces work.

Verification keeps its own proper domain, and it is twofold. At entry first, to avoid the typo that creates a dead address or, worse, one that lands with somebody else. On data you did not collect second, for example business contacts from a database: there, no internal collection rule protects you, and the address’s real existence must be established before sending.

That is what Sestaro’s verification does: syntax and domain checks, a live SMTP probe to confirm the mailbox exists, a second opinion from a different IP address for undecided cases, and a refund of the credit when the address turns out to be dead.

What to do tomorrow morning

Pull the hard bounce rate of your last six sends. If it exceeds 5 percent, you do not have a cleaning problem, you have an address origin problem, and you need to go back to the source of collection.

Then check your removal rule: do hard-bouncing addresses leave automatically, or do they wait for a human decision that never comes?

Finally, find out where the oldest segments of your database came from. The ones nobody can name the origin of are the ones carrying the traps, and they are also the ones the three-year rule required you to have deleted long ago.

In almost every case, compliance and deliverability ask you for the same thing. That is rare enough that we should stop handling them in two separate meetings.

Sources

LaFactory works email on the evidence: headers, DNS records, rejection logs. No open rate promises, ever. Get in touch for a deliverability audit.