The List-Unsubscribe header is in the unseen header portion of email messages. Recipients don't see the header itself but if the receiving email network leverages the List Unsubscribe Header recipients will see an Unsubscribe button they can trust to unsubscribe from future messages.
The header can look like this to receiving networks:
Subject: We need to implement this list-unsubscribe thing
Date: February 22, 2016 12:16:59 PM MST
"The list-unsubscribe has been a very valuable tool for the email ecosystem, from consumers to businesses to mailbox providers. Over the past 20 years, consumers have slowly been trained to mistrust unsubscribe links located in the footers of email and spam, as some spammers would use the unsubscribe link to verify that the email address was a valid, active user. Once the spammers knew that, they would send them even more email rather than opting them out. In some cases, spammers would use the link as a way to install malware on an unsuspecting users’ machine." Microsoft Changes List-Unsubscribe Requirements Melinda Plemel, 1/23/15
Yes, for every email sent from our system Marketo leverages the mailto: List Unsubscribe Header function.
ISPs and spam filters view it favorably when making filtering decisions because having the List Unsubscribe header can indicate that the sender is actively working to avoid spam complaints. In fact, most major providers like AOL, Hotmail, Gmail, and Yahoo! support List-Unsubscribe functionality.
Looking specifically to Gmail, Gmail's Bulk Sender Guidelines recommend that the List Unsubscribe header be implemented.
How the List-Unsubscribe header works at Gmail
Gmail supports the List-Unsubscribe functionality and calls it “auto-unsubscribe.” Gmail inserts an Unsubscribe link next to the From Address.
When an email recipient clicks on “Report Spam,” a dialog box will appear that asks if they want to unsubscribe or report the email as spam. If they click unsubscribe, a notification will be delivered to the email address in the List Unsubscribe Header to stop mailing you.
Is this article helpful ?
We had a user unsubscribe via 'unsubscribe and report spam' method, however the messaged bounced and they received a delivery status notification that it had failed. I'm wondering if you've heard of anything like this happening, and/or if there's a way to make sure if they use this method that the link to unsubscribe will be valid?
What was the text of the DSN exactly?
Message not delivered
There was a problem delivering your message to MIZUE5BRFVCUYV2ZIRHEYY2JL44DSN2XLFTT2PI.firstname.lastname@example.org. See the technical details below.
The "technical details" though...
Reporting-MTA: dns; googlemail.com
Received-From-MTA: dns; email@example.com
Arrival-Date: Tue, 13 Aug 2019 14:21:14 -0700 (PDT)
Final-Recipient: rfc822; MIZUE5BRFVCUYV2ZIRHEYY2JL44DSN2XLFTT2PI.firstname.lastname@example.org
Diagnostic-Code: smtp; The recipient server did not accept our requests to connect. Learn more at https://support.google.com/mail/answer/7720
Last-Attempt-Date: Fri, 16 Aug 2019 21:16:47 -0700 (PDT)
Connections to the unsub server are no doubt heavily policed to prevent abuse. (Imagine that's because, per my tests, the mailserver itself doesn't know the full directory of legit recipients. Since it must deliver any mail that isn't screened out by other measures, other measures need to be stricter than usual.)
If the server wasn't down completely, perhaps it accidentally blacklisted Gmail for a period of time. Hard to say at this point.
Okay, thank you for your insight Sanford.
Brooke Hand, Apologies for my late response, I was out of the office and just saw your question today. My team has also observed the same issue you are describing and are actively working to resolve the issue. The behavior began when we implemented inbound TLS for bounces and unsub requests coming back to us. We have observed that every so often a message back to us from Google/Gmail will fail. We are working with Google mail team to understand what this is happening, we'd like to resolve the issue rather than roll back the inbound TLS for security reasons. The volume of failures has been very low but we are researching this aggressively to prevent these failures.
No worries, and thank you for getting back to me. The information you have provided is helpful; it's also good to hear that the volume of such failures has been low - this instance was the first we had seen or heard of it so the chances of it happening again to us are likely to be slim; regardless, we look forward to hearing how you and your team get on with solving this issue.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.