How to handle spamtraps

27 February 2020

So, you’ve discovered that your customer has an issue with spamtraps on a mailing list. What do you do now?

As a rule, spamtraps end up on a list due to problems with permission or hygiene. No, that’s not exclusive of other things, nor is it necessarily an indication that policies have been violated. But, it’s been my experience that spamtrap problems and policy violations are strongly positively correlated.

Dealing with spamtraps before they become a problem

The easiest way to deal with spamtraps is to head them off of at the pass. Ask questions of new prospects and customers:

  • How do you get new addresses for your list?
  • How do you verify address ownership?
  • What are your policies surrounding suppression of unengaged customers or prospects?
Read moreThe Spock Trap

Also, pay some attention to the questions that they’re asking. Some questions should raise red flags that will lead to a deeper set of questions about practices:

  • Will you suppress spamtraps?
  • What is your policy for dealing with Spamhaus listings?

While it’s possible that questions like these can be innocuous, I generally hear about them from potential clients who have had “bad” experiences at their previous email service provider with the problems that spamtraps can cause.

Particularly problematic are pre-sales questions about how you handle listings from a block list provider like Spamhaus. That’s generally indicative of contentious past listings along with anticipated future listings. So, you should be asking questions about what happened in the past, if they’re still listed now, what changed to bring about the delisting (if one has happened), and why they think that they might be relisted in the future.

They already walk among us

Read moreBad Advice

Most of the time, you’re going to find spamtraps after the customer has been onboarded. It might mean any one of a number of different things:

  • Poor data entry and validation
  • Poor bounce processing
  • The use of old, but rarely used, data (especially around holidays)
  • Purchased data
    • List buys
    • List rentals
    • List appends
    • List trades
  • The use of co-registration data where the data is old

Not all of those possibilities are indicative of policy violations. But, almost all are correctable with a bit of work.

Get rid of non-opt-in data

The easiest bit of advice to get rid of spamtraps is to get rid of non-opt-in data. If the use of purchased lists isn’t against a policy violation, then you should get buy in to have your attorneys change that as quickly as possible. I can’t begin to tell you how often I’ve seen Spamhaus SBL listings where the listing evidence page says that there is evidence that the data was purchased or came from some non-opt-in source.

Getting rid of non-opt-in data includes getting rid of co-registration data, too. In my experience, “co-reg” is just a fancy way of saying “I bought a list from someone with a website.” The fig leaf of “the co-reg provider told everyone that he would give people like us their contact information” is just that: a fig leaf.

Rely on engagement

The only sure-fire way to get rid of spamtraps from a list is to trim the list. But, how do you know what to keep and what to suggest might be appropriate trim? For this, you should plan to ask everyone on spamtrap-infected lists to renew their permission with a couple of exceptions:

  1. Brand new addresses. Addresses that are less than 30 days old are generally going to be okay to hold onto. These addresses haven’t been around long enough to have built up a good engagement profile. So, unless you’re being told that the problem is that the list is contributing to a “mailbomb” keeping these addresses should not present a problem.
  2. Addresses that have opened or clicked at least twice in the last 6-12 months. These addresses are generally not spamtraps, and we know that due to the level of engagement that they’re displaying with messages.

Why “at least twice”? The reason is that spamtrap operators will rarely interact with messages. This is especially true if they believe that there is a problem with a particular message which would result in something malicious happening to the computers of users who load the landing page. The only way to investigate that is to react exactly as a user would. By increasing the number of required interactions, you increase the chances that spamtraps which were used in such a manner will be dropped.

Most modern email service providers have their own advice on how to run a well-formed and effective re-confirmation campaign. I won’t be supplanting or suggesting any changes to that. (At least not in this post.)

The case for address validation

I’m not a huge fan of address validation services. By and large, that industry has tended toward abusive behavior that has not made them any fans among mailbox providers. This means that the mailbox providers are not cooperative partners which can lead to some suspect data.

That said, if someone could check on the veracity of incoming data, that should be a good thing. So, I will sometimes suggest that a validation service that offers an API be selected and used in realtime for webform and point-of-sale data entries.

At the very least, this will help with typos in the domain part of the email address. But remember that while validating the domain is a good start, a typo can just as easily happen before the “@” as after it.

So, if you have a customer who has a spamtrap problem that you think might be caused by data entry errors, then I think that you can make a fairly compelling case for the use of address validation to mitigate ongoing issues.

Conclusion

The one thing that you’ll never see happen is a trap operator tell you what the addresses are that have found their way onto your customer’s list(s). They tend to look at that in the same way that a spy or a journalist looks at their sources.

But, having a trap on a customer’s list isn’t the end of the world. There are still a number of things that can be done to help a customer successfully navigate those waters.

Mickey Chandler
Latest posts by Mickey Chandler (see all)