Email is fine. It works. It sometimes feels a bit clunky and slightly antiquated, but it works. As a web developer, it’s one of these tools I barely think about. The app sends emails to the user because that’s what apps do. Nothing to see here. But last week, a seemingly innocuous piece of feedback got me thinking, and thinking got me obsessing:

“When users book an appointment with our organization through your app, they have to enter a six-digit code to verify their email. Could we skip that step entirely? I’m guessing it’s for security purposes, but we’d like to avoid the extra friction.”

They have a point: while this kind of email verification is somewhat standard, it does feel a bit slow and tedious, and it gets annoying if you have to do it multiple times a day.

Of course, there’s a tradeoff between convenience and security here. It’s hard to improve one without losing a bit of the other, but this got me wondering: assuming we do need to email this code, what could we do to make this process smoother?

There are often some nicer UX patterns when these codes are sent by text message: the code is highlighted, and there’s a shortcut to copy it to the clipboard. But not for email. To my inbox, this is an email just like any other. It displays and handles it the exact same way it does for a message from an actual human or an update for a package delivery.

This is what I started to obsess over. Why does it have to be like this? The passcodes in these emails often expire after a few minutes, surely they could be removed from my inbox automatically. And there’s the same problem for password reset emails. They also follow a fairly standard workflow, but there’s no specific support from email clients. Why?

In both of these cases, I try to log in, the app reacts with an email, I open my email client, and it takes me back to the app, leaving the email read but not archived. Why doesn’t the client archive (or even delete) these automatically? When I open my inbox again a few hours later, why do I have to click “archive” like a caveman?

This started to drive me crazy. I thought there had to be some “advanced email” techniques out there that I just didn’t know about, and that would solve these issues. So I went looking for some optional ways developers could add structured information to email.

My research was a bit disappointing. The first thing I found is a form of markup that allows Gmail to summarize information at the top of some emails, but it doesn’t seem to be supported by anyone else. And it doesn’t really work for these use cases anyways. No luck there.

I then learned about the X-Priority (or X-MSMail-Priority) STMP header, an attempt by Microsoft to let the sender define the priority of the email. This doesn’t seem to be very widely used. I assume everyone sending out promotional emails wants their email to be considered of the highest priority, while the people receiving some random newsletter would disagree. And it wouldn’t solve our problem either anyways.

The one interesting lead I found comes from Hey, a more modern email client. They have a specific “Papertrail” inbox for receipts and various confirmation emails. I quite like this idea, and along with one-time passcodes and password resets, it’s a good other use case for a specific category of email that deserves a specific UX. I couldn’t find any documentation on how to provide this information to the clients as an application developer, so I’m assuming it works based on some machine learning classifier.

The one nifty “advanced email” technique that I found is the List-Unsubscribe header. It’s just an SMTP header adding a URL that the email client can use to display a one-click unsubscribe without the user having to actually open the email. I think that’s a great example to follow: it’s fairly simple to implement, it enhances the experience if the client supports it, and doesn’t break anything if the client doesn’t support it.

So while I couldn’t find any existing solution that solves our specific problem, I believe we can take cues from List-Unsubscribe to build one.

How do we get there?

Before implementing some fancy UX for one-time passcode, password resets and receipts, I think the first step is to allow email clients to recognize which emails need a different workflow. We could have clever machine learning classifiers (like the ones we use for detecting spam), but we could also do something much more reliable, simple, and cheap: developers sending automated emails could just label them.

We could add a custom SMTP header called X-Message-Type, with three possible values depending on the kind of email: one_time_passcode, password_reset, or receipt

When they receive an email with this header, email clients could then process it accordingly. It would be an optional feature, as not everyone will start supporting this right away, but this allows gradual adoption.

It’s hard to think of an easier implementation on the sender’s side: adding this header to these automated emails is a one-line change in most codebases.

On the receiver side, using this header to determine how to handle the email should also be rather simple.

Of course, as soon as this sort of pattern is introduced, we should ask ourselves, how can this be abused? This will really depend on what the actual UX offered by the email client is, but I’m hopeful that if it’s mostly auto-archiving messages, bad actors won’t have much to gain by mislabeling emails.

How do we get this going?

Since this convention needs to be supported both by email senders and receivers, this is a bit of a chicken-and-egg problem, but I think there’s an easy way forward.

Developers sending these emails can start labeling them right away. Even if the overwhelming majority of clients don’t support these features right now, the implementation is trivial enough on their side that we can start there. Having emails in the wild with this header will eventually signal to the email clients that it’s worth supporting these.

Email clients can start by recognizing these labels at the application layer, and by enabling custom workflows. In the same way you can sort incoming emails into directories by matching words in the subject, ideally you could add rules based on email labels. Clients can also publish which headers they support, in order to encourage more senders to use them.

Email sending platforms (such as Sendgrid or Brevo) could encourage developers to use these headers. They already have plenty of advice for improving deliverability (DKIM, DMARC, and such), so they could add these recommendations right along. Most of them support sending custom SMTP headers, so they wouldn’t need to do any additional development.

If you find this idea interesting, you can help too! Spread the word, and encourage more people to join in. My long-term goal is to get an RFC going to make this an official extension of the SMTP protocol, but it’s going to take quite a bit of real-world usage and feedback before we can get there.

Ultimately, this is about improving everyone’s experience on the web. Email as a shared protocol has been a backbone of the open internet, enabling people to communicate without having to subscribe to the same provider. If we want to keep the web open, we have to keep a high standard of user experience, and I believe this is a good step towards making email a little bit smarter.

In the meantime, I’ve set up a Github repo to document the spec, and list the first early adopters. Feel free to star the repo to show some public support for this idea! I’d also love to get more feedback. Do you think the header should have a different name? Do you think this information should be in the markup rather than the header? Can you think of other types of email that could be added to the list? Let me know by opening a new issue or joining the conversation on an existing one.