Email Best Practices

Email is a pain, but is absolutely required for many modern applications to function well. Whether it is for sending invoices, password resets, or simply for notifications, you’ll probably be making changes to your application’s email components early and often. While you can get by with a terribly implemented email system for years, you’ll eventually find that problems in such a system will get more annoying and distracting over time as your application scales up. While it’s easy to fix simple email issues early on when only a half dozen people are receiving your emails, it becomes difficult when there hundreds of people on your system, and becomes all-consuming if there happen to be thousands. Email also seems simple. Like a logging setup, you might be tempted to think you can built out your application’s email functionality in an afternoon. And you’d be right, for a while, but like a hacky, poorly planned logging setup, it eventually causes more problems than it solves. There is a lot of complexity behind the scenes and that complexity can interfere with application stability, usability, and possibly even run your costs through the roof if you aren’t careful. Worse still, there are a lot of regulatory compliance rules around email, with steep fines if you break them. Finally, even if you manage to avoid all these problems, there is still an extremely diverse set of email account providers, mail clients, and spam filters out there, all of which do things in slightly different ways that can make your emails look horrible or even keep them from working at all. You probably won’t be able to solve all your email issues at once. Rather, you’ll probably end up solving email-related problems piece-by-piece as you run into them. However, there are a set of general practices and rules you can observe that will dramatically reduce the number of problems that email causes for you. Dealing with email in a large application is complex and it is getting more complex all the time. Because email had a variety of security, privacy, and spam issues in the early days, a lot of email-related interactions are complex and are not consistent across platforms. In addition, you have to get email right if you don’t want to have performance and stability problems with your application. Episode Breakdown Don’t host your own email server While it is tempting to do this to reduce costs, this results in a lot of downtime as well as deliverability problems, unless you are extremely good at doing this. Even if you are good, it’s probably still cheaper to outsource this to a third party. If you are doing mailing lists, sites like Mailchimp can cover a lot of your needs, while transactional emails can be handled by things like Mandrill, SendGrid, etc. Even if you are doing cloud work, your cloud provider likely has a lot of email-related functionality available for a much lower price than the cost of hosting your own. Third party email providers also provide a lot of other infrastructure for you, such as being able to track things like email bounces and the like. If you don’t use third party providers, you may need to build out this functionality yourself. This is probably not a good use of your time. Have a way for people to manage how you contact them. Many anti-spam laws have been passed over the years, and you are unlikely to be able to avoid them. Further, these laws are often structured around how people react (in real life) to junk email. In this case, the law is actually reasonable guidance for how to keep from annoying your users. Additionally, users are going to want to customize the way that you contact them in general. You probably shouldn’t build out email functionality in your application unless you plan to have this in place.