a.k.a. 'quick howto about improving your Drupal transactional email delivery rate'.
In the world of eCommerce having the ability to communicate with customers and potential customers is priceless. Most eCommerce store owners and eCommerce site builders will probably agree with this statement. Most stores are setup to email the customer an order confirmation at the time of ordering the product, a confirmation that a user account is created, or a neat password reminder email to help your customer recover their password.
So far so good.
What most store owners (and some eCommerce site builders) don't realize is that by default Drupal (and thus Drupal eCommerce solutions) are setup so that the website server sends out the email to the customers. And most webservers don't make great email servers. The fact that a server can send and receive email doesn't neccesarily mean it's a great email server. If that where true one would be able to see delivery and open rates of the emails sent by the server. One would be able to see how many spam complaints the server got, how many emails bounced and could not be delivered. One would be confident a user would receive that important password reminder email right before their point of purchase. We where not that confident, as even our 'New release(s) available' Drupal update email sometimes got delivered to our spam folder. So we looked for a solution.
Transactional Email Solutions for Drupal
We asked ourselves "what solutions are there to make sure your customers can actually 'hear' the transactional email communication we send?" The answers we found are roughly listed below.
Build an email server
One solution is to DIY. Configure that perfect email server you need to make it happen. Educate yourself on email blacklists, handling abuse complaints, email feedback loops and other yargon. MailChimp has a great guide on how to build your own Email infastructure. Or have a look at this Ubuntu guide if you're setting up Ubuntu as an Email server. It will take time to set it up, and in some cases it's probably worth it.
Send through SMTP
Drupal's SMTP module let's you send all email through an external SMTP server. It may improve delivery rates, but in most cases it's actually a partial solution. In most cases it doesn't really handle spam complaints and bounces.
Outsource email delivery
If your time is something you value and your organization doesn't have the resources to setup and maintain a great email delivery system OR just doesn't want to have the hassle of doing that: look for a party who specializes in these cases. Mandrill is such a service that specializes in these cases. Actually it specializes in these 'transactional email' cases AND makes sure it integrates into Drupal with a neat Mandrill module. It runs on the delivery infrastructure that powers MailChimp.
The module is very easy to setup. Basically pasting the Mandrill API key into the module's configuration settings gets you up and running. And make sure you add the DNS keys you get from Mandrill to your DNS server settings. These basically tell the 'email server world' that you allow Mandrill to manage your email.
Our choice
As a small two-person company we went for the solution where we let the email professional do what they are good at. Mandrill is allowing us to have the perfect top-of-the-line solution without having to put in a lot of money or resources. As our company and projects grow transactional email delivery gets more important, our Mandrill plan grows with that need. We're probably never going to have 'setting up the perfect email server' as one of our core activities, so as long as Mandrill stays around we're going to be happy customers with happy customers :)
Do you happen to know other solutions? Please add them to the comments below or contact me through the contact form.