Email Authentication at Pulse Analytics: Part I

As the team at Pulse Analytics is building a set of data-driven tools, ensuring that we are always providing current data is key to preserving and growing our business. While our data is always available on our web platform, we wanted to improve our product's experience and ensure our users have quick access to up-to-date, relevant information by building out an email system that could send monthly reports straight to our users’ inboxes. Our goal was to summarize profiled healthcare organization changes into a digestible newsletter-style monthly email report that was timely and relevant to our users. In this series of posts, we’ll go over the whys and hows of a key issue we encountered when setting up our email delivery system - email authentication.

The Problem

Our team had previously built out a basic email infrastructure for our user support feature, which sends support requests from our users to an internal email address. However, sending emails to external addresses presented new opportunities - extending our email delivery system for this first monthly report would lay the foundation on which we could plan other types of emailed notifications that could benefit our users - but also many new challenges with building and populating dynamic, styled emails.

After building out the initial system that generated email templates and wired in live data (we’ll leave that for a future blog post), we started testing our system. We sent some test emails, checked our inboxes, and saw...nothing. What was going on? There were no errors in the compilation of our email templates, the data was good, and we saw that the emails were successfully being sent to our email server. Well, it turns out that our beautifully formatted emails were being sent as expected, but weren’t landing where we wanted them to go - they were being relegated to the junk/spam folders of the various email clients we tested with.

The prospect of bulk sending emails externally to our users’ email addresses highlighted the need for us to properly authenticate the domain that we were using. Thus began our process of learning about what the current emails authentication standards were and how they operated.

Why Bother Authenticating?

There are two primary reasons to authenticate your email domains: to prevent bad actors from forging email headers to trick recipients into believing it was sent from a trusted source, and to ensure a high level of deliverability across different receiving email servers

Our main problem was the latter - our emails were incorrectly being quarantined in spam folders of people who wanted to receive them. Without proper authentication, email servers that receive emails from a given domain may quarantine or block emails from that domain. Different email servers may also have different standards for how to handle emails that do not pass or have not established a given authentication method, so having robust authentication in place would ensure that our emails had the best chance of reaching a user’s inbox. Proper authentication would then also protect our reputation from being negatively affected by inconsistent email delivery, and would give our users the confidence that our emails were trustworthy and reliable.

For our user support emails, we had previously integrated SendGrid (an external email service provider) into our application to handle email delivery. We chose an external email provider for a few reasons. Convenience and the availability of analytics were two key considerations, but external providers also help with authentication - most email service providers will provide guidance on how to authenticate your domains according to current standards in order to maximize delivery rates.

We decided to continue using SendGrid to deliver our monthly reports for these same reasons, and the authentication capabilities built-in to most external email providers (i.e. generation and storage of authentication records, dedicated IPs) greatly streamlines the process of configuring email authentication.

Looking Ahead

So far, we’ve gone over why email authentication was a problem for us and some reasons why robust email authentication is important. In Part II of this post, we’ll go over current email authentication standards and how they help authenticate a domain so that receiving email servers can be sure that they are not fraudulent. They each address the key question of “Can I trust this email?” in a different way, and in combination provide maximal certainty to receiving servers that a given email can be trusted. We’ll also touch on other considerations and problems we ran into (like the dreaded email blocklist). Email authentication is something often taken for granted as it’s built into most email clients we use, but we hope that through these posts you’ll be able to glean some lessons from our journey into email authentication, so stay tuned!