What about Tom?

I use tom@hotmail.com as my default bogus email address. Tom has subscribed to so many things because of me.

This is why address verification doesn’t work. The address tom@hotmail.com is a real address. It exists. It accepts mail. And at least one person admits to signing up Tom for mail that the person doesn’t want. I’m sure he’s not the only one.

<- 250 OK
-> MAIL FROM:<test@gmail.com>
<- 250 test@gmail.com....Sender OK
-> RCPT TO:<tom@hotmail.com>
<- 250 tom@hotmail.com
-> QUIT
<- 221 SNT004-MC1F46.hotmail.com Service closing transmission channel

Signups like this do contribute to deliverability problems in a number of ways.

  1. The address tom@hotmail.com may be a spam trap. Sending mail to too many spamtraps can result in mail going to the bulk folder.
  2. It may belong to an actual person. Sending mail to someone who has not asked for it can result in spam complaints and bulk foldering.
  3. It may be a canary address. This is one that gets a lot of spam. If mail goes to this address then it’s likely spam and similar mail is bulk foldered at other recipients.
  4. This may be a test address. It might be used by someone inside Hotmail as a test address.

A few of these fake signups aren’t going to hurt deliverability for most senders. Over time, however, these fake signups are going to accumulate on a list. As they accumulate they can, and do, start to affect deliverability. It you’re hitting a lot of these types of addresses it tells the ISP that you don’t have good subscription practices. The ISP knows you are sending mail to people who don’t want it and never asked for it. Filters are designed to affect mail sent to people who don’t want it and never asked for it.
These kinds of addresses are one reason delivery folks talk about segmenting mail based on engagement. Getting rid of even a few of them off a list can improve deliverability for an otherwise opt-in list.
Address verification doesn’t weed out these address. The test I did above is exactly what most of the verification services do. They’re going to return that tom@hotmail.com is a valid address and it’s going to end up in your list.
For those of you who are the type to put real addresses into signup forms, please don’t. It’s unfair to the people who own those addresses and it’s unfair to marketers. Use an address that you know doesn’t exist – like anything@example.com, .net or .org. These domains are reserved by ICANN and will never have users. Stop directing your unwanted email to an innocent 3rd party. They don’t deserve it, and neither do the senders you’re trying to avoid.

Related Posts

It's about the spam

Tell someone they have hit a spamtrap and they go through a typical reaction cycle.
Denial: I didn’t hit a trap! I only send opt-in mail. There must be some mistake. I’m a legitimate company, not a spammer!
Anger: What do you mean that I can’t send mail until I’ve fixed the problem? There is no problem! You can’t stop me from mailing. I’m following the law. My mail is important. I’ll sue.
Bargaining: What if I just send mail to some recipients? What if I hire an email hygiene company to remove traps from my list?
Acceptance: What can I do to make sure the people I’m mailing actually want to be on my list?
Overall, my problem with the focus on spamtraps (and complaints to a lesser extent) is that these metrics are proxies. Spamtraps are a way to objectively monitor incoming email. Mail sent to spamtraps is, demonstrably, sent without permission of the address owner. This doesn’t mean all mail from the same source is spam, but there is proof at least some of the mail is spam.
If there is enough bad mail on that list, then reworking the subscription process may be necessary to fix delivery.

Read More

April: The month in email

April was a big month of changes in the email world, and here at Word to the Wise as we launched our new site, blog and logo.
DMARC
The big story this month has been DMARC, which started with a policy change Yahoo made on April 4 updating their DMARC policy from “report” to “reject”. We began our coverage with a brief DMARC primer to explain the basics around these policy statements and why senders are moving in this direction. We shared some example bounces due to Yahoo’s p=reject, and talked about how to fix discussion lists to work with the new Yahoo policy. We gathered some pointers to other articles worth reading on the Yahoo DMARC situation, and suggested some options for dealing with DMARC for mail intermediaries. Yahoo issued a statement about this on April 11th, explaining that it had been highly effective in reducing spoofed email. We also noted a great writeup on the situation from Christine at ReturnPath. On April 22nd, AOL also announced a DMARC p=reject record.  We talked a bit about who might be next (Gmail?) and discussed how Comcast chose to implement DMARC policies, using p=reject not for user email, but only for the domains they use to communicate directly with customers. We expect to see more discussion and policy changes over the next few weeks, so stay tuned.
Spamtraps
We wrote three posts in our continuing discussion about spamtraps. The first was in response to a webinar from the DMA and EEC, where we talked about how different kinds of traps are used in different ways, and, again, how spamtraps are just a symptom of a larger problem. Following that, we wrote more about some ongoing debate on traps as we continued to point out that each trap represents a lost opportunity for marketers to connect with customers, which is really where we hope email program managers will focus. And finally, we tried to put some myths about typo traps to rest. As I mentioned in that last post, I feel like I’m repeating myself over and over again, but I want to make sure that people get good information about how these tools are used and misused.
Security
We started the month by saying “Security has to become a bigger priority for companies” and indeed, the internet continued to see security breaches in April, including the very serious Heartbleed vulnerability in SSL. In the email world, AOL experienced a compromise, which contributed to some of the DMARC policy changes we discussed above. In a followup post, we talked about how these breaches appear to be escalating. Again, we expect to hear more about this in the next weeks and months.
Best Practices
Ending on a positive note, we had a few posts about best practices and some email basics. We started with a pointer to Al Iverson’s post on masking whois info and why not to do it. Steve wrote up a comprehensive post with everything you ever wanted to know about the From header and RFC5322. I talked about how companies ignore opt-outs, and why they shouldn’t. I shared a really good example of a third-party email message, and also talked about message volume. And finally, we talked about how and why we warm up IP addresses.
Let us know if there’s anything you’d like to hear more about in May!

Read More

Spamhaus answers questions

Lost in all of the DOS attack news this week is that the first installment of Spamhaus answering questions from marketers in Ken Magill’s newsletter.
It’s well worth a read for anyone who is interested in hearing directly from Spamhaus.
One quote stood out for me, and it really sums up how I try to work with clients and their email programs.

Read More