send.Better()

Giving Email a REST

Matthew Clemente

@mjclemente84

@mjclemente

Isn't Email Dying?

The report of my

death has been grossly

exaggerated.

Nearly half of us can’t even use the bathroom without checking email... In sum, Americans are addicted to email.

Teens and younger Millennials told us that they have email addresses... because "It's a fact of everyday life"

Adestra Consumer Digital Usage & Behavior Study 2017

Adobe Digital Insights Email Survey 2016

Who?

Not...

  • Mandrill

  • Mailjet

  • SendinBlue

  • Campaign Monitor

  • Knowtify

  • Elastic Email

  • Pepipost

  • Etc., etc., etc.

Transactional

Marketing

Messages to groups of users that are not triggered by a specific action on their part. Examples include newsletters, invitations, announcements, and promotions.

Email triggered by a user action or an action they were the target of. Directed to individuals,   not groups. Transactional emails are part of an interaction.

Transactional Email?

  • Account creation

  • Email verification

  • Password reset

  • Receipts

  • Requested updates

  • Comment notifications

  • Weekly digests or reports

What these services do is enable developers to easily

utilize email as a first class citizen in their application

to enhance that interaction. That is, to improve the interface.

Transactional emails are part of an interaction. Interaction implies an interface.

Email Is An Interface

Email is a fundamental, inescapable point of interaction.

Examples

You can build a better email interface for your application.

Benefits

  • Easy to integrate
  • Logging
  • Extensibility
  • Reporting/Analytics
  • Templates
  • Deliverability,
  • Inbound/Webhooks

Example

So which is best?

?

Generalized Use Cases

If the single most important factor is cost...

Looking to combine marketing/transactional

Only sending transactional and can't afford missing emails

Developer friendly (better marketing support)

Developer friendly (better logs / inbound handling)

Best Practices: DNS

SPF + DKIM

SPF: Sender Policy Framework

Lets ESPs know what servers are authorized to send email from a domain. Basically just a list of approved senders.

DKIM: DomainKeys Identified Mail

Enables ESPs to verify the sending domain of an email and that its contents have not been altered-in-transit. The sender digitally signs the email using a private key that recipients can authenticate via a public key.

Setup/Example

  • Prior to adding a domain, you can only email verified recipients
  • Recommended setup is on a subdomain: mg.mattclemente.com
  • You can still send from the root domain
    • @mattclemente.com
  • Sending from the subdomain can be done to separate reputation
    • @mg.mattclemente.com
  • Routes can handle inbound emails to subdomain addresses
  • There isn't support for templates, though there are ways to send the same message to multiple users

Best Practices: DNS

 SPF       DKIM = DMARC

DMARC: Domain-based Message Authentication, Reporting & Conformance

Addresses shortcomings in SPF and DKIM by tying those standards to the "From" domain. Additionally, provides domain owners with reporting on who is sending from their domain, and authority to dictate how it is handled.

Best Practices: DNS

 SPF       DKIM = DMARC

Domain owners can publish a DMARC record which tells ESPs that SPF and DKIM records must be in "alignment" and what to do if they're not.

  • SPF: "From" domain matches the Return-Path
  • DKIM: the DKIM-signature domain matches the "From" domain
  • Action if not aligned: None, Quarantine, Reject
  • Provides a way for ESPs to report back about emails handled
  • Reporting can be done without impacting email delivery

Best Practices: DNS

 DMARC Resources

You should set up a DMARC policy for your domain. You can send DMARC compliant emails from all the transactional email providers discussed.

Inbound and Webhooks

Setup/Example

  • You don't need to "Whitelabel" a domain in order to send
  • Whitelabel setup must be from a subdomain, but is otherwise similar to that of Mailgun.
  • "Automated security" for Whitelabel is uses CNAMES so that SendGrid can manage the DKIM, SPF, and MX records
  • The email object very complex, which has pluses and minuses. All API wrappers use a Builder object to put it together.
  • There is support for hosted email templates.
  • You also should to add include:sendgrid.net to the SPF record of your root domain!

Setup/Example

  • Can't send until a domain is set up (only DKIM required)
  • Recommended setup is on a subdomain: sp.mattclemente.com 
  • There is robust support for stored templates, including basic substitution logic and defaults
  • You cannot send from the root domain if you have only configured the subdomain.
  • If you verify the root domain, for optimal performance, you should add include:_spf.sparkpostmail.com to your root SPF record
  • Set the Return-Path (Bounce Domain) via the API, not the dashboard.
  • The template includes the "From" domain

Setup/Example

  • Only transactional emails allowed.
  • You need to verify either a Domain or Email Address to send
  • While subdomain setup can be done, the instructions are geared toward being set up under the root domain.
  • Sender Signatures (verified senders) are different than "Servers", which are used for account organization.
  • Extremely robust template support, including a number of pre-coded, standard templates that can be customized.

send.Better()

Giving Email a REST

Matthew Clemente

@mjclemente84

@mjclemente

Sources of Data and Quotes for Growth of Email

Sources for Examples of Transactional Emails as an Interface