Bye bye, Mandrill! Dear Devs, what’s next?

MailChimp (the company that owns Mandrill) announced earlier today:

“Mandrill is becoming a transactional email add-on to paid MailChimp accounts instead of a completely separate product.”

If you use Mandrill, head over to MailChimp’s blogpost to read about the migration timeline. But after bidding adieu, most of us will have the same question as David Cramer (of getsentry.com fame):

Let’s start with the major contenders out there (listed in no particular order):

  1. Amazon SES
  2. SendGrid
  3. Postmark
  4. Mailgun
  5. Mailjet
  6. MailChimp (in which Mandrill will be available soon as a transactional email add-on)

Did I miss (m)any?

Now the answer can and will get as controversial as it can. Remember Mac vs PC, or Vim vs Emacs? But even if we keep flame wars aside for a moment, the case of transactional emails gets pretty complicated. Why? Because of the lack of consensus on the “true solution for getting emails delivered into the inbox”. In other words, the spam algorithms for different email service providers (such as Gmail or Outlook) are blackboxes. The exact implementation of these spam algorithms is unknown and it varies from one email service provider to another. And thus there is a lack of consensus on the “true solution for getting emails delivered into inbox”. There are no silver bullet solutions to ensure or even improve deliverability in user’s inbox.

For e.g. Postmark wrote a blogpost “The false promises of dedicated IPs” blaming other major transactional email providers for over-emphasizing the need of dedicated IPs. SendGrid refuted these claims by targeting Postmark in a blogpost. So, if you want to find the “true solution for getting emails delivered into inbox”, I suggest that you dive deep into how transactional emails work and then take a call. Rather than engaging in useless flame wars, it is better to review a list of requirements expected from a reliable transactional email service:

  • Reliable: A reliable service will ensure that your emails land in user’s inbox (rather than getting tagged as spam). Deliverability problems, if any, should only arise as a direct result of your practices/mistakes.
  • Scalable and Fast: The service should be scalable (millions or more emails daily for a single customer). And it should deliver these emails as fast as possible. This blogpost on Mandrill’s blog clearly outlines the importance of fast transactional email delivery. But almost every site will boast reliability and scalability as part of their sales pitch. How to tell which websites are trustworthy? Well, most of the transactional email services have a section on their website where they list the logos or success stories of their customers. You can use it to see which services are being used by high traffic sites run by big companies. You can also use one of the many sites like StackShare which list the different companies using different transactional email services.
  • Shiny interface: This is important if your marketing team would be involved in looking at delivery stats and graphs (to track growth). In this case, you might want to choose a site that offers detailed statistics with graphs in a easy-to-use interface. I know this is debatable, but I personally feel that SendGrid’s interface is more polished and shiny. You can look yourself at the user interfaces of both AWS SES and SendGrid to compare them side-by-side:
AWS SES’ interface v/s SendGrid’s interface
  • Cheap: This could matter if you are low on budget (i.e. in case of hobby projects or startups). A quick survey seems to indicate that Amazon SES is the cheapest of all the major contenders listed above.
  • Features: Different services provide different features. For exampls, AWS SES provides just a barebones interface with basic reports and graphs, API, delivery confirmations and a few other features. On the other hand, Mandrill’s current offering (as of February 25, 2016) includes API, delivery confirmation, dedicated IPs, searchable activity log, tracking options, tagging, split testing, detailed reports, templates, custom domains, wrappers and many other features. Thus, for example if you need a barebones interface but cheap solution, then AWS SES is the way to go.
  • Controversial features: As discussed above, SendGrid and Postmark had a public debate about dedicated IPs in transactional email services. From what I understand, there is no consensus on many controversial features like dedicated IPs. For such controversial features, understand the implications of using or not using the feature and then choose a side.

I hope that you would have realized by now that the answer to the question “SES vs SendGrid vs Mailgun vs foo vs bar” will be different for every product (based on the features expected by product’s team from a transactional email service). Some might want to choose the one that’s cheaper. Others might want to choose the one that boasts a “good customer list” or the one whose “dashboard looks more shiny”, like David Cramer did:

In the end, you should take the final call based on your requirements. I personally would use and recommend SendGrid or AWS SES.

Bonus protips: The art of getting emails delivered to email inbox is widely misunderstood. For starters, sending transactional/promotional emails with just one big image will cause a high bounceback rate. There are many such best practices in the transactional/promotional emails world which must be followed if you want to get email delivered to user’s inbox (instead of spam). Most bulk email services maintain documentation about the same in whitepapers, knowledge bases, docs etc. (e.g. MailChimp’s Knowledge Base, AWS SES Best Practices Whitepaper etc.) Read and understand such docs if you really care about growth for your product.

PS: On an unrelated note, what really intrigued me is the following line in MailChimp’s announcement:

“Startup developers looking for a cheap, reliable transactional service may want to consider Amazon SES.”

Wait what! Did MailChimp just referred thousands of customers to Amazon’s SES just because the new MailChimp+Mandrill combo might be more expensive to use? The new MailChimp will still allow users to send transactional email using a Mandrill addon. Conventional (and evil) sales wisdom suggests that MailChimp should have justified the increase in pricing using (pseudo-)features. This is what sales pitches are for. I know that it isn’t unusual for big companies to refer customers to new services when they are shutting down one of their products, but Mandrill isn’t exactly being shutdown. I can’t resist the temptation to thank MailChimp for honest advice in this case!