What is a spam trap email address, and can validation catch one?

You send a campaign, the open rate looks fine, and then your deliverability quietly falls off a cliff. Somewhere on that list was a spam trap — an address that exists only to catch senders who mail people who never asked. If you have been asking what is a spam trap, and whether an email validator can find one before you hit send, here is the honest answer: understand them, clean your list, and do not expect any tool to promise you a clean sweep.

Two kinds of spam trap#

A spam trap is an email address that a mailbox provider or blocklist operator monitors specifically to identify senders with poor list hygiene. Mail arriving at one is, by definition, mail nobody opted in to receive. There are two kinds, and the difference matters.

Pristine traps were never real. A provider or an anti-abuse operator (think Spamhaus, or a large mailbox provider) creates addresses that never belonged to a person, never subscribed to anything, and never sent a message. They seed them where scrapers find them — buried in page source, in old records, on pages no human reads. The only way one lands on your list is if you scraped, bought, or guessed it. There is no legitimate path to a pristine trap.

Recycled traps were once real. Someone owned the address, used it, then abandoned it. After a long dormancy the provider stops bouncing mail to it and reactivates it as a trap. Anyone still mailing that address is, by construction, mailing someone who stopped engaging years ago and never came back.

Why one trap does so much damage#

Traps are leverage, not volume. Mailbox providers and blocklists treat a trap hit as strong evidence that you are not mailing people who asked for it. A handful can be enough to drag your sender reputation down, route your mail to spam folders, or land your sending domain or IP on a blocklist. The cost is not the one wasted send; it is every legitimate subscriber whose inbox you stop reaching afterward.

Why no validator can promise to catch them#

Here is the part most vendors skip. A pristine trap is a perfectly valid, deliverable-looking address. Correct syntax. Live MX records. Not disposable. Not a role account. It passes every structural check because, structurally, nothing is wrong with it — the address is real; it just belongs to a trap instead of a person. There is no field in a validation response that separates "real inbox owned by a customer" from "real inbox owned by a blocklist operator." Anyone selling you guaranteed spam-trap detection is selling you a guess dressed as a fact.

Boundstone does not claim spam-trap detection, and it will not add a spam_trap field it cannot stand behind. The email check reports exactly what it did and what it did not do:

{
  "valid_syntax": true,
  "domain": "example.com",
  "mx_found": true,
  "disposable": false,
  "role_account": false,
  "free_provider": false,
  "checks": {
    "performed": ["syntax", "mx", "disposable_list", "role_list"],
    "not_performed": ["smtp_mailbox", "catch_all"]
  }
}

smtp_mailbox and catch_all sit in not_performed on purpose — Boundstone does not open SMTP connections or probe catch-all domains, so it does not pretend to. Spam-trap detection appears on neither list, because it is not something an honest validator can offer.

What list cleaning actually does#

Cleaning helps with recycled traps, indirectly, and it is worth doing. Recycled traps begin life as ordinary addresses that go quiet — the same population as your dead weight and your typos. When you remove addresses that fail structural checks and re-verify a list you have not mailed in months, you shrink the pool of long-dormant addresses that recycled traps emerge from. You will not catch a specific trap; you will shrink the neighborhood it lives in.

Structural validation flags the obvious problems: broken syntax, domains with no MX record, disposable domains, and role accounts like info@ and sales@ that tend to attract complaints. That is genuinely most of what a bounce problem is made of — see reducing your email bounce rate for the fuller picture, and validation vs verification for where the line actually sits. For pristine traps the only real defense is upstream: confirmed opt-in, no purchased or scraped lists, and re-engagement before you mail a cold segment.

A quick check before you send#

Run a single address through the free email validator with no signup, or call the API over a list. The bs_live_ key is a server-side secret, so make this call from your backend, never from browser or client code:

curl https://api.boundstone.io/v1/verify/email \
  -H "Authorization: Bearer bs_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email":"you@example.com"}'

Read the checks object, not just the top-level flags. It tells you what a "valid" here means — structure and deliverability signals, and nothing about who is behind the address.

The short version#

• A spam trap is an address monitored to catch senders with poor list hygiene. Pristine traps were never real; recycled traps were real, then abandoned and reactivated.
• One hit can damage sender reputation and get you blocklisted, so the cost far outweighs the single send.
• No validator can reliably identify a live spam trap — a pristine one looks exactly like a good address.
• Cleaning invalid and long-dead addresses lowers your recycled-trap risk indirectly. It does not detect traps, and nobody's does.
• Boundstone checks syntax, MX, disposable, and role, and lists what it did not check. It does not claim spam-trap detection — and the not_performed list is how you know.