Sending Mandrill e-mails from Rails, the MVC way

Update: For updated guidance, see E-mail in Rails with MailChimp and Mandrill, a comprehensive guide

Mandrill is a transactional e-mail service for developers. It allows you to quickly reach out to users from your app via e-mail, through SMTP or Mandrill’s  API.

Cook Smarts‘ transactional e-mails sometimes go to many users at once, and we quickly hit the limits of SMTP. It was time to use Mandrill’s API to send out e-mails from our Rails app.

Here’s how we moved from ActionMailer/SMTP to Mandrill’s API while staying true to the model-view-controller (MVC) nature of Rails.

Install the Mandrill gem

Add the Mandrill API to your gemfile.

Then run ‘bundle install’ from the same directory.

Send e-mail

Want the simple version of the code needed to send a message? Check out Mandrill’s documentation.

Below we’re going to cover Cook Smarts’ more complex use case.

We specify the subject, from name, and from e-mail above, which is pretty self-evident.

But – surprise! – we’re sending this particular e-mail to a ton of users at once, and we want to address each user by name.

Addressing the message

This message is going to all users with a subscription. We have a scope in our User class called ‘paid,’ which returns all the paid users.

We need to get these users’ e-mail addresses into an array for Mandrill. A class method, User.to_mandrill_to, takes care of this.

When we call ‘User.to_mandrill_to(User.paid),’ we get all our paid users’ e-mail addresses back as an array.

Merge tags

Mandrill uses merge tags to personalize messages. For instance, we want to say “Dear Mary” if the message is to Mary, and “Dear John” if it’s to John.

When we send multiple messages at once, we need to tell Mandrill which name is related to which e-mail address.

Our e-mail template, stored in a Rails view, contains a placeholders for the user’s name:

Another class method, User.to_mandrill_merge_vars, associates each user’s e-mail address with their first name:

This gets us the value we need for the ‘merge_vars’ argument of the API request above.

The message

As stated earlier, the e-mail template lives as a view in our Rails app.

We’ll use render_to_string to process the template and insert it into our API request.

The view should be a full HTML page, including and tags. We add ‘:layout => false’ to avoid bringing in other header/footer content from our app.

Avoid an embarrassing mistake

Remember to include ‘:preserve_recipients => false’ in your API request, unless you want all the people you’re e-mailing to appear in the To line in every message. Mandrill has the details.

MVC Summary

Our Users model provides the addressee information, the meal plan e-mail template/view provides the message, and the admin controller sends the actual e-mail.

All of this without the use of SMTP or Rails ActionMailer – just Mandrill’s API.

We’ve found that this solution has worked well for transactional e-mails with multiple recipients.

If you’re looking for tight Mandrill + ActionMailer integration, check out the Mandrill delivery method gem.

We’re starting a series called Mailing on Rails, which will cover all the bases to get you up and running with mail in your app. Want us to let you know when it’s up? brings Rails job offers to you. Free for candidates. Salaries from $75,000 to $250,000. Sign up now!

8 thoughts on “Sending Mandrill e-mails from Rails, the MVC way”

  1. Thanks!great tutorial.

    I have one question though: is it possible to pass rails parameter to the view?
    My message contains dynamic content, for example I want to display the new arrivals of the store, the size of this variable sometimes is 3 others is 7. I have @items. and would like to do something like @items.each do |i| i.title end inside the message. Is it possible to do this? Thanks!

    1. Matt, thanks for letting us know. render_to_string in this article is used in the controller. In Rails 4, do you need to precede it with even within a controller?

  2. Thanks for this article Corey. Any benefit to merging on Mandrills side (via merge tags) versus doing it on your app’s side (via variables in the controller)? Just offloading the work to their servers?

    1. Brian, the advantage to using Mandrill merge tags is being able to submit one API request for thousands of e-mails. If we merged on the app’s side, we’d have to use an API request for each individual e-mail, and would likely have to batch the requests and manage all of that.

      When we send just one transactional e-mail, like a receipt, we use Mandrill’s SMTP instead of the Mandrill API, through Rails’ Action Mailer (

      (Even if you’re sending just one e-mail at a time, though, you might consider using Mandrill’s API and merge tags, as doing so would allow you to MailChimp and Mandrill templates, which you could update without redeploying your app. We might be heading this direction for receipts and such. See


      1. Thanks Corey. Makes sense.

        I’m currently using Mandrill via action mailer (but via SMTP). Need to configure my templates to move to this way of sending.

Leave a Reply