Enhanced handling of ‘list unsubscribe’ requests from inside email applications

Beginning Oct. 24, 2016, we will treat “unsubscribe” requests from email platforms differently than “Spam” reports. These requests come from the “Unsubscribe” buttons in apps like Gmail, as opposed to someone clicking your messages’ own “unsubscribe” link. This will optimize delivery for users who wish only to leave a mailing list and not completely prevent important messages such as password resets from reaching them. Accordingly, please note two considerations resulting from this change:

  • Developers who rely on Sailthru postbacks can respect a new “mode” value that indicates a unsubscribe request was made
  • Marketers should use the “transactional” template designation to ensure critical messages (password resets, receipts) make it to customers

Read on for more details about these two items.


When an end user receives an email and marks it as “Spam,” that sends a Feedback Loop message to the email service provider (Sailthru) that allows the ESP to opt-out the user from future sending.

Some ISPs and email programs, such as Gmail, now allow for users to use an application-level “unsubscribe” link. In Gmail, you’ll often see this at the very top of the window next to the sender’s name. This native unsubscribe button/link keeps the end-user in the email application and allows the email service to handle the opt-out for them via the same Feedback Loop system that denotes spam. This is not the same as the unsubscribe link you include in your message, which directs the users to a Sailthru Hosted Page and allows them to opt-down or entirely opt out of messaging.

What’s Changing

There are separate “spam” and “unsubscribe” designations in the Feedback messages we receive, and beginning Oct. 24, 2016, we’ll act on the “unsubscribe” messages differently than “spam.” After the unsubscribe feedback is received, the user’s status will be changed to “optout marketing” and customers using our “transactional” template functionality will still be able to message important, “transactional” templates (i.e., receipts, password resets) to users if those templates are set up and approved by Sailthru. Learn more about the “transactional” status and templates here.

The following table summarizes behavior before and after the change for both user status, and the “mode” and “reason” parameters in the Sailthru postback.

Feedback type Before 10/24/16 10/24/16 and after
Spam Opt-out user from all messages from the account (user status “optout-all”)

Postback parameters from Sailthru:

[no changes]
Unsubscribe Opt-out user from all messages from the account  (user status “optout-all”)

Postback parameters from Sailthru:

Opt-out user from all campaign and transactional messages, except for those transactional message templates approved by Sailthru as “basic” (user status “optout-basic”). “Basic” will only be seen when you’re using the API. In the UI, you’ll see Optout Marketing.

Postback parameters from Sailthru:

Developers should note that our Sailthru Postbacks will now send a new value for the “mode” parameter in Sailthru postbacks on user changes when a user uses an unsubscribe link in the email application. Marketers should ensure they are using our optout marketing template functionality to continue messaging users with key transactional messages even after an unsubscribe.

Learn more about Sailthru postbacks here, and see the updated documentation on opt-out mode types.

Please Note: This change will not be retroactive and we are unable to reprocess events prior to this change.

If you have any questions on these changes, or need help approving your “transactional” templates, please contact Sailthru Support or a Customer Success team member.