Successful sends on Black Friday

Last year a number of ISPs mentioned the Black Friday email volume was congesting their systems and causing delays. While anecdotally it seems that volume is up over last year I also haven’t heard any ISPs talking about congestion. Likewise, most of the delivery folks I’ve spoken too today and over the weekend are saying there were no major problems.

How’d the busiest email weekend of the year work for all of you?

Related Posts

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

Purchased lists and ESPs: 9 months later

It was about 8 months ago I published a list of ESPs that prohibit the use of purchased lists. There have been a number of interesting responses to that post.
thumbsup
ESPs wanted to be added to the list
The first iteration of the list was crowdsourced from different ESP representatives. They shared the info they had with each other. With their permission, I put it together into a post and published it here. Since then, I’ve had a trickle of ESPs asking to be added to the list. I’m happy to add any ESP. The only requirement is a privacy policy (or AUP) that states no purchased lists.
People reference the list regularly
I’ve had a lot of ESP deliverability folks send thanks for writing this post. They tell me they reference it regularly when dealing with clients. It’s also been listed as “one of the best blog posts of 2015” by Pardot.
Some 2016 predictions build on the post
I’ve read multiple future predictions that talk about how the era of purchased lists is over. I don’t think they’re wrong. I think that purchased lists are going to be deliverability nightmares on an internet where users wanting a mail is a prime factor in inbox deliverability. They’re already difficult to deliver, but it’s going to get worse.
Thumbsdown
Not everyone thinks this is a good post. In fact, I just recently got an comment about how wrong I was, and… well, I’ll just share it because I don’t think my summary of it will do it any justice.

Read More