The issue I have with Commercial Emails now is that in iOS Mail, the list-unsubscribe pop ups, allowing users to unsub, which feedbacks to SF, registering as a unsubscribe, however, the way we manage opt-outs is via an unsub link that links to an external platform and thus, there's no feedback loop currently from SF to the said external platform.

I've tested that by using Transactional Send Classification, it would get rid of the popup, so this would be a workaround for me.

My question is,

  1. Can I use Transactional Send Classification (may have to check the "Honor source and publication list level opt outs" option) for commercial emails?
  2. And still include the unsubscribe link that links to the external site (so I can cover myself legally to comply with the Spam Act)

Anyone with any experience with this, please share, or would like to hear of any way to get rid of the list-unsubscribe.


  • Yes if you want a fine
    – 0xsegfault
    Commented Oct 15, 2019 at 0:42
  • 3
    It would be safer to have sfmc unsubs sent (export or api) back to your DBOR to sync up rather than risk what not only could be a heavy fine, but also a severe hit to sender rep Commented Oct 15, 2019 at 0:50

2 Answers 2


The unsubscribe function provided by the email client/device (iOS Mail, etc) can not be controlled. If a user clicks this link it sends a technical message to Salesforce Marketing Cloud that unsubscribes them from the applicable List (All subscribers, etc).

You should not take steps to override this.
As Gortonington mentioned, you should create a sync process between SFMC and your customer database. We have strict Marketing Consent laws in Australia, and we have created a data sync from Salesforce into our Customer Database to ensure we respect when subscribers want to stop receiving emails, no matter how they opt out.

You can do this easily by exporting subscriber data directly from All Subscribers, or querying the Unsubscribe Data View in Automation Studio.

Bets practice is to reserve Transnational Send Types for critical messages - like order confirmations and password resets.


Here is an example of SSJS I have built for this purpose, calling a 3rd party API to unsubscribe, and reactivating subscriber in All Subscribers list:

<script runat="server">

//Authorize API Call
var authurl = 'https://example.com/authorization/oauth2/token';
var contentType = 'application/x-www-form-urlencoded';
var payload = 'grant_type=client_credentials';
var accessTokenResult = HTTP.Post(authurl,contentType,payload,["Authorization"],["Basic abcdefghijklmnopqrstuvwxyz=="]); 
var accessToken = Platform.Function.ParseJSON(accessTokenResult["Response"][0]).access_token;
Write("AccToken: "+accessToken);

//Data Extension Initialisation and row retrieval + All subscriber List Initialisation
var unsubs = DataExtension.Init("List Unsubscribe Management");
var myList = List.Init("All Subscribers - 264");
var data = unsubs.Rows.Retrieve({Property:"EmailAddress_Master",SimpleOperator:"greaterThan",Value:0});
var datalength = data.length;
var LogDE = DataExtension.Init("Logging");

// Loop and API call to API using all values in 'List Unsubscribe Management'
for (var i = 0 ; i < data.length ; i ++) {
   var url = "https://example.com/unsubscribe";
    var EmailAddress = data[i].EmailAddress_Master;
    var SubscriberKey = data[i].SubscriberKey;
    var Tokenvar = data[i].Token;
 var contentType = 'application/json';
 var payload = '{data : { type : "confirmTransaction", attributes: { transactionToken : '+Tokenvar+' }}};';
 var headerNames = ["Accept","Authorization","Api-Key","Api-Version"]; 
 var authorizationHeader ="Bearer "+accessToken;
 var headerValues = ["application/json",authorizationHeader,"abcdefghijklmnopqrstuvwxyz","1"]; 
 var result = HTTP.Post(url, contentType, payload, headerNames, headerValues, content);


You must adapt the endpoints, data extension keys and list IDs - but basically this is the approach you need to take. You will of course need to populate the "List Unsubscribe Management" by querying the Unsubscribe data view, as Cameron Robert also suggests.

  • Nice code Lukas. We do a similar hourly SSJS sync however we leave the record as "unsubscribed" in SFMC until the user tries to re-subscribe - that way any Journey activity they could be in is also prevented from sending them emails. We've also found that the Subscribe/Unsubscribe SSJS API can only handle around 1800 calls within the 30 minutes timeout limit. Commented Oct 15, 2019 at 13:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .