Update (3/16/16): Mandrill is now an add-on for paid monthly MailChimp accounts, and is no longer available as a standalone service. Existing Mandrill users have until April 27, 2016 to merge their Mandrill account with a MailChimp account. See this article for additional details, including pricing information and instructions for merging your accounts.
Update (3/4/16): SparkPost has offered to take on any departing Mandrill users and to honor Mandrill’s pricing for those users.
Update (2/25/16): We’ve published an FAQ article in Mandrill’s Knowledge Base that provides more information about the transition. We’ll continue updating that article as new questions arise.
Today, we’re emailing our customers to announce some significant changes to Mandrill.
Going forward, all Mandrill users will be required to have a paid monthly MailChimp account and verify ownership of all sending domains. Here’s the timeline: Starting 3/16, all new Mandrill users will create accounts through MailChimp, and current Mandrill users can merge their existing Mandrill account with a monthly MailChimp account. Current users will have until 4/27 to merge their accounts.
Why we’re making this change
The MailChimp team built Mandrill in 2012 as a transactional email tool. It was a startup within MailChimp that functioned as a completely separate product. Mandrill is now becoming an optional add-on to paid MailChimp accounts. This is a strategic change we’re making to close the gap between the two products. MailChimp is designed for marketing, and Mandrill is designed for transactional messages. Each is powerful on its own, and offering Mandrill as an add-on makes MailChimp even more powerful for our small business and e-commerce customers. Our CEO and cofounder Ben Chestnut wrote more about the changes on the MailChimp blog.
We're pushing a change today, August 4, 2015 at 12:00pm UTC (see this in your time zone), that makes domain verification mandatory when you add a new sending domain and set up SPF and DKIM. This change won't be applied retroactively, so if you added a domain to your Mandrill account before today and set up SPF and DKIM, we'll still sign your mail as usual. However, we still urge you to verify any sending domains for your account.
Mixpanel is an analytics platform that lets you access detailed data from your website or app, focusing on actions your users take, rather than only showing page views. This means you get powerful data you can manipulate and analyze to get a better understanding of how your users interact with your application or website. Then, you can leverage all of that data and set up sophisticated segments to target your users based on their unique behavior.
Now, thanks to the Finc3 Mixpanel Mandrill Connector, you can easily connect Mixpanel and Mandrill to take advantage of Mandrill's trusted delivery infrastructure and send trackable, templated emails based on relevant user actions.
We recently rolled out some improvements for previewing templates in the Mandrill web interface. Now you can preview all of your templates at a glance, and there are no more pesky pop-ups!
At Mandrill, API uptime is essential. We have to ensure all the pieces of our architecture are happy and healthy. When they're not, we need to take them away quickly and automagically so they don't negatively impact our users. We accomplish the automagic bits using some off-the-shelf tools and our own homegrown tooling we call "Pulse."
Configuration management has seen massive improvements recently. You can take your pick between any of the popular tools—Puppet, Chef, Ansible, Salt, my-custom-bash-script.sh, etc.—and all will get the job done, but one question that these tools haven't fully answered is the idea of service discovery. We needed some tooling to tie together deployment, configuration management, and service discovery. And thus, Pulse was born.
Earlier today, we notified some of our customers of a security vulnerability we discovered in Mandrill’s infrastructure. At this time, we’re confident that no customer data was compromised as a result of the vulnerability, but we feel it’s our responsibility to let our customers know exactly what happened and what we’re doing about it.
Since this issue only applies to Mandrill accounts that were used between February 6 and March 10, we emailed everyone who may have been affected. If you didn’t get an email from us today, that means you weren’t affected. For other Mandrill users and affected users who choose to notify their own customers about the vulnerability, this post explains what happened.
As a Mandrill support analyst, I get a lot of questions from users looking for quick and easy ways to send triggered emails based on a customer’s interaction with their application or site. For example, they may want to send a series of onboarding emails to new customers to help them get the most out of important features by including tips, tricks, or tutorials. Our webhooks are a powerful way to get the data needed to trigger these types of interaction-specific emails, but they’re only one piece of the puzzle. It’s still necessary to create the logic to handle those triggers, and that’s not always feasible for smaller teams or for those who don’t have the development resources to set up and maintain that kind of advanced logic.
In November we quietly rolled out a new template language using Handlebars to support more complex dynamic content and templates. Since a full email strategy often involves different people—from developers to marketing to content editors (and more)—templates help separate data about an order, for example, from the formatting and style of the email. Handlebars gives your entire team more control and flexibility, including support for iterating over a collection (loops) and conditional data.
If you want to start using Handlebars right away, check out our documentation to see what's supported, or skip ahead to examples. If you're interested in learning about why we added a new template language and our process for releasing it (including why we didn't announce it from the start), read on.
Update December 17, 2014, 4:55pm EST: As with most changes in Mandrill, we rolled this one out using a progressive migration from our smallest region to our largest region while monitoring server loads, error rates, and user feedback through support channels. While our initial estimation that a fraction of users would be impacted was correct, the severity of that impact in some cases was more greater than anticipated.
The initial changes we made included updates to both our root certificate and intermediate certificate chain, so that everything used SHA-2. This resulted in errors, particularly for users in shared hosting environments where SHA-2 is supported, but the root cert bundles couldn't be updated in a timely fashion. We've partially rolled back this change to a configuration with a SHA-1 root, and SHA-2 intermediate certificates, which should address the majority of issues users were reporting. We'll continue to monitor the status of this, and provide further updates if necessary.
Next Wednesday, December 17, 2014, we’re making some updates to Mandrill’s SSL certificates to ensure they’re no longer using SHA-1 hashing algorithms for signing. The change is anticipated to impact a very small number of users — those using an older server, and more specifically, an older SSL client library.
Yesterday, Google released information about POODLE, a serious vulnerability in SSL version 3.0. This vulnerability can't be used to gain unauthorized access to the Mandrill infrastructure, but in theory a malicious network operator could use it to eavesdrop on encrypted communications. We're updating Mandrill's infrastructure to protect against this vulnerability by completely disabling support for the SSLv3 protocol.
2014 brought the announcement of several high-profile vulnerabilities in specific widely-used encryption libraries. But POODLE is different—it's a flaw in the protocol itself. SSLv3 was released in 1996, and should be considered obsolete and unsafe. TLSv1, the successor to SSLv3, was released in 1999—15 years ago. Newer versions of TLS are preferable, but TLSv1 provides an acceptable, safe baseline.
Unfortunately, disabling SSLv3 may cause compatibility problems for a very small amount of traffic on the Internet—well under 1%. We don't take this lightly: breaking compatibility is always a serious concern. In this case though, leaving SSLv3 enabled would risk exposing our users to eavesdropping by malicious actors, and we're simply unwilling to take that risk.
As of Wednesday, October 15 at 20:00 UTC, SSLv3 was disabled for all API and SMTP traffic received by Mandrill. SSLv3 for webhooks was disabled on Thursday, October 16 at 17:00 UTC. We're evaluating the impact of disabling SSLv3 for all outbound mail that uses opportunistic encryption, and will post an update once that is complete.
At MailChimp, our motto is "Listen Hard and Change Fast." The need for fast iteration permeates every aspect of our culture, including how we deploy code changes to our production servers. We found some unique challenges iterating quickly on an infrastructure service like Mandrill where stability and 100% uptime are absolute requirements. After two years and over 1,200 successful automated deployments with no scheduled downtime, here's what we've learned.
If you've logged in to the app in the last week, you've probably noticed that we've given the Mandrill web interface a bit of a facelift. The new layout brings navigation changes, is responsive, has a slight visual refresh, gives the content section of the application more screen real estate, and sets up a better base for new features and updates coming in the next few months.
Email is serious business. We take pride in being the fastest-growing email as a service platform, but we put just as much work into security as we put into the features and performance that drive that growth.
Between the ongoing revelations about widespread communications surveillance, and recent high-profile security issues such as the Heartbleed OpenSSL vulnerability, we're happy to announce a handful of significant new security features at Mandrill. We'll also talk a bit about the security-centric philosophy that has guided product development at Mandrill for the past two and a half years.
We recently enabled opportunistic TLS for all mail sent via Mandrill. This means that we'll attempt to use an encrypted connection for every message that we send. Internet surveillance typically involves widespread collection of data as it is being transmitted, which is ineffective if encrypted connections are used. Unfortunately, while support for TLS is growing, it isn't everywhere yet. Some recipient servers don't support TLS at all, and others are misconfigured—in these cases, we'll fall back gracefully to an unencrypted connection.
Google's Email encryption transparency report is one method of verifying TLS support for the mail we send.
This week we've added a couple of small features to help you keep track of what's happening in your account. You can now see a log of IP addresses that access your account and you can receive weekly and/or daily account activity emails.
IP Access Logging
IP logs are a great way to see where and how your account is being accessed. For security, you can see that strange IP in a foreign country that accessed your account. And then make sure if it wasn't one of your colleagues, block them from your system and/or limit your API keys. For debugging, you can confirm whether your servers connect to Mandrill at all. IP information has been available in your account's API Logs, but only for the last 100 calls - not very useful, especially for non-API access.
The new Account Security page in your Mandrill Account includes a list of the IP addresses that access your account, with the following details: geo data, first time accessed, last time accessed, and whether the IP was used to access your account through the API, SMTP, or the web interface. Since you can track trends by location as well as method, and because Mandrill lets you create API keys distinct from your account password, you can get a broad picture of whether you need to take action, and what actions to take.
Two years ago Mandrill began as a skunkworks project at The Rocket Science Group. Chad wrote about the risky decision to build a separate team and a new product. Sensible people would just tack on some new APIs or bolt some seemingly-new features on to an existing product instead of conceiving a new team or platform. Sensible people would set small, attainable goals instead of ones that start with being the best and most widely-used Email As a Service product. Fortunately, we’re not sensible people.
Two years in
In just two years, Mandrill grew from a skunkworks project to a product that outperforms similar services and beats the competition in a feature by feature comparison. Today marks a milestone in Mandrill’s growth as we sign up our 250,000th active user, making Mandrill the largest EAAS platform by a fairly wide margin. Mandrill’s active user count isn’t just ahead of our competitors; our user growth rate consistently outpaces competitors, pushing Mandrill further ahead of the pack. According to data from Datanyze, Mandrill is the fastest growing EAAS platform since February 2013.
Not bad for two years.
You might think most of those 250,000 users come from MailChimp's 6 million users. We thought the same thing! When Mandrill started, we expected a lot of crossover. Turns out the audiences are completely different, and we had to re-think our entire approach. Mandrill’s a team that likes challenges though: this one just meant Mandrill had to earn these users on our own.
Ultimately, our users are this milestone, and we're grateful for each of you who have joined us, whether you joined when Mandrill was in beta, signed up today, or somewhere in between. If you used Mandrill in the last two years, thank you. If you gave us a high five, reported a bug, offered your feedback, or shared your business or idea with us to figure out how Mandrill could fit in to your vision, thank you. Thank you for letting us earn you as a user. We know that’s just the first step, and we’ll also need to continue to earn your support and trust.
While this growth is exciting, we’re far from claiming success. We know there are more features, more improvements that we can build to improve our service offerings. We accomplished a whole lot in two years, but we’re buckling down (and hiring) so we’re ready for what the next two years mean for Mandrill and our customers.
This week we have a couple of features and refinements for increased account security: a new option for two-factor authentication along with new and revised account alerts. We also improved webhooks to handle intermittent errors more gracefully.
SMS Option for Two-Factor Authentication
Last week we added two-factor authentication, using Google Authenticator or YubiKey, as an extra layer of security for logging in to your account. SMS is now available as another two-factor option. You can enable all three options, so you can use SMS as your primary method of two-factor auth or as a backup if you don't have your YubiKey handy.
It's not Friday, but it's still time for some features! We've added two-factor authentication so you can protect your Mandrill account using Google Authenticator or YubiKey, and we've added blacklist webhooks so you can sync your Mandrill blacklist with your internal application database.
For many applications, email is the most common and sometimes only way they talk to their users. An attacker seeing the contents of those messages or sending phishing emails can be devastating. To add another layer of security protecting your account, we now support two-factor authentication using Google Authenticator or YubiKey.
On Monday, the OpenSSL project released an update to address a serious security vulnerability nicknamed "Heartbleed". This vulnerability impacts the encryption used for internet communications and could allow access to decrypted HTTPS traffic. Like many service providers, once Mandrill became aware of Heartbleed, we moved to address, and evaluate the impact of, this vulnerability. We know that our users share our concern for security and privacy, so we want you to be aware of the specifics of Heartbleed vulnerability as it relates to Mandrill.
First and foremost, we have no evidence that the Heartbleed vulnerability was used to obtain any Mandrill data or to access Mandrill services.
Mandrill's relay and application servers were using affected versions of OpenSSL. Patches have been applied to all impacted servers, a process which was completed and confirmed by 14:00 UTC on April 8th. Although Mandrill utilizes Amazon EC2, we don't use the disk images provided by Amazon that were found to be affected. Nevertheless as a precaution, we've replaced our private key and SSL certificate since it's plausible that Mandrill's certificates could have been exposed.
What you should do
While there's no indication that Mandrill user data has been impacted, we strongly recommend that users update their Mandrill account passwords. Since API Keys are used for accessing your account via the API and SMTP, we also recommend deactivating old keys and replacing them with new keys.
Many of our users have sites or applications hosted which store their Mandrill credentials or other sensitive data. So, we also recommend auditing all services you may use to determine if they are also vulnerable, taking steps to repair any vulnerable services, and replacing SSL certificates once the vulnerability has been removed.
Update April 12, 2014: Yahoo has confirmed the DMARC change in an official statement. There appear to be no plans to revert this change. If you're using yahoo.com in your from address, it's advised that you use an alternate 'from' email domain. For now, a private domain or other free email provider will work, though a private domain is preferable since other free email providers may follow Yahoo's lead.
Update April 22, 2014: AOL has announced changes to their DMARC policy as well, so you'll want to use alternatives for AOL addresses in the 'from' field as well.
Late last week, Yahoo! quietly made a dramatic change to the DMARC policy for yahoo.com that impacts senders who use services like Mandrill or independent mailing lists to send 'from' @yahoo.com addresses. Yahoo hasn't indicated exactly why they made this change, but it may signal other changes from email providers that are yet to come.
If you're sending through a service like Mandrill, you can generally use your own email address as the 'from' email address. For site and app owners, this is usually an address on their domain. For some use cases, though, the 'from' address might be a personal email address like a Gmail or Yahoo address. Email's generally designed to allow this - you can send 'from' an email address through any server on the internet.
It's been a busy couple of months here at Mandrill. After a soft feature freeze in November, we've been working on scaling the application to put us on a solid footing for future growth. In the past few months, we've set up dozens of new application and database servers and migrated terabytes of data, without taking the application down for maintenance - even for a minute.
This week, we're coming out of the freeze with a handful of new features that we've been working on. We're excited about the foundational improvements that we're making, and we'll talk more about those in a future post. But for now, it's Friday, which means: features!
Rejection Blacklist Imports
We've added some additional options for importing rejection blacklist entries. It was always easy to add multiple email addresses to the rejection blacklist via the API but the UI only allowed you to add addresses one at a time. Now you can add multiple addresses at once or you can upload a text file containing a large number of addresses (each address on a separate line).
The Mandrill team has spent the last several months adding a bunch of great features each week, like resending messages, subaccounts and demographics. We've also added some pretty innovative features that you don't normally find for transactional emails, like the rules engine, split testing and our executable API docs. With each release we've worked hard to make sure the interface for using them is well designed and easy to use, whether you're accessing them through the Mandrill web application or the Mandrill API.
However, one problem we've encountered with the speed we've been releasing is that some features have been available through the Mandrill UI a week or two before they're accessible through the API (and sometimes vice versa). While we have some big, new features in the works, we also want to kill that time gap when they're ready. In order to do that, we're going to slow down for a couple of months and work on a making Mandrill's foundation even better for future innovation.
This week, we have a few small improvements to announce. You can now retry recently soft-bounced or delivered messages to help diagnose delivery problems, and rules options have been further expanded to allow multiple actions per rule and more sending and tracking options.
Most of the time, email works predictably. If the email address is valid and the message isn't spammy, it'll be delivered as expected; otherwise it'll bounce with an error message. Most of the time, resending messages is a waste of time - the result won't change. But sometimes messages fail when they shouldn't or don't deliver when they say they do. When that happens, you usually need to try resending the message to verify the problem, and then resend the message at least once more once the problem is fixed.
Instead of doing this manually, you can now ask Mandrill to resend these messages for you. As long as we have the content available, you can tell Mandrill to resend any message that is marked as soft bounced or delivered. We'll send a new, duplicated message that will be tracked and logged separately from the first one, so you can easily see whether or not resending the message helped.
This week, we have a few small improvements to announce. Rules options have been expanded to give you more control over your sending, Cc and Bcc options have been added to the sending APIs, and message content is now accessible through the API.
Expanded Rules Options
Mandrill's rules engine lets you modify the content and behavior of messages based on general criteria, like the sender address or the API key used to send the message. New options let you change the subaccount, tracking domain, SPF/DKIM signing domain, and Return-Path domain of messages that match your rule criteria. This is a good option if you can't change the SMTP headers or content yourself -- for example, if you're using a CRM or third-party system that doesn't allow you to add custom headers.
We're still working hard at improving the scalability of the Mandrill backend to support our amazing growth (thank you, by the way), so we only have one small treat for you this week.
Expanded API Functionality: Inbound, Tracking Domains, and Template Labels
You can now access and control even more of Mandrill's functionality programmatically using our API. We've added API support for inbound domains and routes, custom tracking domains, and template labels. If you're using an official Mandrill API client, you may need to update your client to a new version before the new calls and parameters will be available.
If you want to know more about what these API calls can do for you, information can be found in the knowledge base and api docs.
We've been hard at work on some larger backend changes, but still have a highly requested feature for you this week.
Check your templates against multiple email clients
A while back we added a Litmus integration to offer spam filter testing for your email templates. This is great for helping deal with the quirks of ISP spam filters, but making sure your email looks right once it gets into the inbox can be just as important. Since testing emails in multiple clients and browsers can be insanely time consuming, we've expanded our Litmus integration to include email client testing. You can test any template against a combination of 30 clients/browsers for $3 per test.
This week is about making it easier to find the things you need. Template labels allow you to easily organize and find templates in the web interface and contextual help allows you to get relevant information where you need it.
If you're managing templates for several clients or just have a lot of your own, it can get a little cumbersome to find the one you're looking for using just the template name.
We've made a few improvements to the app this week. We've separated the rejection blacklist for each subaccount, and we've added more API calls for managing custom DNS names for dedicated IPs.
Subaccounts are a great way for senders to protect their reputation when they send on behalf of many others. Mandrill will track each subaccount separately, with distinct reputations and quotas. We've now added a separate rejection blacklist for each subaccount. Any bounces, spam complaints, or unsubscribe requests Mandrill receives for an email will only by applied to the sending subaccount's blacklist. Other subaccounts will still be able to send to that recipient without issue.
We're still working away on a number of backend projects, but we've made a few improvements to the app this week. We've added an entire suite of API calls for managing dedicated IPs, and you can now use API keys as a condition for rules.
Manage Dedicated IPs via the API
We've added extensive API support for managing dedicated IPs. You can now list, provision, and remove dedicated IPs directly via the API. You can also move IPs between pools and enable or disable warmup mode. Finally, you can list, create, and destroy IP pools.
The new API calls are all located in a new
ips namespace. You can use them to integrate dedicated IP management directly in to your application.
This week we've been working on a host of backend projects, but we've still got a couple of nice improvements for you. We've added the ability to search and filter activity based on an API key and added API calls for managing your sending domains.
Activity filtering by API key
Starting now, we're auto-tagging your emails based on the API key used to send them. This allows you to filter by API key in the dashboard, activity view, demographics and other pages where you can filter based on system tags like sender and template. Showing the API key willy nilly around the app didn't seem like a very good idea so you'll notice that we're not listing the actual API keys in the filters, but using your API key description instead. If you'd like to filter by an API key, but it doesn't have a description yet, you can add one on the SMTP & API Credentials page inside the app and it'll show up in the filter.
We have some major new features for you this week. Subaccounts let you manage and control your own users' email, Custom Reverse DNS lets you fully whitelabel your dedicated IP addresses, and Bounce Forwarding lets you integrate Mandrill's bounce handling with third party systems without using webhooks. Finally, SMTP Events now have more detail to help you troubleshoot delivery issues.
One of the biggest challenges of running an email service is the anti-abuse system. It only takes a handful of bad users sending spam to cause everybody's messages to be delayed or even blocked. Mandrill's reputation and quota system works well to protect Mandrill users from each other, but if you have multiple users of your own sending through a single account, sending for all of your users could be impacted by one or two less-than-stellar users in your account. Subaccounts let you leverage Mandrill's reputation system for your own users' email. Here's how it works:
We have a few refinements for you this week. Custom Return Path Domains whitelabel your emails more completely, SMS Alerts add a new option to help you keep an eye on important changes to your account, and Alert Logging provides a snapshot of triggered alerts for your account.
Custom Return Path Domains
The Return-Path address for your emails is where things like bounces and other delivery events are sent. It's also known as the "envelope-from" or
MAIL FROM address. (For Gmail users, the
mailed-by header typically is generated from this address). Until now, this address was a subdomain of mandrillapp.com, but we now allow you to use a custom domain instead, to more completely whitelabel the emails you're sending. All you need to do is use a CNAME for a subdomain you control and point it to mandrillapp.com.
Because a custom return path domain is just a CNAME to mandrillapp.com, existing tracking domains can be used as return path domains. We recommend setting up a distinct return path domain in order to make it clear that it's a domain that sends mail. More information on custom return-path domains.
We have a few refinements for you this week. SMTP events give you all the detail on individual email delivery, alerts have been polished to have more options, and centralized documentation makes it easier to see everything Mandrill can do for you in one place.
In addition to deferral details launched last week, the activity log now includes detailed SMTP information for delivered messages, too. Each log entry includes a timestamp and the response message we received from the mail server where we tried to deliver the message. These logs help you confirm when a receiving server accepted a message for delivery. They're also useful for debugging delivery problems that occur after messages have left our system, since ISPs and hosting providers often need diagnostic messages to track down what happened to a message after it entered their system.
We have a combination of new features and polishing for you this week. Deferrals give you detailed information to help troubleshoot specific addresses that are having trouble receiving mail, neighborhood comparisons show you how your sending stats compare to the rest of Mandrill users and the revised Account section makes it easier to get a quick overview of your account.
We do everything we can to deliver messages within seconds, but sometimes we run into roadblocks. The recipient's account might be over quota (even in the days of multi-gigabyte quotas, that still happens!), or the receiving server might be experiencing some other general problem. In cases like this, there's nothing we can do to make the message send more quickly, so we queue it and retry automatically. To keep you informed of delays like this, we've added a new
deferred state for messages so you can see exactly why the delays occurred.
The details of the delay, including the timestamp and the error message that caused it, are available in your activity log and in the
messages/info API calls. We've also added a new
deferral event for webhooks so you can integrate this data into your applications, and we've added deferral support to the rules engine as well.
This week we focused on improving and polishing existing features. The timeseries search API lets you get aggregate email stats based on a search query, demographics data is now searchable in the activity log, and geolocation reporting now includes states and provinces.
Timeseries Search API
The activity log interface lets you see an aggregated delivery and engagement timeline for all messages matching a search query. We're now making this information available to your applications through the API. This query gives you the same fidelity of statistics that our API provides about tags, but for arbitrary search queries. You can find more information about using this call in our API docs.
We've been focused on backend projects this week, but we still have a couple new features for you. Template live preview lets you see exactly what your template will look like while you code it, and recipient demographics give you aggregate stats on your recipients' operating systems, email clients, and locations.
We've taken our existing geolocation and user agent data and made it more accessible by adding a simple aggregate demographics report. You can see if your recipients are nerdy lovers of Linux, or maybe most of your opens are coming from mobile devices - reminding you that you need to make your template responsive. You can also filter this aggregate data by tag and by date.
We have a small batch of new features for you this week. Reputation improvement helps you understand the factors leading to poor account or tag reputation, reputation history has been expanded to include tag-specific reputation, the NodeJS API client has been added to the API docs, and we've integrated support into the Mandrill application.
When your reputation starts dropping, it can sometimes be hard to understand why. Mandrill uses a large number of factors to determine your account or tag's reputation, and it's not always obvious what the major problems are. Starting this week, accounts and tags with poor reputation will include a section breaking down what the major problems are along with information on what you can do to improve. We've also published a series of guides about common reputation issues in the knowledge base.
Happy 4th of July to all our USian friends out there. We have another handful of features for you this week. Tag-specific reputation lets you break down your reputation by email type, reputation history helps you understand how your reputation changes over time, and we've expanded access to message data using the API.
We've expanded the reputation system to calculate distinct reputations for each of your tags. This gives you much more detailed information about how your mail is performing, and can help pinpoint reputation issues that might be harming your overall deliverability. For example, a specific tag with a high complaint rate might not harm your account's reputation as a whole, but the complaints will definitely hurt your deliverability, especially as more and more ISPs use content and engagement to make filtering decisions. Reputation problems tend to go hand in hand with unhappy recipients, so if you can identify and fix up specific types of your mail that are causing problems, everyone will be better off.
We have another handful of powerful features for you this week, including one of the most requested features for Mandrill since we started. Test mode gives you a way to generate fake events and test your integrations without actually sending email or affecting your reputation and URL patterns and tagging provide you with more powerful click reporting.
Test Mode (Sandbox)
We've added a test mode to make it easy to experiment with Mandrill and fine-tune your integration for things like bounce handling without actually sending email and potentially damaging your account's reputation or racking up usage fees.
When you're logged in to your account, you can flip your current browser session into test mode by accessing the account menu in the top-right corner. This won't affect normal sending for your account via API or SMTP. When you're in test mode, the top navigation bar will turn orange, and you'll see separate stats and activity. The main difference between normal and test mode is that no mail is sent in test mode (so you won't be billed for actually sending and your account reputation is unaffected by activity in test mode). Add-ons like spam filter testing, scheduling, and extended content storage still function in test mode, and they incur the same usage fees as in normal mode.
It's been a big week here at Mandrill. We hit 65,000 users and we've added a handful of powerful new features. Scheduled emails enable a number of sophisticated autoresponder-like behaviors, and stats comparisons now provide even more details about your activity. We've added some quick tips to make searching easier, and geolocation and email client info for opens and clicks are now available in the activity log.
Now, when you send an email through Mandrill, you can specify when it should be sent. We'll store the email and take care of sending it. We haven't invented time travel yet, so we can't send messages back in time, but we've got the future covered.
Scheduling an email is simple: using the API, just set the
send_at parameter to indicate when the message should be sent. For SMTP, use the
X-MC-SendAt header. We've also added API calls to search, reschedule, and cancel your scheduled emails.
Because of the additional storage required, an additional fee applies for using this feature. Scheduled emails cost $0.05 for every thousand emails scheduled, plus an additional $0.02 per thousand emails per day for storage. More details are available here.
We've got a couple of exciting features to announce this week. A/B split tests give you new ways to test and improve your email content, an improved editor makes it more enjoyable to craft templates, and access to raw bounce messages helps troubleshoot tricky delivery problems.
A/B Split Tests
A/B split tests give you a powerful new capability to easily track and optimize the engagement your users have with your email content. This has been a standard feature for years in bulk email products, and now we're offering it for your transactional email, too. Here's how you use it:
First, decide which emails you want to test by specifying a tag. If you don't want to test all the emails with that tag, you can also set a random sample percentage to test against.
We've got a lot of projects currently in the Research & Development phase, but we've still got some cool new features to announce this week. We've overhauled our API docs to support multiple programming languages, added flexible traffic splitting for dedicated IPs, and improved session handling.
Integrated API Client Documentation
Reading API docs when trying to integrate a service into your application can be a confusing process. Part of this is because the actual interface you're using as a programmer usually isn't the raw protocol. It's a library that is generally similar to the API but just different enough to be annoying. This can lead to mental contortions trying to map between what's in the API docs and how the library implements the call. We're trying to reduce that confusion by integrating our official API client libraries into our API docs.
What a week! We've added powerful dedicated IP management tools, improved stats comparisons, and made it easier to troubleshoot webhooks.
Dedicated IP Management
Dedicated IPs give you a lot of control over your sender reputation, but they also require more careful management as your traffic starts growing beyond what a single IP can handle. Without warmup, a new IP can experience delivery problems, even if you haven't changed anything else about your email.
To make it easier to transition to using a dedicated IP, or multiple IPs, we've added an automatic IP warmup feature. When you purchase a new dedicated IP, you can choose to start warming it up immediately. With automatic warmup, Mandrill starts sending a tiny percentage of your email over the new IP, and slowly ramps that volume up over the next 30 days. If you only have one dedicated IP, we'll continue to send some of your mail over shared IPs until the month passes and your IP is fully warmed up - we do this because our shared IPs are already warmed up enough to send huge amounts of email daily.
You can also switch an existing dedicated IP into warmup mode at any time, which is useful if you want to reduce the traffic that an IP is sending and then slowly ramp it back up over time.
This week, we've focused on giving you more power when sending and helping keep your account secure. With additional conditions for the rules engine, you can set up more complex schemes, including automated split testing. You can also IP- and scope-limit API keys, and add more dedicated IPs to your account.
Rules give a sophisticated (but non-programming) user a way to change the behavior of their transactional email. A common request is the ability to handle automated split testing without requiring changes to the sending code. We've added features this week for managing rules that make automated testing possible, as well as help manage your rules more effectively.
The fact that each rule can only match one event and take one action causes a lot of repetition as the same conditions are duplicated between different rules. First, your rules can refer to other rules in their conditions. For example, here are rules that send Gmail password reset emails to a webhook:
Since you can now set up rules that are only meant to be used as conditions in other rules, it's important that these nested rules don't accidentally modify your emails or trigger webhooks accidentally, so we've added a new action for rules called "do nothing." This can be used any time you want to keep a rule around, but don't want it to take any action.
This week, the Mandrill developers have been busy adding new features based in large part on what users have been requesting and where we've seen user questions. We've added extended content storage, a way to easily add unsubscribe links, more details about rejections, and (more) webhook testing.
Extend Content Storage
Not too long after Mandrill launched, a lot of users asked for a way to view the actual content being sent instead of just metadata about the messages. We added a quick option to view the contents of emails for 24 hours after an email was sent. This is generally long enough if you're doing a quick audit while testing or occasionally as you're sending more volume. For some users, though, viewing content is used for troubleshooting or to help their support teams confirm information contained in emails, so having access to the content for longer periods of time is really important.
Happy birthday, Mandrill! After devouring perfect bananas for the past week, we have some new features to share.
Bulk data export
It's pretty easy to amass a ton of data in your Mandrill account. Users have been asking about the best way to get that data back out, and so this week we created a set of tools to make it easier to export your activity, rejection blacklist, and whitelist.
Let's take a look back at the features and improvements released for Mandrill in the last week.
Rules engine now available to all
For many of our users, one of the great appeals of Mandrill is how easy it is to get started. Since we accept mail using plain old SMTP, there's a pretty good chance that your platform already supports Mandrill without writing any custom code. But, if you want to really take advantage of Mandrill's powerful platform, you need to write code.
So this week after months of beta testing, we're exposing some tools that make it easy to customize your Mandrill email behavior without writing any code. It's all part of someting we call the Rules Engine.
We spent most of our time this week adjusting the backend systems to improve the performance and consistency of the application. This is the kind of thing that can be difficult to explain simply, but let's give it a shot.
Even better sending performance
Last week, we made a series of changes to improve our sending speed. We've continued to see better performance and fewer spikes since those changes were made, but we saw places where we could do even more. With SMTP servers all over the world, there were some edge cases where those servers couldn't get new messages to us as quickly as users were sending them, causing messages to be delayed by whole seconds - clearly unacceptable.
We replaced our main SMTP delivery system with a one that scales better with increased concurrency and uses fewer resources. Here's the graph from our status page that shows the results:
Friday was a little crazy, but we still have plenty of things that went live this week. Let's get on with it.
More consistent and better sending performance
As part of the effort to build our new status page, we created a large international set of benchmarks (expect another blog post on this later). These tests send an email from every continent through our servers once per minute and measure how long the different parts of delivery take. We've always monitored sending performance through Mandrill in the effort to make email delivery fast, but these benchmarks showed how spikey our delivery times could be during periods of high load and contention. So this week we strapped on our profilers and went to war to trim some of those edge cases. A few days later, battered and exhausted, we have some results to share.
Lots of big things going down this week, including some changes to the quota system that affects just about all Mandrill users. Let's break it down.
Templates are now more than just HTML
We originally conceived of templates as a simple way to let non-technical people edit the HTML of their application-delivered messages. We even integrated with our sister product MailChimp to make editing templates even easier. Once the feature was launched, we were inundated with praise for having templates, but you guys wanted more than just HTML - a lot more. So, starting today, templates can control even more of the sending options for your email. You can now specify a subject line, sender address, and text part for messages sent using a template. When you send your messages using the messages/send-template API call, you can now leave off the from_email, from_name, subject, and text parameters from your call and it will fill in the values from the template instead. On top of that, we've overhauled the templates interfaces to reflect this new direction.
Author's note: This is the first of our 'from the trenches' posts, which are designed to give you a little bit of information on the how and why we do some of the things we do here at Mandrill.
When we created Mandrill we knew that a status page was going to be a pretty important thing for us to build out. It needs to be a place where we can show our current users that their trust is well placed, and where potential users can see that we do a really good job at providing a fast and reliable way to send their email.
Before I started designing our status page, I decided to talk to several people here in the company with a lot of experince using and looking through them: devs from our operations group. One of the general questions I asked them was what, for them, makes a good status page. The response was laughter with the (cleaned up for blog posting purposes) reply "Status pages are, pretty much, universally horrible. Good luck." And that was basically the same reply I got from others in the company.
Status pages are usually a sea of green check marks and if you're lucky you can find an icon you can hover over and see that the service was almost unusable (but still green). They may have a little, buried historical data or an uptime stat that, without any context, doesn't really tell you much. So the problem I was facing was how we balance out the green while also providing data with context?
Another week has ended, and that means that we have more Mandrill features and updates for all you wonderful people.
Webhooks are a great feature for integrating your site or application with Mandrill. You can listen for all kinds of events around your emails and act on them in totally custom ways. While this is really cool, it can be a pain to set up and test that webhooks are working, particularly if you're listening for bad or infrequent events like spam complaints and unsubscribes (and you don't want to generate actual spam complaints of unsubs for your account).
To make the setup process smoother, each webhook now has a "send test events" button. Click it, and we'll immediately send a batch of events (at least one of every event you're listening for) to your server so you can get a real example of the events we send and can iterate quickly on your integration. Pretty simple, but very cool. Here's some docs on how the button works, but seriously, it's a button. Click it.
Like our siblings over in MailChimp, the Mandrill team is celebrating Good Friday today, but we've still got some neat additions for you this week.
Dramatically Lower Prices, No Minimum Fees
This one's already been announced on the blog, so I won't belabor the point too much, but our new pricing is lower for absolutely all of our users, and on average will cut your bill in half. In addition, we made a bunch of changes to our monthly billing and account status screens to reflect this new focus on pay-as-you-go utility pricing.
This is a huge change to our pricing model, but we're still the same team with the same goals. We're just as focused on performance and reliability of our infrastructure, and we'll be doing just as much to innovate and add features to the product at a rapid clip. With nearly a year of experience running Mandrill under our belts, we found some cost savings in how we operate. Who better to benefit from that than our customers? Play around with our new pricing calculator and see!
UPDATE: As of 2015-07-15, Mandrill's pricing has changed. See our pricing page for current details.
Yesterday we changed Mandrill's pricing model. It's pretty significant and we think you'll be happy to see simplified and more cost-effective pricing for all senders. No more monthly plans. No more figuring out whether you want to keep a monthly plan even if you're sending less mail. Just consistent rock-solid features for all users, predictable pricing, and volume discounts built in (still no negotiation needed).
...And lower pricing for everyone.
But how much lower? Let's look at a few of examples of monthly sending:
Old Price: $ 9.95
New Price: $ 2.60
Old Price: $ 23.45
New Price: $ 8.60
Old Price: $ 171.45
New Price: $ 47.60
Old Price: $ 526.95
New Price: $ 197.60
Old Price: $ 1,745.95
New Price: $ 1,048.80
Just a few feature releases this week. We spent a lot of time setting things up for next week's additions.
Making the API docs executable
A nice mix of big and tiny updates this week.
Mandrill in three more regions
As part of our ongoing efforts to make SMTP fast, we launched Mandrill SMTP and API servers in four separate locations around the globe. This week, we added three more. You'll now see Mandrill servers in Tokyo, Japan; Sydney, Australia; and São Paulo, Brazil. That means we're now available in every public AWS region currently available except for Northern California, and have servers on five continents. Not bad!
Another week, another round of updates and improvements to Mandrill. Here we go.
New Pricing for High Volume Senders
Like most web-based software products, Mandrill had pricing information listed in the app and on the website, but really big and complex users needed to contact us for pricing. Personally, I hate it when companies hide pricing behind a sales process, so a couple weeks ago we changed Mandrill's high volume pricing to be both simpler and more transparent and stuck it up on the website. The new pricing took effect immediately for all users sending more than 1.3 million emails per month.
- Old Price: $0.40 per thousand emails beyond 1.3 million emails per month
- New Price: $0.20 per thousand emails from 1.3 million emails per month to 6.3 million emails per month, and $0.10 per thousand emails beyond that
Use the Mandrill pricing calculator for more details.
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.
Today we're excited to announce that we've partnered with our friends over at Codecademy to help new and seasoned developers learn to use the Mandrill API.
Mandrill generally operates on a continuous deployment model, meaning that as new features and bug fixes are complete (and tested by man and machine) we can deploy them to you. We deploy in small batches, continually monitoring changes and production load. Being able to quickly add features requested by users and fix bugs as we find them, instead of on a set development schedule, means that Mandrill can quickly adapt to be better and faster at sending your email. Lots of users have been excited for expanded attachment support, so we rolled out changes yesterday to include support for inline images and more attachment types.
Transactional email needs speed. Users generally don't want to wait for their password reset information or a confirmation that their order went through, and although there are a lot of factors that can influence delivery speed, most of us expect that an email comes within a few minutes of requesting a password reset or completing an order on our favorite website. On the Mandrill side, we're doing things like adding SMTP servers around the world to speed things up for our users. Using a local Postfix server is one step you can take to help increase speed and redundancy for your emails.
It's the beginning of a new year, and Mandrill's modest growth continues!
To keep things rolling, we'd like to start talking about some nifty integrations out there that will help you leverage the tools Mandrill puts at your disposal. There are a number of good integrations already in the wild, including ones for Joomla! and Drupal.
But for today's safari, we're stalking the two ton elephant in the CMS room: WordPress.
One of the things WordPress does "for free" is send email. You've noticed this happening -- you get notified via email when someone leaves a comment or a new user registers, for instance -- but you may never have thought about customizing that process. We're here to tell you why you should!
A few months ago, we had a customer come in complaining of slow sending speeds. Even the simplest of emails was taking 2 or 3 seconds to deliver. That may not seem like a lot, but if you're sending thousands of messages on a single thread, it can quickly add up to hours. Our servers routinely spent about 50 milliseconds processing their mail, so that was eliminated as a possibility. The customer's servers were in France and had a 250 millisecond ping time to our servers in Texas. That's pretty far, but still far short of 3 seconds.
The problem: SMTP is chatty
The key to this little puzzle is that the customer was using SMTP to send their mail. That's not too surprising; about 60% of the email that goes through Mandrill is sent using SMTP. The problem is that SMTP is designed as what we nerdy types like to call a chatty protocol. To send a single email using SMTP, you have to send multiple separate commands to the SMTP server and wait for a response on each one. The farther you are from the SMTP server, the longer you have to wait for each response. Here's a basic breakdown of a simple SMTP conversation (see wikipedia or the SMTP RFC for more detail):
Last week, we conducted some planned maintenance to move some data around and generally make things faster and more reliable for our users. While we were at it, we also rolled out a small update for templates, added some API calls related to Mandrill's inbound email processing, and added API logging for messages transmitted via SMTP.
My most recent post included a basic example of a plain text transactional email. I explained how even a simple email with your particular style could go a long way over something generic. Well, the message must have resonated, because one of our readers reached out that same day to share an example of a company doing exactly this... and doing it really well!
In turn, we were delighted enough to share this email with our own readers. So stick around, you might learn something!
Whenever we write or talk about transactional email, there is usually an accompanying laundry list of things that are worthy of custom email notifications. You know, welcomes, comments, receipts and the like. But this always seems a bit glib: sure, those are great examples of what transactional email is, but it doesn't say much about the how.
Indeed, because "how" is a developer topic, it can be difficult to fit thorough prescriptions into otherwise-brief business topics. And besides, coding isn't for everyone! What good is all the business advice if someone can't get started integrating without a computer science degree (or at least a solid year hacking on the web)?
Today we're going to sidestep these problems and put Mandrill to work leveraging more integrations with less coding. Read on to find out how.
Custom metadata is one of my favorite features in Mandrill because it's a powerful way to customize Mandrill for the unique needs of your organization, app, or website and it's simple to set up. With custom templates for metadata fields, the Activity view in your Mandrill account can display data about your emails and link directly to your CRM or backend database.
In his last post, Loren showed how Tourbuzz is using Mandrill's search API to show customers their email history inside of the Tourbuzz application. Of course, advanced searching is not limited to the API. It's also available inside the application. Mandrill searches utilize Lucene queries, which means you can search by a single term, phrases (surrounded with double quotes), multiple terms (using the Boolean operators AND, OR, and NOT) and wildcards (* for multiple character wildcards and ? for single character). And by default, Mandrill searches all indexed fields, including any custom metadata that you've added. All that information is just one search field away.
By now, you know that Mandrill provides tools for building out your email infrastructure. What you may not know, however, is that the tools can also be used to pass value down the chain to your own customers. Today we're going to examine how one of our customers has done just that with some of our more advanced email platform features.
In their own words:
"Mandrill's turnkey email platform allowed us to migrate from our internal postfix system to their ESP in a couple of days. That included development of our amazing new "Email History" feature which allows our customers to instantly see deliverability, opens, and clicks for every email handled by our system.
"Our new email infrastructure has improved deliverability, vastly increased customer confidence in our system, and reduced support load for both us and our customers." -Alan Pinstein, cofounder, Tourbuzz.net
Read on to learn how they did it.
If you use a desktop email client to create emails to be sent through Mandrill, one thing you might be missing out on is the ability to use a template or specify some custom options for the emails that you're sending. Mandrill has an awesome SMTP headers API so you can add all kinds of goodies to your emails, but desktop email clients don't generally make it simple to add these custom headers. With a little bit of wrangling, though, you'll be off and running. Below I'll show you how you can add these for a couple of popular email programs.
Imagine doing business with someone who doesn't listen to you. They talk to you often enough, but they aren't interested in anything you have to say. In fact, they can't hear you at all, as though they have their fingers in their ears while chanting "la la la I can't hear you la la la." Not very professional, is it?
Strangely enough, this happens millions of times a day! And it's perpetrated by some of the most sophisticated companies out there. They talk at their customers, not with them. They speak and refuse to listen. Odds are you can go to your inbox right now and witness this for yourself.
What am I referring to, exactly? Why, "no-reply" email addresses, of course! And it's more than just rude, it's a big missed opportunity for the companies that abuse them, as well.
That's why the Mandrill team is declaring war on this dreadful practice. Let's look at an example and consider the consequences in depth...
I just passed Ben (MailChimp's CEO) on the stairs. All I heard was him chanting "blog post, blog post, blog post."
"When are you going to update the Mandrill blog?" "What are you guys working on?" "Is Mandrill dead?"
No, Mandrill isn't dead - it's very much alive. But, see, that last blog post that Chad made? It's sort of a hard act to follow. We've been busy adding new features and beefing up functionality but few of these features seemed to warrant a full blog post. Plus, the Mandrill blog is sort of a nerd's blog, which means code and the command line and...well, more on that later. Time to rip off the band-aid. Here's a little bit of what we've been up to:
Mandrill (our new email as a service product, for those that don't know) has had an interesting history. It started as an idea about two years ago, and its path of becoming a product is an example of a growing company trying to figure out how to start something new.
tl;dr As a company grows around a product, inertia from past success can kill short-run productivity on something new. A way to get around this is to create a whole new team isolated from the core to break the inertia and force them to bet big on the new risky product.
Why Do Startups Win?
To a naive observer, it seems insane that tiny companies bootstrapped with no money and made up of a bunch of friends from college could ever build products that rival the output of huge companies. The huge companies have easy access to large amounts of money. They have built-in pools of trained experts that they've hired over the years and can afford to pay well. They have a brand that people recognize. They have man-millenia of experience building products and systems with a proven track record of success. (they're big for a reason, right?) Tiny companies have none of these things.
So why aren't big companies exploding with innovative new products? Why do they pay huge premiums to acquire tiny startups? It can't be for the idea - everybody has ideas. It would have to be for the team or the execution of the idea. With all of these advantages, why does the big company need to pay a premium for that? Why doesn't the big company just create new products from within?
About a year ago, we launched STS - a transactional email service built on top of Amazon SES. In that time, we've seen the integration grow to a moderate success, now sending on average over 100,000 messages every day. While we're happy with the cool things people have built on top of our integration, we've received a ton of requests from customers for features that we felt we really couldn't accomplish on top of a limited platform like Amazon's. We've also spent years building a world-class platform for email delivery and analytics, so the devs were constantly saying "why don't we use this platform to build an email service that's MailChimp through-and-through?" That thought turned into a prototype labs project called Mandrill which we are excited to announce has graduated to public beta.
At its core, Mandrill is similar in functionality to our STS integration, but using the same optimized delivery engine that MailChimp uses for the delivery of our bulk newsletters - slightly modified for one-to-one email. You still need to be a programmy nerd to use it, so if you're not comfortable with code and APIs, you'll need to find someone who is before you get started using Mandrill.