Mandrill Takes the Pain Out of Email Deliverability

Written by Steve Grunwell@stevegrunwell10 years ago

Share Tweet

Companies that have been on the web for any amount of time usually have stories to tell about email deliverability; while “99% of the emails we send are opened by their recipients” might not be as sexy as “we had five million unique visitors last month” or “our homepage loads in 700 milliseconds,” there are few ways to risk customers as quickly as your transactional emails not arriving (or worse, getting caught in a spam filter). Deliverability isn’t the first metric people consider as they start running their businesses online, but it’s certainly the one they hear most about from customers when things don’t go well. Fortunately, MailChimp offers a nice little service called Mandrill that makes sure your customers are never left wondering.

First, it’s important to recognize that not all emails are built equally. For the sake of clarity, let’s assume that all email falls into one of three classes: mass-mailing (e.g. your monthly newsletter), transactional emails (e.g. customer receipts, password reset emails, etc.), and individual emails (e.g. “Sarah sends Brad an email”). Mandrill is designed to serve transactional emails, which it does extremely well; after all, it’s run on the same infrastructure as MailChimp, which delivered 70 billion emails in 2013. The team has done its due diligence to ensure MailChimp mass-mailings get into as many inboxes as possible, and now they’ve opened up those tools for transactional emails as well. Best of all, it’s free for the first 12,000 emails a month (and super cheap after that).

Why is it so hard to deliver an email?!

Sending an email is a process that takes several steps through multiple servers, which leaves a lot of room for things to go wrong. As email SPAM becomes more pervasive with each passing month, email providers are forced to instate increasingly-rigid guidelines for what passes through and what gets sent to the big junk mailbox in the sky. Sometimes tiny mis-configurations are to blame: your app claims to be example.net when really it’s example.com, or you’re sending as example.com but the server is identifying itself as simply “example.” Certain email content can be flagged as being spammy (good luck to anyone legitimately selling cheap Viagra online), as can poorly-coded, image-heavy messages.

Your server’s IP address (a set of numbers that identifies your server’s location on the web) can also be to blame as spammers love to buy up cheap web-hosting, send out a bunch of spam, then move onto a new server. Once those IP addresses are released, they’ll eventually be re-assigned to a new server, meaning your blog’s IP may have once been used to send out a few million “CHEAP GUCCI HANDBAGS!” messages, securing its spot on email blacklists used by major spam filters!

These are just some of the dozens (if not hundreds) of factors that can cause your email not to be delivered, some of which are entirely out of your control. MailChimp has an excellent primer on the basics of spam filtering that should be a must-read for anyone sending emails to customers.

Setting up Mandrill

After signing up at mandrill.com, you’ll likely want to start by generating an API key, which is done on the “Settings” screen (the gear at the bottom of the left side). Generate a new API key, give it a description, and possibly limit the API key to a specific set of IP addresses and/or limit what the API key can be used for (I’d recommend restricting the key to your server’s IP address(es)) and only enabling the “Messages” set of API actions. For a simple web server sending out things like contact form notifications and “forgot password” emails, that configuration should be more than sufficient.

Next, you need to tell your application or server to use Mandrill. For most Linux servers, this article covers everything you need to route all outbound email traffic through Mandrill, which I find to be far easier to configure than per-application settings; let your app or CMS send through Postfix (a popular mail application on *nix servers), and tell Postfix to route it through Mandrill. Once you’ve set this up once or twice you’ll be able to configure new servers to send through Mandrill in a matter of minutes.

Sending domains

Though it’s not required, you’ll get the best results with Mandrill if you set up DKIM and SPF records for any domains you’ll be using to send email through Mandrill. This helps Mandrill and other servers down the line confirm that you’re indeed the owner of the sending domain (or at least have access to edit the DNS zone file), which increases your chances even more that your messages will arrive in your customers’ inboxes.

To add these records, simply follow the instructions on the Settings > Sending Domains page. You’ll need access to your domain’s DNS records in order to do so, of course, but the deliverability bump you’ll get will be well worth it.

Better understanding your email

Once you start sending emails with Mandrill, you’ll gain access to all kinds of useful analytics regarding the delivery, bounce, and open rates of your messages. These can be great for pinpointing users with invalid email addresses, seeing what email is being ignored, and more. You may also sign up for alerts about abnormal sending rates, billing thresholds, or an increase in bounce, rejection, and/or spam rates, all of which can hurt your sending reputation. More than anything, this detailed information about the emails being sent by your site or application increases your visibility to the automated messages being sent to your users.