A spam trap is an email address that belongs to nobody. It accepts mail, never replies, has never subscribed to anything, and exists only to record who sent to it. Mailbox providers, blocklist operators and anti-abuse organisations plant such addresses, or quietly reopen abandoned ones, because consent cannot be audited from the receiving end. A receiving server cannot inspect a sender's opt-in records. It can observe that a message arrived at an address no human being could have used to sign up, and treat that as evidence about every other address on the same list.

How a trap works inside the mail flow

The mechanism sits at the SMTP transaction, before any content filter runs. An address is either published where a harvesting robot will find it or reclaimed from a user who abandoned it. When a message arrives, the receiving server answers with a 250 acceptance rather than a 550 rejection, and the sending platform logs a successful delivery. No bounce is generated, no complaint arrives through a feedback loop, no unsubscribe is requested, no open or click is recorded.

Silence is the design: the first symptom of a trap hit is usually not an error in a campaign report but a drop in inbox placement days later. What the trap produces instead is an input to reputation data. Spamhaus publishes its Combined Spam Sources dataset as a subset of the Spamhaus Blocklist, queried at the initial connection against the connecting IP and returning the code 127.0.0.3 in the sbl.spamhaus.org or zen.spamhaus.org zones. According to Spamhaus, CSS normally holds between two and four million listings, adds 300,000 to 400,000 every 24 hours, and expires entries roughly three days after the last detection. Poor list hygiene sits among its published triggers, alongside unsolicited mail.

Trap operators never disclose which addresses are traps. Spamhaus gives two reasons: the addresses form part of the filtering method, and a sender told which address is a trap tends to suppress it rather than repair the process that delivered it.

The taxonomy, and where it disagrees with itself

Email service providers have converged on a three-part shorthand. HubSpot, Braze and Validity each describe pristinetraps, never valid addresses; recycled traps, once-real mailboxes repurposed by the provider; and typo traps at misspellings such as gmial.com.

Spamhaus, whose data underpins much of the filtering that punishes trap hits, publishes a longer list. Its February 2022 guidance separates classic or pristine traps from seeded traps, scattered where they are not obvious, such as page source code, and splits the recycled category into dead address and dead domain traps, the latter created by buying expired domains and collecting whatever arrives. Two categories have no vendor equivalent: live traps, real mailboxes whose unsolicited mail informs blocking decisions, and role addresses such as postmaster@ and abuse@, published in whois records and frequently harvested.

Dormancy periods differ by source. Spamhaus describes dead addresses as hard-bouncing for a period often running to 12 months or more before being switched back on; Cordial gives a range from 90 days to over a year depending on the provider.

Typo domain traps are the weakest signal and Spamhaus says so, describing them as not pure spam traps, noting they carry a great deal of real mail, and stating they are weighted accordingly. Its own examples include yaaho.com, ynail.com and homail.com.

Who runs the traps

Three groups operate trap networks. Blocklist operators including Spamhaus, SpamCop, Abusix and SORBS feed public and commercial reputation data. Gmail, Yahoo and Microsoft all maintain their own recycled address pools. Email service providers run internal traps to police their shared IP ranges.

Project Honey Pot represents a fourth, distributed model. Operated by Unspam Technologies and online since 2004, it asks webmasters to install a script and donate unused MX records, then issues addresses tagged to the timestamp and IP address of the visitor that collected them. When mail arrives, the operator knows the message is spam and precisely which robot harvested the address, and when. It added http:BL in 2007, returning a threat score from 0 to 255 over DNS so sites could block harvesters at the web layer.

Its billionth trapped message arrived on 9 December 2009. Estimates of the yield from a single harvest diverge: the project states 869 spam messages per harvested address, while The Register, reporting the same dataset, gave 850.

Visibility for senders is asymmetric. Microsoft's Smart Network Data Services shows a Trap hits count and a Trap message period recording the first and last trap delivery in an activity window. Google Postmaster Tools reports reputation and a spam complaint rate, but exposes no trap counter.

From blackhole lists to seeded addresses

The infrastructure that makes traps consequential predates the traps. Paul Vixie and Dave Rand founded the Mail Abuse Prevention System in 1996, and its Real-time Blackhole List became the first DNS-based blocklist in 1997. Project Honey Pot arrived in 2004, a year after the United States CAN-SPAM Act, and Mailgun dates its own recognition of Spamhaus typo traps to 2014. In September 2016 Spamhaus published guidance on subscription bombing, and from October 2016 treated unprotected subscription webforms as a systemic abuse vector, recommending CAPTCHA or equivalent protection. The General Data Protection Regulation took effect on 25 May 2018, and with it the principle Spamhaus states flatly: permission is not transferable.

Why it matters to the marketing community

The commercial consequence is disproportionate. A listing affects the sending IP or domain rather than a single campaign, so transactional mail, password resets and billing notices fail alongside the marketing programme that caused it. Senders on shared infrastructure damage their neighbours: HubSpot describes quarantining the offending segment and contacting the customer when its shared servers are listed.

