Spam traps are addresses that never belonged on your list. The types, who operates them, how they end up in your database, and the hygiene that keeps them out.
A spam trap is an email address whose only job is to receive mail it never asked for. No human reads it, no signup form legitimately produced it, and every message it receives is evidence about the sender. Blocklist operators and mailbox providers run millions of them, and a handful of trap hits can put an otherwise legitimate sender on a blocklist. Understanding how traps work explains most of the hygiene rules this publication keeps repeating.
The three families of traps
Pristine traps
Pristine traps are created as traps. Operators publish them invisibly on websites for scrapers to harvest, seed them into circulated lists, or simply create them on domains they control. Because the address never subscribed to anything, receiving any commercial mail at one is proof of harvesting, list purchase, or a compromised data source. Blocklist operators weight pristine hits most heavily for exactly that reason.
Recycled traps
Recycled traps are former real mailboxes. The provider closes an abandoned account, returns unknown-user bounces for an extended period, often a year or more, and then quietly reactivates the address as a trap. Any sender still mailing it after that window either ignores bounces or has not mailed the address in so long that they never saw them. Both are hygiene failures, which is what a recycled hit signals.
Typo traps
Typo traps live on lookalike domains: gamil.com, hotnail.com, yaho.com. Users mistype their address at signup, the form accepts it, and the welcome series starts mailing a trap operator. Typo hits indict the signup flow rather than the list source, and they are the family most directly eliminated by confirmed opt-in, since the confirmation mail goes to the mistyped address and no human ever clicks it.
Who runs traps and what a hit costs
Spamhaus runs the best-known trap network, feeding the SBL and the data behind its reputation products. Microsoft operates traps and reports per-IP hit counts in SNDS, one of the only places a sender ever sees trap data directly. Beyond those, security vendors, smaller blocklists like UCEPROTECT, and independent researchers all run networks of varying quality.
The cost of a hit depends on the operator and the trap family. Repeated pristine hits at Spamhaus can produce an SBL or CSS listing that blocks delivery at every provider consuming their data. Recycled hits typically degrade reputation scores rather than trigger immediate listings. Aggressive lists like UCEPROTECT escalate quickly but carry less weight with major providers. In every case the operational response is the same: stop the leak, then remediate the listing.
How clean senders end up hitting traps
Most trap incidents at legitimate companies trace to one of a few doors. An acquisition partner or lead vendor supplies addresses that were never confirmed. A legacy list gets reactivated for a one-off campaign after years of dormancy, mailing straight into the recycled-trap window. A signup form without confirmation accumulates typos and bot submissions. Or an old segment escapes the sunset policy through a CRM sync that resurrects suppressed records.
The pattern across all four is absence of confirmation plus absence of recency discipline. Traps are not clever adversaries; they are passive sensors that only detect senders who mail addresses without evidence a human currently wants the mail.
What actually protects you
Trap-proofing checklist
- Confirmed (double) opt-in on every acquisition path, no exceptions for partners or imports
- Immediate, permanent suppression on unknown-user bounces
- Engagement sunset policy that stops mail to the chronically silent
- No reactivation of segments older than the recycled-trap window without a re-permission pass
- SNDS registered and trap counts alerted on any non-zero value
- Acquisition sources tagged in the database so a trap incident can be traced to its door
Note what is absent from that list: list cleaning services as a cure. Validation vendors catch syntax errors, dead domains, and some known-bad addresses, and they are useful at the point of collection. But trap operators do not publish their addresses, and a service that claimed to identify pristine traps reliably would be describing a data leak, not a product. Running a purchased list through a cleaner does not make it safe; it makes it a cleaned purchased list.
If you are hitting traps now
Trap incident response
- 1
Stop the affected streams
Pause sends from the implicated IPs or segments. Every additional hit deepens the listing you are about to remediate.
- 2
Identify the cohort
Cross-reference SNDS hit dates or the blocklist evidence with campaign logs. Narrow to the segments and acquisition sources mailed in that window.
- 3
Quarantine, do not cleanse
Suppress the suspect cohort entirely. Attempting to surgically remove traps from a bad source is guesswork; the source is the problem.
- 4
Fix the door
Whatever admitted the addresses, an unconfirmed form, a vendor, a resurrection bug, gets fixed before volume resumes.
- 5
Then remediate listings
Approach Spamhaus or other operators only after the leak is closed. Delisting requests that precede the fix get denied and burn credibility.
Frequently Asked Questions
Can I find out which address is the trap?
How long until an abandoned address becomes a recycled trap?
Do trap hits explain a sudden Gmail placement drop?
Is one trap hit an emergency?
Spam traps reward the sender who needs no defense against them. Confirm every signup, bounce out the dead, sunset the silent, and never resurrect the ancient, and trap networks become an abstraction that happens to other people's lists.
Key Takeaways
- Pristine traps never belonged to anyone; hitting one means your acquisition process ingests addresses nobody submitted
- Recycled traps are abandoned mailboxes reactivated as traps; hitting one means you mail addresses that stopped responding long ago
- Typo traps catch unconfirmed signups like gamil.com domains, which double opt-in would have filtered
- Traps cannot be identified or removed from a list; validation services do not reliably detect them
- SNDS trap counts and sudden Spamhaus listings are usually your first evidence
Related articles
Building a Deliverability Monitoring Stack
Postmaster Tools, SNDS, FBLs, DMARC reports, TLS-RPT, bounce logs, engagement data: the full observability stack, what each layer catches, and the alerts worth paging on.
Q4 Peak Sending: Ramping Volume Without Triggering Filters
Between Black Friday and year end, send volumes triple while filters tighten. How to ramp into peak season so November's volume looks like growth, not an incident.
Email Validation Services: What They Can and Cannot Do
Validation APIs verify syntax, domains, and mailbox existence. Where each check works, where catch-alls and traps defeat them, and where validation belongs in your stack.