The importance of data hygiene

Over the weekend, one of the major ISPs purged a lot of abandoned accounts from their system. This has resulted in a massive increase in 550 user unknown bounces at that ISP. This ISP is one of those that uses bounces to feed into their reputation system and the purge may cause otherwise good senders to be blocked temporarily.
Talking to clients and other industry folks, it looks like the addresses that have newly bounced off had zero activity for at least 6 months. Nothing. Nada. No clicks. No opens. No interaction.
This is why data hygiene is so critical. Just because the emails are being accepted at the ISP, and even showing inbox placement at the mailbox monitoring companies does not mean that there is actually someone reading your email. Failure to look at overall data means that when an ISP bulk deletes abandoned accounts then bounces will increase. While I don’t expect this to have any real, long term effect on sender reputation I do expect that some senders with a lot of cruft on their list will see some short term delivery problems.
Companies that run re-engagement campaigns saw a whole lot less bouncing and even less blocking as a result of the purge. They were removing addresses that were non-responsive all along and thus didn’t have major deadwood on their list.
Ongoing data hygiene shows you what your list really is, not your list plus abandoned accounts. The addresses that the ISP purged? They were not valuable anyway. No one was reading that mail for at least 6 months.
If you did see a spike in bounces this weekend at a major ISP, you should really look at engagement. If some percentage of recipients at one ISP are actually non-existent, then it’s likely that about that same number are non-existent at other major ISPs as well. What are you going to do to identify and remove those dead addresses from your lists?

Related Posts

iContact lists compromised

iContact has acknowledged that (some) of their customer lists were compromised and that they are investigating. As iContact has chosen not to allow comments on that post, feel free to share comments here.
HT: @aliverson

Read More

Protecting customer data

There have been a number of reports recently about customer lists leaking out through ESPs. In one case, the ESP attributed the leak to an outside hack. In other cases, the ESPs and companies involved have kept the information very quiet and not told anyone that data was leaked. People do notice, though, when they use single use addresses or tagged addresses and know to whom each address was submitted. Data security is not something that can be glossed over and ignored.
Most of the cases I am aware of have actually been inside jobs. Data has been stolen either by employees or by subcontractors that had access to it and then sold to spammers. There are steps that companies can take to prevent leaks and identify the source when or if they do happen.

Read More

This is why the ISPs throw up their hands at senders

I recently saw a question from an ESP rep asking if anyone had a personal contact at a particular ISP. The problem was that they had a rejection from the ISP saying: 571 5.7.1 too many recipients this session. The ESP was looking for someone at the ISP in order to ask what the problem was.
This is exactly the kind of behaviour that drives ISPs bonkers about senders. The ISP has sent a perfectly understandable rejection: “5.7.1: too many recipients this session.” And instead of spending some time and energy on the sender side troubleshooting, instead of spending some of their own money to work out what’s going on, they fall back on asking the ISPs to explain what they should do differently.
What, exactly, should you do differently? Stop sending so many recipients in a single session. This is not rocket science. The ISP tells you exactly what you need to do differently, and your first reaction is to attempt to mail postmaster@ the ISP and then, when that bounces, your next step is to look for a personal contact?
No. No. No.
Look, connections and addresses per connections is one of the absolute easiest things to troubleshoot. Fire up a shell, telnet to port 25 on the recipient server, and do a hand SMTP session, count the number of receipts. Sure, in some corporate situations it can be a PITA to do, sometimes you’re going to need to get it done from a particular IP which may be an interface on an appliance and doesn’t have telnet or whatever. But, y’know what? That Is Your Job.  If your company isn’t able to do it, well, please tell me so I can stop recommending that as an ESP. Companies have to be able to test and troubleshoot their own networks.
Senders have been begging ISPs for years “just tell us what you want and we’ll bother you less.” In this case the ISP was extremely clear about what they want: they want fewer recipients per connection. But the ESP delivery person is still looking for a contact so they can talk to the ISP to understand it better.
This is why the ISPs get so annoyed with senders. They’re tired of having to do the sender’s job.

Read More