Adding List-Unsubscribe Header to SFMC Transactional Emails via Messaging API

Question

I’m working with the Salesforce Marketing Cloud (SFMC) Transactional Messaging API to send transactional emails. Recently, both Google and Yahoo announced changes to their policies for handling emails from bulk senders (those sending more than 5000 emails per day to Gmail recipients). As part of these changes, they now require adding a List-Unsubscribe header to all emails based on the standard RFC8058 and RFC 2369.

Here’s our specific scenario:

• Our company sends well above 5000 emails per day via the SFMC Transactional Messaging API.
• Most of these emails are updates related to our users’ saved content (such as updates on items in their watchlist or new items based on saved searches).
• For all these update emails, we already include an unsubscribe link within the email body content.
• While the upcoming change from Google is primarily aimed at commercial emails, we want to ensure compliance and provide a better user experience by including the List-Unsubscribe header regardless of whether it’s strictly required.

---

Questions:

1. Is It Possible to Add the List-Unsubscribe Header via the SFMC Messaging API?

• I’ve looked into the Messaging-API documentation, but I couldn’t find any specific guidance on adding email headers
• Has anyone successfully added the List-Unsubscribe header to transactional emails using the SFMC Messaging-API?
• If so, could you share any insights or steps?

2. Alternative Approaches:

• If adding the header via the API isn’t feasible, are there any alternative ways to achieve this?
• Perhaps a workaround or a different approach that ensures the inclusion of the List-Unsubscribe header?

3. Best Practices and Considerations:

• Are there any best practices or additional considerations when implementing the List-Unsubscribe header for transactional emails?
• Any pitfalls to avoid or specific details to be aware of?

I appreciate any assistance or guidance from the community. Thank you!

Answer 1

That's an interesting question. You should switch your send classification from Transactional to Commercial - this is the only method for adding list-unsubscribe header to your email. Messages sent using Transactional send classification cannot have the additional header included with any other methods.

I went to API documentation, to find a way of defining the send classification for the sends triggered by your Transactional Messaging API. This can theoretically be done when creating your send definition. But, you can only use send classifications categorised as Transactional:

The external key of a sending classification defined in Email Studio Administration. Only transactional classifications are permitted. Default is default transactional.

I would reach out to Salesforce support to get a conclusive guidance on whether there are other methods, not covered by the documentation, but I doubt there are other possibilities.

Answer 2

According to the google & yahoo documentation, it sounds pretty unlikely* that they will block you for transactional emails, if these emails are what that recipients want / dont flag as spam.

*by which I mean it specifically says that they dont. Obviously, who am I to guarantee this, but the wordings in the quotes below are pretty clearly worded.

==

highlights by me:

How is the distinction made between promotional and transactional messages

The distinction between promotional and transactional messages can vary depending on industry and applicable regulations. Message recipients, not Google, determine the nature of the messages they receive. To reduce high spam rates, consider giving users an easy way to unsubscribe from marketing and promotional messages, and keep the user in mind when designing your emails.

What happens to messages that don’t meet the one-click subscribe requirement for promotional, marketing, and commercial messages?

We don’t automatically reject messages or mark messages as spam when they don’t meet the one-click unsubscribe requirements in our Email sender guidelines. However, unwanted messages that don’t use one-click unsubscribe are more likely to be reported as spam by recipients. An increase in messages marked as spam increases the chances that future messages from the same sender are delivered to spam. Additionally, only bulk senders that meet all the requirements in our Email sender guidelines, including one-click unsubscribe, are eligible for mitigation.

source

https://support.google.com/a/answer/14229414?sjid=18421852417566266633-EU#zippy=%2Chow-can-bulk-senders-make-sure-theyre-meeting-the-sender-guidelines%2Cwhat-time-range-or-duration-is-used-when-calculating-spam-rate%2Chow-is-the-distinction-made-between-promotional-and-transactional-messages%2Cwhat-happens-to-messages-that-dont-meet-the-one-click-subscribe-requirement-for-promotional-marketing-and-commercial-messages

Yahoo: no real difference

Is one-click unsubscribe required for all of my mail? No, one-click unsubscribe is only required for promotional/marketing messages. The requirement does not apply to transactional messages (e.g. order confirmations, password resets). We will not make the determination of what mail should and should not contain an unsubscribe link. You should rely on local regulations and your best judgment based on user behavior.

If you see high complaint rates for mail that is not legally required to have an unsubscribe link, it may be in your best interest to include a one-click unsubscribe option to reduce the chance of delivery issues, and give users an easy way to stop receiving those messages.

Source

https://senders.yahooinc.com/faqs/

Paraphrasing the above:

The philosophical question "what is transactional" is with the recipient, not the ESPs in question (yahoo, google).

In other words, don't provoke complaints with your "transactional" content, and you'll be fine.

In other, other words: SF Support in a sense is right when they tell you, you don't technically need it / the product need not support it. Your transactional mails technically have the benefit of the doubt, and then the recipients judge.