[adrinavarro]

We choose SendGrid long time ago to unify all our mail infrastructure under one provider and it was a significant mistake. Now, we're heavily relying on SendGrid but some systems still depend on Mandrill and we're slowly migrating those as we make changes to them.

[WrathOfJay]

Please elaborate on why SendGrid was a significant mistake for you. We are looking at moving to them from Mandrill, since their stability has been terrible for us.

[adrinavarro]

Oops, sorry. Brain fart. I meant Mandrill, Mandrill was a significant mistake. SendGrid is working great for us. So sorry.

[kernx16]

I work at SendGrid, let me know if there any questions you have regarding our products.

[beager]

Was it the migration strategy that was a misstep or having a single point of failure for transactional email? If you're looking to support multiple transaction mail providers, any best practices you've come across to ensure that your app has a common interface to different providers?

[medmunds]

> support multiple transaction mail providers

One potential pitfall is keeping your blocked-email list synced between ESPs. You definitely don't want to repeatedly send to an address that has bounced or reported your email as spam, as that's a good way to get yourself into an ISP's spam filter for all its recipients.

When using multiple ESPs, the best approach is maintaining and enforcing your own block list. But if you're relying on your ESPs' own block list functionality to prevent additional sends to invalid/complaining addresses, you'll either need to sync their block lists, or somehow partition things so that the same recipient email always goes through the same ESP.

Nearly all transactional ESPs offer webhook notifications on bounces and complaints, but not all have an API where you can add an email to their internal block list.

[kernx16]

Why is that a mistake to rely on SendGrid?

[medmunds]

Not the OP, but my personal experience has been that it was a mistake to rely on SendGrid. This is based on a 2016 incident [1] where SendGrid made unannounced changes to IP pools, resulting in sent emails being delayed for several hours or more while the new IPs warmed up. For many kinds of transactional email, several hours' delayed delivery quickly turns into multiple end users opening support cases. ("Where's my password reset?")

If this had been a simple mistake, fine (all ESPs have occasional issues), but to my knowledge SendGrid has never acknowledged this as an operational error. In fact, at the time SendGrid representatives repeatedly insisted the change was made intentionally for its (paying) customers' benefit.

(That said, SendGrid had some really nice tracking and segmentation dashboards, which I do miss at my new ESP.)

[1]: https://news.ycombinator.com/item?id=12142728

[adrinavarro]

I meant Mandrill—Mandrill was a significant mistake. SendGrid is working great for us. So sorry.