Traps also police the practices that produce them. Spamhaus names three and rejects all three. Listwashing strips traps, complainers and litigators from a list that was never confirmed opt-in while retaining the rest. Waterfalling pushes an illicitly obtained list through a sequence of unwitting ESPs, cleaning bounces at each stage before the survivors go through a provider with good deliverability. E-pending, enriching a customer database with addresses sourced elsewhere, is described by M3AAWG as a direct violation of its core values, a position Spamhaus states it shares.

Regulation converges on the same terrain from another direction. The Hessian data protection authority fined an IT company 10,000 euros for emailing more than 2,700 recipients using contact data scraped from public sources. Italy's Garante gave contact database vendor Lusha 60 days to erase every Italian contact it holds, finding that anyone assembling a database from multiple origins must verify the lawful origin of each list. The scraped address that triggers a pristine trap and the one that triggers a fine are frequently the same record.

Limitations, criticism and open disputes

The most persistent dispute concerns causation. Practitioner guidance presents trap hits as the direct trigger for a blocklisting, and vendors sell trap removal on that premise. Spamhaus frames traps as confirmation of an underlying data problem rather than a listing criterion, and says services promising to strip traps, complainers and litigators do not work as advertised, because it keeps seeing mail from cleaned lists in its own traps. Neither position can be tested externally, since listing criteria are unpublished.

Opacity is the second criticism. No public register of trap addresses exists, no notification is sent outside Microsoft's SNDS, and no appeal on the merits of a hit is available.

Traps can also be weaponised. An unprotected subscription form lets a third party enter any address, including a trap, on a legitimate sender's list. Subscription bombing exploits exactly this, and the burden of the listing falls on the sender rather than the attacker.

A narrower dispute concerns whether traps interact with mail. Spamhaus addressed it in November 2023, accepting that pristine traps may click links when researchers investigate whether a message is malicious, while attributing most of the fear to the erosion of engagement metrics generally, including the effect of Apple Mail Privacy Protection on open rates.

Disambiguation

A honeypot in security research is a deliberately exposed system built to observe attacker behaviour. The terms are used interchangeably, but a spam trap observes senders rather than intruders and yields reputation data, not forensic intelligence.

A spider trap, or crawler trap, is a set of web pages designed to consume a robot's resources or hold it in a loop. It targets crawling, not sending.

A hard bounce is an explicit 5xx rejection of an invalid address. A recycled trap is the same address after it stops bouncing, which is why unprocessed bounces from a year ago are how traps enter otherwise legitimate lists.

Recent developments

The 2024 to 2025 authentication cycle changed the surrounding requirements without changing what traps measure. Google's rules for bulk senders took effect on 1 February 2024, requiring SPF, DKIM and DMARC, one-click unsubscribe, and a spam rate below 0.3 percent in Postmaster Tools. Microsoft announced comparable requirements on 2 April 2025 for domains sending more than 5,000 messages a day to Outlook.com, Hotmail.com and Live.com. Its post is inconsistent on the penalty, stating both that non-compliant mail would go to the Junk folder after 5 May 2025 and that it would be rejected with the string 550 5.7.515; dmarcian and Validity reported rejection as the operative outcome.

Authentication proves that a sender is who it claims to be. It says nothing about whether the recipient agreed to be contacted, which is the only question a spam trap asks. As of August 2026 that division of labour holds, and automated prospecting has enlarged the population of senders acquiring addresses faster than consent can be recorded.

Timeline

  • 1996: Paul Vixie and Dave Rand found the Mail Abuse Prevention System
  • 1997: The Real-time Blackhole List becomes the first DNS-based blocklist
  • 2003: The United States enacts the CAN-SPAM Act
  • 2004: Project Honey Pot goes online, distributing addresses tagged to harvester IP and timestamp
  • 2007: Project Honey Pot launches http:BL, returning threat scores from 0 to 255 over DNS
  • 9 December 2009: Project Honey Pot logs its billionth trapped spam message at 06:20 GMT
  • 2014: Spamhaus typo domain traps enter wider industry awareness
  • 16 September 2016: Spamhaus publishes guidance on subscription bombing and webform abuse
  • 25 May 2018: The General Data Protection Regulation takes effect
  • September 2021: Apple Mail Privacy Protection begins degrading open rate as an engagement signal
  • 15 February 2022: Spamhaus publishes its seven-category spamtrap taxonomy
  • November 2023: Spamhaus addresses claims that spamtraps click links
  • 1 February 2024: Google and Yahoo bulk sender requirements take effect
  • 2 April 2025: Microsoft announces authentication requirements for high-volume senders
  • 5 May 2025: Microsoft enforcement begins for senders of more than 5,000 messages a day

Summary

Who: Blocklist operators such as Spamhaus, SpamCop and Abusix, mailbox providers including Google, Yahoo and Microsoft, email service providers policing their own infrastructure, and distributed volunteer networks such as Project Honey Pot.

What: Email addresses with no legitimate owner, either created and seeded or reclaimed after abandonment, used to identify senders who harvest, purchase or fail to maintain their lists.

When: The supporting blocklist infrastructure dates to 1996 and 1997; Project Honey Pot's distributed trap network to 2004; the current published taxonomy to February 2022.

Where: At the SMTP transaction on receiving mail servers, with the resulting data distributed through DNS-based blocklists queried at connection time.

Why: Because permission cannot be verified from the receiving side of an email transaction. A trap address converts an unobservable question about consent into an observable event.