I recently discovered Brevo, formerly known as "SendInBlue", when looking for a reliable eMail provider for transactional eMails as an alternative to Sparkpost as they have a more generous free tier and I'd had some deliverability issues to one provider in paritcular with Sparkpost.
It didn't take long to come to the conclusion that Brevo's service is wholly unsuitable for true transactional eMail, despite the lofty claims on their website.
The reason is simple, they add a List-Unsubscribe header to every eMail you send (even if it didn't come from a list) ... when I asked about this the reply from their support team was, frankly, farcical claiming;
"Unfortunately, due to GDPR reasons, it is not possible to disable the list-unsubscribe header"
We don't have a clue what GDPR is, I guess.
Ah yes, "GDPR reasons" or - in other words - we don't want to do it so want a convicing reason, lets fob them off with something that sounds official. GDPR, of course, nowhere in the 260+ page tome, mentions such things (and nor does PECR, which would at least be the more pertinent reason)
Simon, the Head of Deliverability & Anti-Fraud for Brevo replied to me on Twitter admitting that this was a completely inaccurate reason (but stopped short of actually apologising for their support team's ineptitude) instead siggesting that;
"we do not remove list-unsubscribe header from messages sent through SMTP or API, as not only transactional messages can be sent through those interfaces, but also campaigns. Both transac or marketing can't be easily distinguished from an email flow, so we are applying the list-unsub on any message sent"
Whilst this is a better answer, it's still not helpful. Other providers manage this with a simple flag like {"transactional": true} to classify the mail.
My use of the service was to send tickets for an online box office. Adding this header makes for a confusing (and poor) user experience...
Confusion ensues, let's unsubscribe from... er...
Why does my ticket have an Unsubscribe button??!
This leads the customer to believe they've been added to a mailing list even when they've NOT ticked the box that offered that very thing during the checkout process, so immediate distrust.
Not only that, if they *DO* hit the unsubscribe button the sender can no longer notify them of changes to the performance, or even cancellation.
Flying in the face of standards
The ridiculous thing is their insistance on adding this header to every eMail actually contravenes the IETF standard itself, RFC 2369 states clearly
These fields MUST only be generated by mailing lists, not end users.
So these fields have no business appearing on something that isn't from a mailing list...
The fact that an 'eMail provider' can't follow basic RFCs is enough reason not to use them IMHO, despite them proudly claiming to be used by some major companies.
They seem to offer a really good marketing product, which is fine, but to claim they offer "Transactional email" is nonsense, it's unusable.
Back to Sparkpost we go...