Skip to main content

We have Iterable set up with SparkPost integration. Currently, List-Unsubscribe is disabled in that account. Can anyone confirm whether enabling this feature in SparkPost will override the header emitted by Iterable?

From initial testing with the SparkPost Transmission API, I’ve found that you can send an email with transactional = true, include your own List-Unsubscribe header, and it is not overridden by SparkPost. This was done in a separate test SparkPost account with List-Unsubscribe enabled. With transactional = false (default), the header is overridden by SparkPost.



So, I'm wondering if Iterable has taken a similar approach.

Hey Ken!

Within Iterable, our unsubscribe urURL'ls are handled via API on the Iterable side in the sense that once a user clicks on a link, Iterable will track this unsubscribe and label it as one of the many unsubscribe events we have:

https://support.iterable.com/hc/en-us/articles/208508736-Unsubscribe-and-Subscribe-Sources-#types-of-unsubscribe-events.

There is a form of unsubscribe known as an ISP unsubscribe:

"Iterable received an unsubscribe email from the ISP, triggered because the user clicked the unsubscribe link near the top of the email (perhaps in a 

mailto
 header)."

This can result from the unsubscribe feature outside of the email, which most ISPs such as Google have the ability to unsubscribe without ever clicking on the email itself.

When it comes to ESPs such as sparkpost we typically use this as the sending platform for your sending channels, however, we don't depend on sparkpost as a means to handle unsubscribes since ESPs such as sparkpost are an option and not necessary to send within Iterable.

Let me know if this clears things up!

Cheers,

Elvis

Hi Elvis,

If I understand correctly, we can re-enable List-Unsubscribe functionality on SparkPost (for the emails we send directly through SparkPost), and it will have no impact on our Iterable-based emailing.

Thanks. We'll give that a shot.

Reply


Terms & ConditionsCookie settings