Everything Developers Need To Know About Sending Transactional Email

Let’s imagine you’re developing a new feature or application. The end is in sight. All the complicated infrastructure, databases, APIs, tests are looking good. Then you realize there are key points in the system where you need to send “transactional” emails; password reset, welcome emails, receipts, invoices.

You know there are services and APIs you can use to handle this for you but as you start to look into sending email you realize it’s going to be harder than you thought. Especially if you want to use the designs that your designer, product manager or marketing manager had in mind.

This is a common scenario. As developers we rarely think about transactional emails until after building out the product. But that is OK as there are a bunch of solutions out there that have your back. It has been a long time since you had to rely on setting up your own email infrastructure to handle sending, receiving, bounces, unsubscribes etc.

That said, there are a few key things you need to know about building HTML emails, sending emails and maintaining a good sender reputation score. This checklist will help you prepare for your next project that has transactional emails. We’ll be covering:

1. What Are Transactional Emails?
2. Pick Your Email Service Provider (ESP)
3. A Guide to Deliverability and Reputation
4. Coding Responsive HTML Email
5. Email Resources for Developers

Note: this tutorial is part of a whole week’s worth of email content on Tuts+ Web Design–check out the Mastering HTML Emaillearning guide for more!

What Are Transactional Emails?

You could categorize emails that companies and apps send into:

• Transactional emails
• Marketing emails

You could break these down further into sub-categories, but for the purpose of what we’re talking about here let’s stick with these two.

Marketing emails are typically promotional in nature and handled by marketing teams. They include monthly newsletters, seasonal promotions, company and product updates, new releases etc. There is a content and lifecycle strategy behind when and how often to send them.

Transactional emails are those triggered by user behavior and typically implemented by developers or product teams. The user does something in your app which causes an email to be sent. These include:

• Welcome emails
• Confirmation emails
• Password resets
• New invoices/receipts
• etc.

Most of these emails you’ll probably send yourself, but you may also be sending these through 3rd party services, for example Stripe for receipts, Shopify for e-commerce.

The rules for transactional and marketing emails differ slightly. GDPR came into effect on May 25th 2018, so anyone sending marketing email is required to gather explicit permission from subscribers and maintain a record of that permission. As it stands you don’t need explicit permission to send transactional emails, e.g. a receipt to someone who just purchased something from your store. However there are advantages to keeping in line with the GDPR regulations no matter what types of email you’re sending.

Pick Your Email Service Provider (ESP)

It’s quite possible to set up your own mail server and manage sending email yourself. If you’re at a big company like Google or Facebook you may even have your own email infrastructure team dedicated to supporting transactional mail.

For the majority of us I don’t recommend setting up and maintaining your own mail server. There is a lot of overhead involved in support and maintenance. Instead, use one of the ESPs out there. They have great APIs for developers and are reasonably priced, usually with generous free tiers.

SendGrid Mailgun Postmark Mailjet SparkPost

Each of these ESPs are feature rich with everything you need to manage transactional mail:

• Sending email via API or SMTP.
• Receiving and parsing incoming email.
• Metrics for sent, received, bounced, opened, clicked emails.
• Unsubscribe and suppression list management.
• Reputation monitoring.
• Feedback loop management.
• GDPR compliance and more.

Once you’ve picked your ESP it’s time to set things up.

A Guide to Deliverability and Reputation

Mailbox providers (like Gmail and Outlook) look at a little thing called reputation . You want a good reputation to ensure your email gets into recipients’ inboxes. If you have a bad reputation then your email will either go to spam or the email provider may reject it and it will bounce.

According to Talos , in July 2018 the average daily amount of spam sent globally was 305.95 billion. You don’t want your mail to fall into this bucket.

Average daily spam volume

Things that can contribute to a bad reputation:

• Recipients flagging your email as spam.
• Recipients not opening or engaging with your email.
• You send too many emails.
• You send emails from an IP address that has bad score.
• You haven’t setup DKIM, SPF and DMARC.
• The content you send looks like spam.

The three main authentication methods you need to consider are SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) and DMARC (Domain-based Message Authentication, Reporting and Conformance).

SPF is a way for mailbox providers to authenticate that the email actually did come from your domain. It is a TXT DNS record that you’ll have to add yourself via your DNS management.

domain.com. TXT "v=spf1 include:domain ~all"

DKIM uses public/private key pairs to sign each message with a unique cryptographic signature, designed to detect email spoofing. When you hit send, your ESP will add a private signature, then on your DNS sits your public signature, which the recipient’s mailbox provider will call to ensure all looks good.

_domainkey.domain.com. TXT "v=DKIM1; k=rsa; p=PUBLIC_KEY"

DMARC is not an authentication protocol but allows you to set a policy for what to do with messages that don’t pass SPF or DKIM, whether that be reject or quarantine.

_dmarc.domain.com. TXT "v=DMARC1; p=reject; pct=100; [email protected]"

Here’s an example of how email authentication all comes together. This is oversimplified, but gives you an idea of how it works.

Email authentication (src: htmlemail.io )

Reputation is tied to both your sending domain and the IP address you use, so you want this to be static. Checking your IP address is the most basic method a mailbox provider (Gmail, Outlook, Hotmail, Yahoo, AOL etc.) has when checking your reputation. When you send over 50,000 emails per week you should consider using a dedicated IP so you’re not sharing it with others, giving you some more isolation. And keep in mind you need to “warm up” IPs. You shouldn’t just start sending millions of emails from a new dedicated IP right away. Most ESPs offer this feature.

