As we've noted before, Mandrill uses a continuous deployment model, releasing new features as they are finished rather than batching them together for one, big, scary release day. This lets us get features out the door quickly without having all the debugging and operational challenges of having multiple potentially unstable changes hitting production simultaneously. There's one big disadvantage to this process - it makes it hard to figure out how to communicate these changes to you guys. We don't want to talk about things as they happen, since that's too chatty and most changes we make aren't that big, but if we do something awesome, we want you to know about it.
This post will be the first in a series trying to address that issue. Starting today, we'll post every Friday about the various changes to Mandrill that went live in the previous week. That's enough preamble, so let's get on with it.
Improved sending performance of large backlogs
Previously, if you were sending a large bulk email that was getting backlogged due to exceeding your hourly quota, we processed that backlog sequentially - one at a time. We've now changed things so that each user's backlog will be processed concurrently, so you should see that backlog counter drop faster if you have tens or hundreds of thousands of emails waiting for delivery.
MailChimp integration changed
If you use both Mandrill and our parent project MailChimp, you know that Mandrill and MailChimp were set up using single sign-on - you had one account that was shared between Mandrill and MailChimp. This seemed like a good idea at the time, but MailChimp and Mandrill's needs particularly around multiple users (available in MailChimp with v8) made this less desirable.
Now, Mandrill accounts and MailChimp accounts are separated. You can change the username and password of one without changing the other. Instead, MailChimp is treated like a linked application asking for an API key just like any other. There are no other changes to the integration. The discount for paid MailChimp is still the same as it ever was. We've just changed where the usernames are stored. More info on linking MailChimp and Mandrill accounts.
Heroku users can log in without Heroku
If you signed up for Mandrill by installing our Heroku app, you know that we also have a single sign-on system with Heroku. However, that setup conflicted with things like our mobile app that were expecting a regular Mandrill username and password. Now, Heroku users can set up a username and password for their Mandrill account, letting them log in using the standard login form instead of just through Heroku.
New SPF/DKIM testing interface
Setting up SPF and DKIM for a sending domain can be a confusing task. You need to track down your DNS provider, and use their interface (which is frequently confusing or misleading) to add a bunch of arcane TXT records to your domain. Then, you may have to wait as much as 24 hours for the DNS cache to expire before you can even see whether it worked or not.
To help with this necessary pain, we've overhauled our entire SPF and DKIM testing and validation interface. We'll query your DNS provider directly to make sure we've got the most up to date information available. We'll try to be smart about telling you not only what to do, but show you how your records need to change. On top of that, we've kept track of all the various mistakes that users and DNS providers tend to make, and we added custom messaging to alert you of common workarounds and fixes.
Added CSS inlining options
This one is near and dear to my heart. Forever, MailChimp has had the option of automatically inlining your CSS styles to make sure they're displayed properly (or as close to properly as they can be) in all email clients. We knew we wanted this feature for Mandrill too, but the effort involved in inlining CSS for each individual transactional email made our previous algorithms huddle in a corner and cry. We've built a custom algorithm for CSS inlining specifically for Mandrill, and it's now ready for you to use. It's turned off by default, since it will rewrite your HTML and maybe do it in ways you don't like or expect. You can turn it on by changing your sending options, by adding an inline_css flag to your /messages/send.json or /messages/send-template.json API calls, or by setting X-MC-InlineCSS to "true" if you use SMTP.
We're still being cautious about the potential load impact of inlining CSS in large documents, so for now CSS inlining will only work if your HTML document is less than 256KB. The vast majority of Mandrill's email is below this limit, but believe me the edge cases can get pretty wild.
Added user control of sending queue
If you've ever watched with horror as your well-tested code sent thousands of emails instead of, say, one or two, this is for you. We added the ability for users to pause their own sending queue. Once your queue is paused, you can clear out your queued mail and then unpause your queue. This also makes it easier to test your code, since you can pause your account, queue up emails for testing, and then clear them out without actually sending them.