I was talking to friends running an ESP platform the other day, helping them understand the difference between the available types of list unsubscribe support, what does it mean and how does it 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 hook into, to display an unsubscribe option to subscribers in a way and place 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? Standardized method for declaring what an unsub button should do.

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.

Značky: #ios, #wttw, #list-unsubscribe, #gmail, #Network

I've got just enough time for a quick post today, to share with you this very useful DMARC Dictionary put together by the fine folks at dmarcian . Check it out ! And since that would make for a very short blog post, here's four bonus online resources that you might also want to bookmark, if you didn't already know about them:

• The ISP Information page from Laura Atkins and Steve Atkins over at Word to the Wise , where they've collected info on which ISPs offer ISP Feedback Loops (FBLs), which ones have Postmaster information pages, help/support ticketing systems, etc.
• My new friends at Kickbox (disclaimer: they are my employer) have put together this great "Developer's Guide to Email" website that you are going to find quite useful if you are looking to learn more about email technology or study how it all comes together.
• Postmark's SMTP Field Manual allows you to look up example bounce messages for different ISPs, often with links to more information about a particular ISP's spam filtering.
• And finally, my very own XNND.com , a simple site that lets you DNS lookups and check various things about an IP address or domain name. (Like, does a domain have a DMARC or BIMI record?) Very recently, I moved XNND to Amazon's AWS EC2 platform, to make it faster, and I've got plans to add more features in the future, including re-incorporating my spamtrap data into lookups. (And you should give me your feedback on what else you think I should add to it!)

Happy Friday and happy bookmarking!

Značky: #dmarcian, #kickbox, #dmarc, #useful, #wttw, #Network, #postmark, #guide, #bimi, #xnnd