On the surface, email seems like a simple proposition–an afterthought or commodity even. That couldn’t be further from the truth. You literally cannot build a modern web application without email. At a minimum, people need a way to reset their password, but it goes far beyond that.
The value of email, particularly application or transactional emails, is increasingly apparent. People expect to receive receipts and password resets, and they open them and engage with them. An email newsletter? Maybe they’ll open it, maybe they won’t. This difference has far-reaching ramifications.
Missing or delayed transactional emails feel a lot like your application being offline, and they can really hurt the customer experience. If you need a more quantitative measure, those missing and delayed emails lead to additional support requests. One or two a day may be tolerable, but those quickly add up as you grow. As a small team, there are countless better things to spend time on. You simply can’t take your transactional emails for granted.
Delivery issues can be an invisible problem. You won’t notice until you have enough customers that it becomes likely someone takes time to report a problem. Even then, you could dismiss it as a one-off until you receive multiple complaints. You might not hear about delivery failures frequently, but that doesn’t mean you don’t have a problem. Generally, delivery issues don’t reveal themselves until you’re at scale with enough customers that the complaint volume can’t be ignored. Of course, it’s best not to wait until that point.
Separate Your Transactional from Your Promotional Emails
While there is a gray area, the vast majority of business emails fall into the categories of either transactional email sent from applications, or promotional email like newsletters. On one hand, email is email; but on the other hand, these two categories are different enough for Gmail to explicitly advise sending them from different domains:
If you send both promotional mail and transactional mail relating to your organization, we recommend separating mail by purpose as much as possible. You can do this by:
- Using separate email addresses for each function.
- Sending mail from different domains and/or IP addresses for each function.
Inbox providers and ISPs have increasingly sophisticated spam detection systems, and engagement is one of the signals growing in importance. These days, it’s not just about whether recipients report an email as spam or not; it’s about whether they open it, how long they open it, and if they click on the links inside.
The higher the engagement with emails from a particular domain or IP, the higher the likelihood that the email is important. In the case of transactional emails like password resets, the open and click rates are significantly higher than your average marketing email. The result is that domains and IP addresses sending transactional emails tend to have much better reputations. And in contrast, domains and IP addresses sending bulk promotional emails tend to have worse reputations.
Mingling the two and sending them from the same domains and IPs may help improve the standing of your bulk promotional emails, but it will also hurt the reputation and delivery of your transactional emails. They could end up in Gmail’s “Promotional” tab, or even end up in the spam folder. By separating them, you’re ensuring your most important emails get through by giving ISPs clear indicators of what type of email to expect from each source. This will invariably reduce support and lead to happier customers.
Inbox Rates and Delivery Speeds
There’s another big difference between transactional and bulk emails. Nobody emails support if a holiday sale newsletter never shows up. But if they request a password reset, and the email isn’t in their inbox almost immediately, they’re going to get in touch. The same goes for software license keys and other critical emails. If delivery is slow or the emails end up in the spam folder, your support costs increase.
You may not be measuring those support costs, but they add up. Saving a few dollars per month on email delivery could cost your business hundreds or thousands of dollars in added support. It’s easy to be blind to bad delivery or assume that some delivery issues are outside of your control, but that’s not the case. If your customer support team doesn’t know it’s worth raising up the flag pole, they might just suffer in silence while customer emails go missing and support requests increase.
The other important thing to know is it’s not only about inbox rates. When your customers are waiting for their license keys or password reset emails, speed matters too. It’s not uncommon for a low-cost email provider to take minutes to deliver an email. Even if it shows up, delays of even a few minutes can lead to additional support requests. For a smaller business, this won’t have a huge impact, but as you start to grow, you could quickly find your email delivery isn’t as good as you thought.
The final secret of inbox speeds is they’re often outside of your direct control. When you send an email, ISPs will respond that they accepted the email. However, just because an ISP accepted the message doesn’t mean the message is passed immediately to the recipient’s inbox. ISPs manage a lot of traffic, and they apply sender reputation to their own internal priorities. For instance, if they’re receiving thousands of emails from a domain with a reputation for bulk promotional email, they’ll throttle delivering those to inboxes. But when a domain with a good transactional reputation sends across a single password reset email, they recognize its importance and send it to the inbox without delay.
Another signal that ISPs use to measure the reputation of senders is bounces. If a large percentage of emails from a sender bounce, it’s a sign they aren’t taking care to monitor delivery or the quality of the email addresses to which they’re sending.
There are several ways to handle this. First, your email service provider should provide bounce-handling functionality. When you send an email that bounces, they receive the bounce notification and pass it along to your application via webhooks. You can then take appropriate action, discontinue sending to that address, and display a warning to the user that there was a problem. If you have multiuser accounts, you could even notify the account holder or administrators that there were delivery problems for that address so they can correct the problem.
Not only does this help you reduce bounces, but it proactively handles delivery problems to help your customers stay on top of things. It also reduces the number of support requests about email delivery because it puts more power in your customers’ hands so they’re able to fix the problem without assistance.
Another option is to use email validation services. You probably won’t need to use one early on unless your business model is prone to people providing fake email addresses, but it can help at any point. These services can validate basic typos in popular domains like Gmail, Yahoo, Hotmail, and so on; but, more importantly, they can make a test request to a mail server to validate that there is a usable inbox for the provided address.
Delivery vs. Acceptance
There’s a big difference between acceptance and delivery. Email service providers (ESPs) can only tell you what the receiving mail server told them. In most cases, they’ll respond that they’ve accepted the email–but acceptance does not represent delivery. The receiving mail server may be juggling many emails, and it will have its own rules for determining which of those emails are going to be delivered first.
While some ESPs do offer open and link tracking, these methods only work if the recipient has images enabled and engages with your message. Even though mail servers are accepting your messages, that isn’t a guarantee those messages will make it to the inbox. Or, if they do make it, it may take them a while. So don’t assume that acceptance means delivery.
“No Reply” email address are another consideration. In general, avoid them. At the simplest level, they reduce engagement by discouraging replies. That, in turn, can potentially hurt delivery. It’s the digital equivalent of telling someone to “talk to the hand.” When people do reply, it’s a poor experience because the email is rejected.
At scale, it can be incredibly difficult to change systems and processes so your team can provide support for replies to any emails. Your best bet is to build things to avoid no reply addresses from the get-go. Thankfully, you have several options for handling them.
The simplest solution is to use your support email address as the sending address for your messages. In some cases, though, you may want to use an address like firstname.lastname@example.org or something else. These can either be set up to be aliases for support, or you can use a Reply-to address and specify that replies go to support for your messages.
When you’re just getting started, having conversations with your customers is arguably the single most important task you can spend time on. Not letting customers reply to emails shuts down one of those channels and sends the wrong message. Be welcoming. Encourage replies. Your engagement will improve, and you’ll have happier customers.
Logging and Troubleshooting
One of the most underrated features of modern transactional email tools is logging, including the ability to troubleshoot missing or delayed emails. For most providers, giving you a ton of granular detail and history on individual messages is a risk because it can expose delivery issues with that provider. Most providers will store some combination of message events and a short time period of the full content. In most cases, providers store less than a week.
Unfortunately, missing emails aren’t always discovered within seven days. So when the support request comes in about a missing message, you won’t have the details you need to know. I strongly recommend choosing a provider that stores at least thirty days of message event history.
However, message events aren’t always enough. With spam filters, it’s often the content of the email that caused a problem. Unfortunately, almost no email service providers store the full content of messages for troubleshooting. If a unique word or phrase in an email triggered a spam filter, it’s going to be almost impossible for you to find out; you’d need an email provider that stores the full content of your emails.
Alternatively, privacy and security are also important consideration when storing email content. Having the full content available is helpful, but, storing the full content of a password reset email, for example, can create another attack vector for hackers. For highly sensitive applications, storing the full content of emails may be problematic. In those cases, you’ll either want to avoid storing the full content or ensure that no sensitive information is included directly in the email and instead direct people to login to view the content.
Logging and troubleshooting may seem like a nice-to-have feature, but once you start handling support requests for missing or delayed emails, you’ll quickly learn it’s priceless. You’ll be able to get to the bottom of things faster and spend less time in support, and those savings will add up quickly.
If you’re sending email, take the time to set up SPF, DKIM, and DMARC. These three standards work together to help establish your identity, build a good sending reputation for your domain(s), and provide mechanisms to protect your brand and domain.
Sender Policy Framework (SPF) lets you publicly state the IP addresses that are approved to send emails on your behalf. ISPs won’t immediately flag emails as spam if they don’t have SPF, but it is certainly a signal they factor into the equation.
DomainKeys Identified Mail (DKIM) provides a way to sign your emails. You can think of it as the digital equivalent of a wax seal on a letter that ensures the contents are valid and unaltered. It also helps in other ways. First, it provides a way for ISPs to begin associating your sending reputation with your domain. This is important because IP addresses are becoming less important as a trust signal since they can easily be replaced; a domain, however, can’t be replaced so easily. Second, by establishing a reputation for your domain, your sending reputation becomes more portable if you need to switch email service providers.
Domain-based Message Authentication, Reporting and Conformance (DMARC) is the newest of the three standards, and it builds on SPF and DKIM. On the simplest level, DMARC provides ISPs with a way to let you know about the emails they are receiving using your domain and the originating sources of those emails. You can track down which sources are malicious, as well as uncover sources that aren’t using SPF or DKIM but should. It provides you with a way to explicitly state how you’d like ISPs to handle emails from your domain when they do not align with SPF or DKIM. While you need to be careful using it, you can set a DMARC policy to reject emails that aren’t aligned, and ISPs will simply discard them.
Increasingly, companies prone to phishing scams are setting DMARC policies and telling ISPs to reject any email that isn’t properly authenticated. This way, bad actors can’t spoof, for instance, PayPal addresses in their scams because ISPs can look at PayPal’s DMARC policy and know they should reject any emails that aren’t aligned. You probably don’t need to set a reject policy straightaway, but establishing DMARC reporting for your domains is still a good idea. Postmark provides a free DMARC tool that helps compile the reports into an easy-to-read weekly email, and you can use the tool even if you don’t use Postmark.
Authentication will take some time to set up, but your transactional emails are worth it. You should always take steps to do anything and everything you can to ensure the best possible delivery rates.
Design and User Experience
Once your emails are arriving in recipients’ inboxes quickly and reliably, they still need to be useful. It’s no secret that designing, building, and testing HTML emails is challenging and time-consuming. You’ll have a set of emails encompassing welcome messages, password reset emails, receipts and invoices, invitations, notifications, and more. All of these need to be designed and tested like any other part of your user experience. It’s always easy to tell when a web application cuts corners on the emails.
Fortunately, at Postmark, there’s a set of well-tested transactional email templates to make it incredibly easy to get started. In addition to the templates, there’s a series of guides about best practices for each of the following email categories:
- welcome emails
- password reset emails
- receipt and invoice emails
- trial expiration emails
- user invitation emails
- comment notification emails
A Word on Dedicated IP Addresses
When you evaluate email providers, you’ll inevitably hear about dedicated IP addresses. Almost all ESPs offer two distinct sets of email services. The first is a shared IP range used by all of their customers, and the second is a dedicated IP address. In and of themselves, dedicated IP addresses aren’t inherently bad, but they aren’t a silver bullet either.
The upside of using shared IP addresses is they’re cheaper. The downside is they’re shared, and if you have bad neighbors on the same IP addresses, delivery can suffer if they get reported for spam, or the IP addresses are blacklisted. Depending on how well the provider polices their shared IP addresses, they can easily end up polluted and gain a bad reputation. This problem can be more frequent when a provider allows promotional email to be sent from those IP addresses as well, because newsletters tend to receive spam complaints at a much higher rate than transactional email.
Generally, when you consistently encounter issues with a company’s shared IP addresses, they’ll suggest you pay more money and upgrade to a dedicated IP address for better delivery. That is, they are telling you that if you care about delivery, you’ll need to pay more money. The pattern is simple. They get you on their service with incredibly low-cost shared IP options. At that point, you’re integrated, and the cost to switch is higher. Then, once you realize just how poor delivery is on the shared IPs, they recommend you pay more money. If companies offer dedicated IP addresses at extra cost and don’t stand by their shared IP addresses, that should be a red flag.
To make matters worse, most companies put the burden of warming up the IP address on you. With new IP addresses without a sending history, inbox providers are incredibly wary. If a new IP address comes out of nowhere sending millions of emails, they assume it’s spam, and they’ll treat it as such. You have to slowly and steadily increase your sending on an IP address to build reputation. Most providers will charge extra for an IP address, and even then, you can’t use it right away. You have to work to warm it up.
Similarly, dedicated IP addresses don’t work until you have a high and steady volume of emails. If you only send on one day a month, you’re going to have a hard time building a reputation; if you only send a hundred emails daily, your volume isn’t high enough to build a reliable reputation.
In the right context, there’s nothing wrong with a dedicated IP address, but it’s important to understand that it’s not a silver bullet. Moreover, if a provider’s shared IP prices seem to good to be true, they likely are. Remember, sending the email is only part of it. If delivery suffers, you’re not really getting what you’re paying for.
Email isn’t going anywhere anytime soon, and the ecosystem of tools to make email easier is constantly expanding. Gmail offers Postmaster Tools to help you identify and troubleshoot reputation and delivery. Postmark offers a free DMARC tool to help gather data and send you weekly reports about email sent using your domain. Tools like Mail Tester and Spamcheck help you get a feel for the spamminess of your emails. Open source tools like MailMason and Postmark’s Templates help you build and maintain a consistent set of email templates with significantly less effort. Services like Litmus and Email on Acid make testing email in various clients easier than ever. And finally, services like ReturnPath and 250ok provide advanced tools for monitoring all aspects of your deliverability.
While email has traditionally been more of an afterthought for developers, it’s coming into its own and beginning to receive the attention it deserves. The tools are improving, and the conversation around inbox rates and delivery speed is becoming more prominent. Teams are also beginning to recognize just how different promotional and transactional email are, and what that means to business. When you’re looking for an email provider, understand that email isn’t the commodity lower-cost providers would have you believe it is, and take time to really investigate providers before choosing one.
Considerations for evaluating transactional email service providers. I put together a detailed guide of considerations and things to look for when trying to choose a transactional email service provider.
Transactional email bounce handling best practices guide. An exhaustive guide to help you understand bounce handling and design a solution to mitigate bounces and empower users to correct issues before they become a bigger problem.
Word to the Wise Blog. Laura Atkins runs one of the most respected companies and blogs for email industry news around authentication and deliverability.
Should You Send from a Dedicated IP Address? The MailChimp team has put together a great summary and overview of how ISP’s determine the reputation for a fresh IP address.
HTMLemail.io A set of extensive and well-tested responsive HTML email templates to jump start your transactional emails and save some time.