2

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?
  1. 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?
  1. 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!

4
  • 2
    1. No. 2: Proxy. You don't want to go there. 3. Complain to your Account Executive and/or MC product mgmt
    – identigral
    Feb 19 at 17:22
  • Thanks for the comment 1. I already feared this :( 2. Just out of interest, what kind of proxy are we talking about :D 3. I will :D
    – Jo.sch
    Feb 19 at 17:46
  • 1
    You want a SMTP-capable relay where you have control over the envelope. While this is possible from a technology perspective, practically this is a no go - it'll strongly impact your deliverability...unless it's a commercial-grade service with dedicated IPs similar to MC. In the latter case you're implementing and paying twice. AWS SES and Postmark are two commercial options. Free/DIY/OSS - Postfix.
    – identigral
    Feb 19 at 18:20
  • thank you for explanation. Yeah doesn't sound like something feasible to do. Maybe we will have to move to SES completely for those emails.
    – Jo.sch
    Feb 20 at 10:49

2 Answers 2

2

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.

5
  • 1
    We have many customers in the same bucket of a problem. There are only two choices: MC should send List-Unsubscribe for transactional emails or these emails need to be tagged as Commercial. That first choice is a philosophical question - should a customer be able to unsub from transactional emails? MC (current state) says hell no. ...but this whole thing might be a XY problem - MBPs' sender requirements for List-Unsub use careful wording of marketing and subscribed messages : Yahoo, Google
    – identigral
    Feb 19 at 16:11
  • The usual mess that is MC: it sends List-Help with transactional emails but not List-Unsub. Compromise, hooray! (Spoiler alert: the compromise is useless).
    – identigral
    Feb 19 at 17:19
  • @lukaslunow I did reach out to support and after some back and forth I got the answer that mails through transaction api do not need this header and also its not supported.
    – Jo.sch
    Feb 20 at 10:43
  • I wasn't really happy with the explanation from their side so I tried my luck here to get some more clarification. So what I get out of this is: SFMC messaging-api does not support our usecase and if for some reason starting april gmail will block us we are kind of ***.
    – Jo.sch
    Feb 20 at 10:45
  • @Jo.sch remember to mark my answer as accepted if it has been helpful Mar 13 at 7:21
0

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.

You must log in to answer this question.

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