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! read more
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! read more
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.read more
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.
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 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.
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.
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.
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!
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).
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.read more
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.
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.
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.read more
We've been hard at work on some larger backend changes, but still have a highly requested feature for you this week.
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.
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.
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.
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.read more
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.
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.
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.read more
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 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.read more
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.
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 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.read more
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.
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.read more
Happy birthday, Mandrill! After devouring perfect bananas for the past week, we have some new features to share.
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.
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.read more
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.
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:read more
Friday was a little crazy, but we still have plenty of things that went live this week. Let's get on with it.
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.
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.
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.read more
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.
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!read more
Just a few feature releases this week. We spent a lot of time setting things up for next week's additions.
A nice mix of big and tiny updates this week.
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!read more
Another week, another round of updates and improvements to Mandrill. Here we go.
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.
Use the Mandrill pricing calculator for more details.read more
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.read more