The worst thing about the yahoogle requirements has been their use of the term “one-click unsubscribe”. It’s an overloaded term that’s being used here to mean RFC 8058 in-app unsubscription. That’s a completely different thing to what one-click unsubscription has been used to mean for decades, often in the context of complying with legal requirements around unsubscription.
It’s confusing.
So here’s the simple explanation. To comply with everyone’s unsubscription requirements you need to do two things.
First thing
You need to have a clear link visible in the body of your message that allows users to unsubscribe. It’s the link you already have in the footer of your message:
When the user clicks on it they should go to a web page. That web page must have a clear, conspicuous button that the user can click to unsubscribe. It cannot require them to provide any other information. It cannot require them to log in to an account.
That page can have other options, such as being your subscription center, offering chances to opt-down, customize content, anything you like. But there must be an obvious button to unsubscribe.
You do not have to unsubscribe the user immediately they click on the link, that’s not what one-click unsubscribe means (and you absolutely should not). It should take the user to a web page.
Second thing
You must support RFC 8058 unsubscription. If you’re sending mail through an ESP they have to implement this and you don’t need to worry about it.
If you’re sending your own email or you are an ESP, read on.
RFC 8058 unsubscription is done in the headers of your email. It’s invisible to the user. It does not mean you need to add another link at the top of your email.
Those headers look something like this:
List-Unsubscribe: <https://mynews.apple.com/subscriptions?blahblahblah>
List-Unsubscribe-Post: List-Unsubscribe=One-Click
The link in the List-Unsubscribe header must be https. Clicking on it must take the user to a web page where they can unsubscribe, probably the same one the unsubscribe link in the body does.
The mail must be validly DKIM signed and those two headers must be included in that DKIM signature
Doing an HTTP POST to the URL must silently unsubscribe the user (or return an error if it can’t do so).
This is how menu options to unsubscribe in mail clients work. It’s how Yahoo’s subscriptions center works. And it’s how Gmail can offer to unsubscribe a user as a better alternative to marking it as spam.
Third thing
There is no third thing. That’s it. Done.
(I wrote a lot more about unsubscription if you really want more.)
RSS - Posts
Reading RFC 8058, it seems that List-Unsubscribe: links that take the user to a landing page where they have to click on a button to confirm are problematic, because automated systems wouldn’t be able to use them to remove the recipient from the mailing list. I think that one of the things that 8058 is trying to do is to provide a workaround to that, so that a user who clicks on a link would still have to click on the button but someone using their email service’s “this message is from a mailing list, click here to leave the list” automated function will just use the built-in function, but I’m not sure if I’m following that correctly. Do I have that right?
RFC 8058 provides a non-interactive unsubscribe, one that’s invisible to the user and done purely by background communication between the mail client and the list operator.
I see. The difference is whether the request is sent via GET or POST, right?
Thank you Steve, I did not know that, and a really informative article!