Email best practice is to minimize sending sensitive information to your customers via email. In the past, email clients were fairly wide open applications with little to no security and data was often sent over unsecured internet connections. This made it very easy for a hacker to either sniff the email while in transit and/or get into your email inbox and find sensitive data.

But I’m starting to wonder if we are approaching a new era where more personal data can, in fact, be sent via email; there are two reasons for this conclusion:

  1. Today, most email clients need a username/password and many even support multi-factor authentication methods.
  2. Google’s recent launch of AMP for Email.

Over the years in my job as a Messaging Engineer at SparkPost I have spent a lot of time telling people not to send sensitive information in an email to their customers; but to use email as a way to send a ‘call to action’ to their customer; one that typically brought them back to their website. Taking this approach kept sensitive data safe and secure behind the corporate firewalls and whatever login mechanisms they deployed. But the tide has changed in the last few years, and most new email clients force similar security as these applications deploy. In fact, many aspects of email lead to even greater security than those applications. Here are a few examples:

  1. Most of my email clients notify me if my email is accessed from a new device.
  2. While not a perfect security mechanism, I can typically see if my email was read. If the email was read before I got to it, I may have an issue.
  3. Two-factor authentication is widely used to log in to your email client.

Taking all of these items together, give me a fairly high degree of security if I choose to use them.

So what about the email itself.  Most Internet Service Providers mandate that you send your email using an internet cryptographic protocol called TLS, and most of them use version 1.2 that has been around for almost a decade and has been proven to be very secure. But admittedly, I’m still a little cautious about sending sensitive data like names of my prescription over email. This is where Google’s new AMP for Email comes in. Here is a description on AMP for Email by google:

AMP for Email allows senders to include AMP components inside rich engaging emails, making modern app functionality available within email. This dynamic email format provides a subset of AMPHTML components for use in email messages, that allows recipients of AMP emails to interact dynamically with content directly in the message.

What AMP does is allow emails to act very much like an application. Every time a user opens an email built with AMP components, it has the ability to call back to a server and display the latest information to your customer in that email. Maybe it’s when their next appointment is, or what prescriptions are due for refills. While not typically sensitive information; I like the idea of opening up an invoice and having it show me the latest shipping information without having to press a link and go to some third party sites like DHL or UPS!

From a security perspective, all communications from the email client to the server when retrieving the data is done across secured lines, just like the ones you use when logging into a secure web application. So is there really any significant difference between new AMP emails and our current HTML based applications? I’m thinking not.

If we start extrapolating the possibilities of AMP for Email, future email clients may morph from what we have today into a portal listing both normal emails and new AMP emails that take the role of micro applications with very specific functions.  This new email client may be similar to what many companies attempted in the earlier days of the internet when companies like Netscape, Lycos, TopTier and Yahoo attempted to be a one-stop shop Portal page into all things internet. Instead of your typical email client where there is a list of emails that have been streaming through your inbox over the last several days, your email client may have a list of micro applications that perform small tasks that typically were done after going to the website. I would expect that users would select, or pin which AMP enabled emails they want at the top of their list; similar to what Hotmail implements now by pinning important emails to the top of the email list.

Leveraging this microservice approach within emails will also help fight spoofing and typosquatting. Once the user has an email that they trust, they can continue to leverage that email each time they want that service without having to worry if a new email they think is from that company was spoofed or they accidentally typed a bad web address that is actually going to a typosquatting URL.

When taking all of these security measures together we are on a solid trajectory to changing the way our users interact with email and potentially sensitive data like PCI and HIPPA data. To be clear, there are regulatory hurdles that need to be considered and/or modified in order to have this vision come true. PCI DSS prohibits merchants from sending emails that have full credit card numbers or primary account number unless using stronger encryption than TLS; so those numbers will have to be masked or only sent through a stronger encryption mechanism during the AMP callback to fetch data via HTTPS. Email clients may also need to be smart enough to delete sensitive data that it’s at rest in an email after it’s been fetched and displayed to the user.

This is really just the tip of the iceberg when it comes to compliance regulations that need to be thought through; not only for PCI and HIPPA but other regulations around the world.

Until regulations around sensitive data get addressed, AMP for Email still has the ability to change the way we work with email; creating a more secure environment against phishing and spoofing in the #1 communication channel between business and customer.

Happy Sending,

Jeff