SendGrid – Awful Transactional Email Vendor

Update:  Near the end of the day, after the publishing of this post, and after waiting almost 8 hours, a different member of the SendGrid team reviewed what went down and reinstated our account.  He apologized and agreed our account should have been reinstated immediately.  At that point they released the nearly 1000 emails they had held hostage all day.

In the end, the SendGrid experience was beneficial as we switched to ElasticEmail.com.  That company has great pricing and even more importantly they have a sweet set of reports and tools which is allowing us to really improve our spam detection and mitigation processes.   Using SendGrid or Mandrill some of the problems we are discovering would never have been uncovered.  Thanks to ElasticEmail we have been able to implement some new safeguards that will reduce or eliminate any spam being sent through Lodgix.

Original post:

We’ve been using Mandrill for a couple of years to send our transactional email.  They provided a very high quality service at a cut rate price.   For whatever reason they have recently decided to change their business model and they left 1000s of transactional email customers holding the bag.   Which as a sidenote, also reflected very badly on Mailchimp.  We’ll not every use any product from that company again.  Although we were very happy Mandrill customers.

In our search for a new provider we ended up choosing SendGrid.  SendGrid was more expensive and has a bunch of lousy interfaces, but in the end they did the job, which was to deliver our many transactional emails to our clients and their guests.

Today however I woke up to discover that SendGrid had arbitrarily suspended our account.   They do this via email and they do it without warning.  Not only that, but they allow your API to continue sending email into Sendgrid where the email will be “queued” until their account review is finished.

The API does not return any error or any sort of notification which might alert development that there is a problem.   SendGrid shuts off your account with just one email to the only email they have listed for your account.  If that email goes to spam, or if that email is not delivered because SendGrid is the vendor responsible for delivering that email, than you are out of luck.   All email from your application goes into a wormhole at SendGrid.

We worked with a minion customer support representative at SendGrid named Christina.  It was obvious from her canned questions that she could barely uses her own email client much less attempt to troubleshoot why our service had been disrupted.

Thankfully our Mandrill account was still active so we were able to drop SendGrid and start sending through Mandrill again immediately which mitigated the SendGrid disruption.

SendGrid still has not restored our service, 7 hours later.   We have a 98% delivery rate and a spotless domain reputation.

The problem as relayed to us by Christina is that our app was sending spam.  She gave us some examples.  Turn out the app was not spending spam, rather we were forwarding my @lodgix.com email from our MX servers through sendgrid for spam filtering at gmail. Gmail has some great spam filtering tools and I get a ton of spam.  That spam, while not originating from Lodgix, was still being forwarded through sendgrid to gmail.   Since Christina at Sendgrid seems to be too incompetent to understand this, we reconfigured that email to go through enom rather than forwarding from our MX to sendgrid.

So just a heads up that if you are a company who has a heavy reliance on transactional email (not bulk email marketing), sendGrid is a very bad choice.  There are a ton of other services out there with far better customer service (they use zendesk which is awful and old) and which don’t willy nilly turn off your email send without some sort of discourse first.

They still have hundreds of our emails held hostage in a queue at SendGrid and they’ve offered no explanation or apologies for their actions.  It is all very strange, but yet not.  In the end, this fiasco showed us there are better alternatives then sendgrid on the market, and we learned to always have a Plan B and Plan C when it comes to transactional email, just as we do for the many other components of our application.