Yahoo Mail/Gmail 2024 Easy Sender Compliance Guide: Click here

FAQ: List Unsubscribe on Apple Mail on iOS


It was back in 2016 that we learned that Apple planned to add list-unsubscribe support to Apple's iOS email client, and that support came with iOS 10. 

Many ESPs have long supported a special header, the "list unsubscribe" header. Google's Gmail and Microsoft's Outlook.com, along with some other email clients or platforms, look for this header, and if it is found, they'll put some sort of prominent "unsubscribe" link or button in a special place in their user interface. At Gmail, in particular, this header tends to show only for "good" senders, so if you're a sender and you do see this extra unsubscribe link when sending to Gmail subscribers, know that Gmail probably considers your mail stream to be a wanted and safe one. And if you've got this functionality showing up for Gmail subscribers, you're probably already covered when it comes to iOS users.

Assuming that a message contains the correct "mailto" style of list-unsubscribe header, the mail client user interface will show a dismissible banner above the message headers that says, "This message is from a mailing list," followed by a clickable "Unsubscribe" link. If you click on this "Unsubscribe" link, the mail client tells you: "Mail will send a message from (you) to unsubscribe from this mailing list." You can then either hit the cancel button, or continue by clicking on the "Unsubscribe" button.

If you continue by hitting that "Unsubscribe" button on the pop-up message, Apple mail generates an email message, from you, with an empty subject line, to the email address specified in the original message's list unsubscribe header. The body of that message will contain the following text: "Apple Mail sent this email to unsubscribe from the message "(subject line of original message)".

After you unsubscribe in response to a given message, the Apple Mail client will no longer show you the banner and unsubscribe link for that message.

Frequently Asked Questions

Are these spam complaints? No, these are "just unsubscribe requests." Your email service provider (ESP) or mailing list management software should capture them just fine, assuming the list-unsubscribe header they have implemented works properly. Do make sure every request you receive results in that recipient being unsubscribed; this is clearly what the recipient wanted.

How will these unsubscribes show up in my email service provider (ESP)'s reporting? There is a 99% chance that these unsubscribes will be reported by your ESP the exact same way that current Gmail "list unsubscribes" are tracked and reported. It probably isn't possible to tell Gmail unsubs from Apple mail user unsubs, unless your system can parse the body copy and look for the string "Apple Mail sent this email" to denote which ones are Apple device users. I wouldn't expect most platforms to be able to do that.

Do these reports affect my sending reputation? Probably not. Nothing seems to suggest that Apple is collating this data in any way that would allow it to be used to measure a sender's reputation. Your email service provider (ESP) may or may not take action based on some elevated level of unsubscribes, but this would not be specifically driven by Apple device users.

I want to support this functionality in my mailing list manager. How do I add it? First, read up on VERP, Variable Envelope Return Path. You may already be using VERP for your bounce processing (Return Path header), wherein you use a unique, encoded per-recipient/per-mailing bounce address. (Do it -- it's a best practice.) Basically, just do the same thing for the list-unsubscribe header:

List-unsubscribe: <mailto:(encoded_string)@server-that-handles-unsubs.example.com>

You want to use something VERP-like so that you can just assume that any mail to that address is an unsubscribe request, and that you can trace it to the correct recipient requiring unsubscribing. This saves you from having to parse the from address, or accidentally removing the wrong address. (If you remove the wrong address, the recipient could still receive additional mail, which will likely make them unhappy, and potentially violate the law.)

Does Apple support both the MAILTO and HTTP methods of list-unsusbcribe? Apple supports only the "mailto" version of the list-unsubscribe header (as defined in RFC 2369) appears to be supported by the iOS mail client. The "http" version of the list unsubscribe header does not appear to be supported. Apple's mail client seems to ignore the "http" versions of the list unsubscribe header. (Compared to Gmail, for example, where both HTTP and MAILTO methods are supported.)

I see that iOS Mail sends an email reply requesting that I be unsubscribed. What email address is it sending that email message to? It is sending that email message to a special address, specified in the header of the original email message. That header is called "list-unsubscribe." This header is usually hidden, not displayed by default in most email clients. If you select "view source" or "view original" to show all of the email headers, there you'll see the list-unsubscribe header. In that header, the email address to send the unsubscribe request to can be found after the text "mailto:".

Will there be a copy of this emailed unsubscribe request saved to my "Sent" folder? Yes, iOS Mail saves a copy of this message and puts it in your "Sent" folder so that you can review it later, if you so desire.

Does Apple support the newer "one click" unsubscribe POST functionality? No, they don't seem to have support for "list unsubscribe POST" currently. (Learn more about one click unsub here.)

Does this functionality work only for some email domains (i.e. Gmail, Hotmail, etc.)? Apple has implemented this functionality in their client in a way that is not specific to the recipient's domain. Meaning, it doesn't matter if you're using Apple Mail to read mail from an iCloud account, Gmail account, or something else. Regardless of your email domain and email account, Apple mail will show the unsubscribe feature as appropriate.

Post a Comment

Comments policy: Al is always right. Kidding, mostly. Be polite, please and thank you.

Previous Post Next Post