Details On Email Delivery
ServiceSpace
--Nipun Mehta
3 minute read
Jan 26, 2015

 

We will send out 100 million emails this year, so it's helpful for everyone to understand the high-level process -- particularly around deliverability.

Typical happy process goes like this: we send an email, it is received by the recipient's email client (Gmail, Outlook, berkeley.edu, etc.), and then it is delivered to the recipient's inbox. If the recipient doesn't like it, they can click on unsubscribe and in one-click be removed from our site.

Then the caveats. :)

First is spam. Email clients naturally want to filter spam for their users, and they all have their own algorithms for this filtering. Spammer are constantly trying to rig that system, so it's an ongoing battle -- further complicated by features like Gmail's "Promotions tab". To avoid the filter spam filter across hundreds of different email client is impossible to predict, but we do our best.

Second is that emails bounce. There's the over-quota kind of "soft bounce" and then the "server unreachable" hard bounce. It's possible that emails do recover from hard bounces, but if we see couple of hard-bounces in a row, we drop the subscriber automatically.

Third is unsubscribe. Ideally, people unsubscribe from our site. But email client sometimes give their users added convenience of getting off directly -- which then contacts our email service provider and which "globally opts out" that email address from all our emails. In many cases, this is good -- but in our case, readers often want to unsubscribe from one list and don't realize that there's lot of ServiceSpace lists that are connected with it. So this creates a discrepancy.

Fourth is "block bounce". When servers like ours are blasting millions of emails, email clients like comcast.net would look at say, "20 thousand emails in the last 5 seconds from servicespace.org? Looks like a spammer." They would block all emails from our server. When they do this, our email service provider has to request them to lift this ban (after showing that we're legit) -- and this happens couple times a quarter, most frequently with comcast.net, but recently with mac.com as well.)

So, when someone says, "Hey, I am not getting my emails", we ...
 

1) make sure that they're actually subscribed

2) ask them to check

3) make sure that they're not marked as bounced or not globally opted-out

4) ensure that there isn't an open block-bounce with their domain

So, what can we do to maximize delivery? Well, it's an art, but here's the basics ...
 
--Don't send spam. :)

--Follow email best practices -- like having unsubscribe links in every newsletter. We do this, and are always on the lookout to step it up.

--Secure ours server so hackers can't send fake emails from our machines -- and we're solid on that front.

--Code standards-complaint newsletters. We do a good job of this, although our designers often get upset :) since this always strips down the functionality.

--Protect our server "reputation" (judged by third parties) -- we have 99 out of 100, and are working on getting 100. :) Sending emails from domains other than ours will bring the reputation down -- so, for instance, all the challenge emails can't be sent from personal emails but have to go out from @kindspring.org (although the reply-to address can be set as we wish).

--Have multiple IP addresses, so you can rotate them for very big campaigns and avoid "block bounce" headaches. We do this.

--Get third-party certifications to say we're legit. We have the basics here, but could get couple more validations down the road.

This is the high-level of the nuts and bolts; and then we have a super-clean front-end for all this.  All put together, there's a lot here -- stuff that actual $100M dot-coms do.  For us, though, it is optimized for commercial-free content, focus on decentralized design, and seamless scale-up/down. 
 

Posted by Nipun Mehta on Jan 26, 2015


1 Past Reflections