Let's talk List-Unsubscribe!

I was talking to friends running an ESP platform the other day, helping them understand the difference between the available types of list unsubscribe headers, what does it all mean and how does it all work. Might you find that interesting as well? Let's see.

List-unsubscribe: What is it? It's a hidden email header. Originally specified in RFC 2369, the goal was to provide a hook that email clients could use to display an unsubscribe option to subscribers in a method and location that was easy to find and common from message to message. I can't speak for the creators, but I imagine the goal is to make it easy for subscribers to unsubscribe, so that they don't turn to clicking the "report spam" button instead, out of frustration. TL;DR? It's basically a declaration of how a  standardized "Unsubscribe" button in an email client should work.

It's been around a while (the spec is dated 1998) but Gmail was the big adopter, rewarding good senders by displaying an unsub link in the Gmail UI, if the header was present. (Gmail actually sometimes displays the link even with no header present, for some big brands, to help drive display of the link more often. So if you see an "Unsubscribe" link in the Gmail UI, but there's no list-unsub header, that's why.) Sendgrid's got a good overview of the basics, and I published my own FAQ about this back in 2016.

And then along came Apple's iOS 10, where they added (email based) support for list-unsub as well. 

And as I've said before, distilling down guidance from Laura Atkins to just the TL;DR -- if you send marketing mail or if you're building a platform to serve up marketing mail, you NEED list unsubscribe support. The sending reputation of the customers sending from that platform are going to suffer without it.

That's the history. Now let's jump forward to today. There's a new-and-improved version of the standard outlined in RFC 8058 called "Signaling One-Click Functionality for List Email Headers" or what I tend to simply call "list unsubscribe post" because of what happens behind the scenes when the unsub button is pushed. The webmail makes a "POST" call back to the sending platform to pass the unsubscribe request. In theory, bots and security scanners won't make a POST request, preventing "false positive" unwanted unubscribes.

Tony Patti from Sparkpost put together a great overview (and a chart) in 2020 showing which ISPs support which method. It's something you should bookmark and use as your guide when building list-unsub and list-unsub post support into your sending platform. The one thing I'd update from that post is that I'm observing Microsoft's Outlook.com sending a list-unsubscribe POST response, but I think it might be malformed. It seemed to do it even when no list-unsubscribe-post header was present, and I'd recommend testing to make sure you can properly capture these unsubs requests.

It's clear to me that list-unsub-post is the future of embedded unsub functionality, but I don't think it's safe to implement it without also implementing the mailto: version, otherwise you'll lose the opportunity to receive opt-outs from Apple Mail users.

And finally, don't fear the unsubscribe. Chad White explained for the Litmus blog back in 2016 why List-Unsubscribe Concerns Are Overblown, and that guidance is still solid. Subscribers come and subscribers go. You ARE going to lose subscribers over time; they can't be locked down in any practical way -- trying to do so will only cause harm to a sender's reputation. Don't forget that list growth needs to be part of your marketing strategy. It's not simply that you "build a list" once and then you're done.