Another thing to consider is using separate IPs and subdomains for your transactional and marketing email. I typically set up something like send.mydomain.com for marketing and notifications.mydomain.com for transactional emails.

Don’t send from a “no-reply@” email address. First of all it looks bad to your recipients as it looks like you don’t care and don’t want to hear from them. Second of all, it’s a great thing when recipients reply and engage. This is what mailbox providers like to see.

Use tools like SenderScore and SenderBase to monitor your reputation.

Coding Responsive HTML Email

MIME Multipart

When you send an email it is constructed of headers and different parts. This is known as Multipurpose Internet Mail Extensions (MIME). This combines plain text, HTML and/or other parts and leaves it to the recipient client to decide what and how to display it.

• Headers contain key value pairs like who the original sender was, the subject, reply-to address, and a bunch of other interesting data. Within your body you have different “parts”.
• text/plain is the simplest form of sending an email with text only and no formatting.
• text/html enables HTML. This is where your HTML email goes.
• text/watch-html is for watches, like Apple Watch, and has limited HTML support.
• text/x-amp-html is a new part that brings interactive content to Gmail with AMP for Email .

For most emails you’ll send a plain text part and an HTML part. Mailbox providers like to see both. The good news is that ESPs handle all this for you. It probably isn’t something you need to think about unless you’re trying to do something more advanced with email.

If you’re curious how it all looks, in Gmail click View original (or Show original ) and it will show you how the sausage is made. Piecing these all together is quite complicated which is another good reason to use an ESP who does this all for you.

Tables and Inline CSS

When coding HTML email it is (still) recommended we use tables ( <table> ), table rows ( <tr> ) and table cells ( <td> ). A lot of email clients are getting better about supporting modern HTML and CSS, but you risk them falling apart in certain email clients.

There are a lot of email clients out there. Litmus , an email testing tool, currently supports over 90 clients across desktop, web and mobile. These email clients all use different rendering engines. Some use Webkit, some Internet Explorer, some Microsoft Word. And they all add some of their own flavor of styles and classes on top of what you provide.

Read more about email rendering engines.

With this in mind you’re advised to play it safe and stick to some rules when coding for email.

• Use <table> instead of <div>
• Use full hexadecimal colors #ff6600 instead of shorthand #f60
• Use padding instead of margin
• Use background-color instead of background
• Use inlined CSS instead of embedded CSS
• Stick with system and web safe fonts
• Add role="presentation" to each table so that it’s clear to screen readers the table is being used for layout
• Use semantic HTML tags, such as <p> and <h1> , where applicable

For example, here is how I typically code buttons for HTML email, using an outer table for alignment, and an inner table for the button shape.

It’s a pretty bulletproof solution:

Writing CSS inline can be monotonous, not to mention hard to maintain, and unscalable, especially for big teams. This is where you want to use a CSS inliner or someautomation toolset to help you build and inline your templates. Frameworks like MJML and Inky give developers a more friendly templating language to work with.

Inky MJML

Note: you can use media queries and conditional statements to target certain clients–with them you can have special layouts for Outlook or make use of web fonts in Webkit clients. Check out this simple open source responsive email template to get you started or read more about these techniques for coding more advanced HTML email templates.

Do I Really Need to Use Tables and Inline CSS in 2018?

It depends. If you want to play it safe and make sure your emails are bulletproof, then yes.

• 

  Email Design

  Creating a Simple Responsive HTML Email

  Nicole Merlin

If you have good insight into your recipients and you know they use email clients that have support for embedded CSS and the box model, then maybe not. You can definitely take the risk and it may not be a problem. I personally stick with old habits and use tables and inline CSS but many others are starting to experiment with the “no inline” option.

Images, GIFs, Video & Media

Some clients (notably Outlook) will block image rendering by default, forcing recipients to opt-in to see your images. With that in mind always give your images meaningful ALT text.

• 

  HTML

  Quick Tip: Remember to Style Your ALT Text

  Nicole Merlin

You’ll want to provide high quality images for retina screens (e.g. iPhone) therefore your images should be at least 2x the dimensions you want to display them at. With that in mind, always give your image a width attribute to stop it overflowing on some clients.

<img src="https://your-cdn.com/image.png" alt="Descriptive text" width="600px" height="300px" border="0" style="display:block; max-width: 100%;">

Animated GIFs are supported in most clients. Video is supported on iOS, Apple Mail and Outlook.com. You can also experiment with emojis in your subject lines to get recipients’ attention

Compress your media assets and upload them to a content delivery network (CDN), such as Amazon Web Services, Cloudinary or imgix. A lot of ESPs will handle this for you.

tl;dr

And we’re done! Let’s recap:

• There is more to sending email than meets the eye.
• Use a developer friendly API service to manage email for you.
• Set up SPF, DKIM and DMARC for your sending domain.
• If you send a lot of email pay for a dedicated IP rather than using a shared IP.
• Send plain text and HTML emails.
• Use tables and inline your CSS so they don’t fall apart across email clients.
• Remember to test your emails on email clients and across devices.

Email Resources for Developers