Thoughts on Transitioning from Mandrill to Mailgun
April 24, 2016
As I’m sure you are aware, the April 27th deadline to switch off of Mandrill(or upgrade to a paid Mailchimp + Mandrill account) is approaching quickly. I’ve been using Mandrill for projects for some time now and overall have really liked the service. Its Magento/Mailchmip integration is really cool and painless and for the most part, deliverability has been fairly good.
However, back in February, Mandrill pivoted and announced that they were redoing their system to require all Mandrill accounts to have a paid Mailchimp account going forward. They gave users a rather short notice to either start paying for a Mailchimp and Mandrill account or switch to a different service.
I completely understand needing to charge for a service and would of probably been fine paying a monthly fee to use Mandrill(especially for its Magento integration,) forcing all my clients that are using it into a paid mailchimp account, especially when many use other services like iContact/Constant Contact/etc, didn’t sit right with me.
The Mandrill Pivot
Prior to February, Mandrill was billed as an:
Email delivery API from MailChimp
Mandrill is a reliable, scalable, and secure delivery API for transactional emails from websites and applications. It’s ideal for sending data-driven transactional emails, including targeted e-commerce and personalized one-to-one messages.
And, this is how I used it…as a way of ensuring better email deliverability than you can get using a random hosts sendmail functionality. However, the pivot resulted in the following new description:
Transactional Email for MailChimp
Mandrill is a transactional email API for MailChimp users. It’s reliable, powerful, and ideal for sending data-driven emails, including targeted e-commerce and personalized one-to-one messages.
So, as Mandrill was moving away from their initial use-case, I decided to also move away from it. Of all the people who I have using Mandrill, only one decided to stay with it and we may revisit that this week given how well Mailgun seems to work. In this case, the client actually used Mailchimp w/paid account already, so it wasn’t a big jump to also pay for Mandrill.
Transitioning to Mailgun
I suppose as a glutton for pain, I moved to yet another third-party service, this time choosing Mailgun, which was acquired by Rackspace several years ago. My reasoning for not wanting to roll my own transactional service, use the server’s sendmail tool, or just use SMTP on one of my email servers is mainly due to deliverability and, to a lesser extent, tracking/logging of clicks, opens, messages, etc. Of course, this could backfire if/when Rackspace decides to shut this down, but hopefully they will just eliminate the free version and convert it’s user’s to paid if that happens…not do a complete pivot like Mailchimp.
Overall, the transition has been painless and I actually like the web interface a lot more than Mandrill. It has a sane way to search the logs, SMTP responses and error codes are reported in a better and easier to understand fashion, and setup was easier. It feels like a much more mature web-interface.
Similarly, the PHP api was very easy to get working and I switched out all my Mandrill send mail functions to use Mailgun in no time at all. If anything, it is a bit simpler than Mandrill’s api. A couple of my sites were also using a WordPress SMTP plugin to send wordpress emails and switching those over to Mailgun’s SMTP offering was also painless.
First impressions of the service, website, and api are that it is a much better product than Mandrill. I’ll reiterate my hope that if it ever gets to the point that offering it as a free service doesn’t work out, Mailgun does a sane pivot to paid accounts, I would happily pay at this time.
Mailgun vs Mandrill Deliverability
I have not had any issues yet, although don’t have that much data. I will revisit this post in the coming months once I have been using it for longer and have more data to play with.
I imagine it can not be any worse than Mandrill, which sometimes silently failed, reported mails as sent that were not, and didn’t always properly report SMTP codes.