A Marketer’s Guide to Email Infrastructure

(AKA what the heck are all these acronyms)

Photo by Stephen Phillips — Hostreviews.co.uk on Unsplash

In most organisations, email infrastructure is set up and maintained by an IT department, leaving an email marketer to happily send and optimise email with few delivery or deliverability worries (yep, they’re different). So, when exactly would a marketer delve into these uncharted territories?

If you’re on a blacklist, finding your emails are sent to the spam folder, or perhaps setting up an email program for a side hustle, you’re going to find yourself diving into the deep and murky depths of email infrastructure. It won’t be long until you come across these dreaded acronyms:

• SPF (Sender Policy Framework)
• DKIM (DomainKeys Identified Mail)
• DMARC (Domain-based Message Authentication, Reporting and Conformance).
• CNAME (Canonical Name)
• MX records (Mail Exchange)

There are many descriptions for these acronyms but if you’re anything like me, some of the explanations will leave you more confused than you were before you read them. Hopefully, this guide, written by a fellow marketer who has felt your pain, will clear up confusion and get you back to sending emails.

While it’s true that SPF, DKIM, and DMARC configurations aren’t mandatory, they do directly impact the inbox placement rates of campaigns. With all the time that goes into creating beautiful emails, it would be a pity not to put your best foot forward with the technical side.

SPF, DKIM, and DMARC are some of the policies that can help to place your email masterpieces in the inbox, rather than spam.

Let’s dive in.

First up: email delivery VS email deliverability

You might hear these terms used interchangeably, but that’s not accurate.

Email delivery is whether a mailbox provider accepts your email (yay) or it fails due to soft or hard bounces.

Soft bounces can occur when your recipients’ mailboxes are full (seems bizarre, but it does happen), your message was too large for their inbox, or because servers are down. Your email service provider may continue to attempt to send these messages for a specific period.

Hard bounces are more of a red flag; they happen when an email address is invalid or doesn’t exist (this is one of the reasons double opt-in is so widely touted), or you have been blacklisted.

Email deliverability, on the other hand, refers to the percentage of emails that reach recipients’ inboxes. This is also known as the Inbox Placement Rate (IPR). Your Email Service Provider (ESP) is unlikely to show this data, but services like Return Path use seed lists to monitor whether your emails are placed in the coveted position in a recipient’s inbox.

On to the acronyms

In short, DKIM and SPF work together to provide email security for your domain. They are the policies that are used to authenticate that the sender of an email is who they say they are and have the authority to send emails from a specific domain.

To ensure your records are set up correctly, you’ll need to check that they are set up in your DNS (Domain Name Server — think of this as the phonebook of the internet).

Your DNS is likely to be wherever your website is hosted (if you’re not sure where that is, you can use a hosting checker to look it up). You’ll need to know this in order to make changes to your SPF, DKIM and DMARC policies.

For example, I’ve needed to set up my DKIM, SPF, and DMARC records on Route 53 because my website is hosted on Amazon Web Services.

Sender Policy Framework

SPF for email is not to be confused with UV protection — although if not applied, you can be badly burned. A Sender Policy Framework specifies exactly who is authorised to send emails on your behalf.

An SPF record prevents spammers from sending messages on behalf of your domain (also known as spoofing); it achieves this by requiring a TXT record to be published within your DNS.

When you’re setting SPF up in your DNS, the record name will be the name of the domain (or subdomain) you’re using to send emails.

Your domain can only have one SPF record, but if you send from multiple places (and you probably will!), you can alter the SPF record to include all of the platforms you send from. Remember, if you send to your database using an email service provider but also reply to emails using Google, you’ll need to include both of these in your SPF record.

Pro tip: Before you start building your SPF records, create a list of all of the platforms you use to send emails. If your transactional messages are sent from Amazon’s Simple Email Service but your marketing messages are sent from Hubspot, and you’re also sending emails from a billing management system like Chargify, you need to have all of your ducks in a row so you don’t miss anything. If you use dedicated IP addresses, you also need to have these listed.

How to set up an SPF record

1. All SPF records begin with the version: v=spf1
2. Following the version, add any IP addresses that you want to authorise to send on your behalf. This section will look something like this ip4:000.000.000.000 ip6:0000:0000:0000:0000:0000. If you’re not using dedicated IP addresses, move on to step 3.
3. Now, add all of the platforms you use to send emails with lookups, also known as include tags. You can include a maximum of 10 lookups (if you’ve got A or MX lookups, they also count towards your limit). For example, include:_spf.google.com include:mailgun.org
4. Once you’ve added all of your IP addresses and include tags, you need to wrap up your TXT record with one of three all tags:
a. ~all indicates a soft fail (emails that don’t pass SPF will be accepted but marked. If you use any platforms that don’t allow you to specify SPF, you’ll need to use this tag… better yet, though, move to a different platform!)
b. -all indicates a hard fail (emails that don’t pass SPF will be rejected)
c. +all allows any server to send email from your domain and isn’t recommended at all (beware — danger, reader! If you use this, any server can send email from your domain).

Now you’re ready to publish your SPF TXT record on your DNS. It will look something like this v=spf1 ip4:000.000.000.000 ip6:0000:0000:0000:0000:0000 include:_spf.google.com include:mailgun.org -all

Once you’ve published your SPF record, make sure you check it. MX Toolbox has a great SPF Lookup you can use to make sure you haven’t missed anything.

DKIM

DKIM stands for DomainKeys Identified Mail. Think of DKIM as the modern equivalent of the red wax seals, stamped with a family crest. Essentially, DKIM is used to authenticate the authority of the sender — sadly, this new authentication just doesn’t look as fancy.

If you’ve ever clicked on the dropdown arrow in Gmail, you may have seen a list of sender information. DKIM is how the ‘Signed by’ section comes to be. The existence of the signed by section means that Gmail has verified that the email was signed by the sender and that the message wasn’t tampered with.

DKIM uses asymmetric encryption which is just a fancy way of saying it generates a pair of keys — one is private, and one is public. The public part of the key is used in a TXT record for your domain; the private key creates the signature for each email. When your recipients receive your email, their server looks up the public part of your key and is thereby able to verify whether the email was sent by you, or by a usurper.

If DKIM fails, the ‘signed by’ section will not be applied and this can raise red flags for mailbox providers. Consequences can include sending you to the spam box or even blacklisting you.

So, how do you set up DKIM?

Most email service providers will generate this key pair for you (don’t expect to see the private key). You can usually find the DKIM TXT record in your ESP’s settings page. It’ll look something like this:

v=DKIM1; k=rsa; p=yourPublicKey.

Along with your DKIM record, your provider will give you a specific subdomain to use, which usually looks something like this:

provider._domainkey_.yourdomain.com

Again, if you use multiple platforms to send emails, you’ll need a DKIM record for each sending platform and to publish these individually as TXT records, using their unique required subdomains.

You’re getting there! Once you publish your DNS records, you’ll want to use a DKIM checker tool to check everything is working as you expect to.

DMARC

DMARC stands for Domain-based Message Authentication, Reporting & Conformance. It’s a mouthful, but it’s just a policy of what should happen if emails sent from your domain don’t pass DKIM and SPF. As the name suggests, it’s also where you can request reports to be sent.

There are two kinds of reports you can receive; forensic and aggregate. Forensic reports are only sent by an Internet Service Provider when the SPF or DKIM does not align with your DMARC policy. They generally contain data to help you identify the issue with a specific source or IP address. Forensic reports are typically sent immediately after the failure.

Aggregate reports are sent every day by default regarding a group of emails (i.e. all Google email addresses) and don’t contain personally identifiable information.

Unlike DKIM, you only need to create one DMARC policy. You’re on the home stretch.

A friendly suggestion: prepare for an influx of emails when you request DMARC reports. You’ll probably want to keep these separate from your own inbox and send them to a dedicated postmaster email address.

How to set up a DMARC policy

1. All DMARC policies begin with v=DMARC1
2. If you want to limit the percentage of messages subjected to filtering, you can set pct=x (where x is the percentage you want to filter using these rules. It’s pretty likely you’ll want to set this to pct=100).
3.Set the email address you want to receive forensic reports on with ruf=postmaster@domain.com
4. Set the email address you want to receive aggregate reports on with rua=postmaster@domain.com
5. Set your domain’s policy with one of three policy options:
a. p=reject (this is the one you’ll probably want to use)
b. p=quarantine (using this option, if emails don’t pass your DMARC policy, they’ll be sent to your recipients’ spam folder)
c. p=none (using this option allows emails through even if they don’t pass; setting your policy to “none” shouldn’t be a long-term strategy unless there is an extremely compelling reason.)
6. For any subdomains, you’ll use one of the three same policy options, but with sp (subdomain policy). Typically, you’ll want to set up a subdomain with its own DMARC policy, which will take priority over this one — but this is a fallback for you.
a. sp=reject
b. sp=quarantine
c. sp=none
7. Set up the alignment mode (i.e. how strict your DMARC policy is) for your DKIM rules with adkim=s for strict or adkim=r for relaxed.
8. Set up the alignment mode for your SPF rules with aspf=s for strict or aspf=r for relaxed.
9. For the reporting format, use the tag rf=afrf for message-specific failure reports. This stands for Authentication Failure Reporting Format.
10. Finally, set your reporting interval using seconds and the tag ri=86400 (that’s reporting every 24 hours).

Voila, your DMARC policy will look something like this: v=DMARC1; p=reject; sp=reject; pct=100; ruf=postmaster@domain.com; rua=postmaster@domain.com; adkim=s; aspf=s; rf=afrf; ri=86400

And now, you’ve guessed it, check that your DMARC policy is working properly.

CNAME

CNAME stands for Canonical Name. CNAME records are used to tell the internet that one domain is an alias for another domain name. It’s the internet equivalent of a marriage license, to demonstrate you’ve changed your name.

Some ESPs will require you to set up a CNAME record so that you can see sweet, sweet data for opens, clicks, and unsubscribes. If you need a CNAME, your ESP should provide it, along with instructions on how to set it up.

MX Records

MX stands for mail exchange. MX records are only needed if you want to receive incoming mail for your domains (and since emails should be a conversation, not a monologue, you probably will).

I’ll give you a tip so that you don’t fall into a trap: imagine this paragraph has red flashing lights around it. You should only ever have one source for MX records per subdomain. More than one source for MX records will break things. Bad things will happen. There will be confusion and frustration.

If Gmail is where you receive responses from your recipients, Google is your one source for mail exchange so you should only have Google MX records set up.

OMG, are we there yet?

It can be painful to set these records up the first time, especially if you’re not sure where to change these details or find information. Fortunately, even though many DNS hosts will warn you that it can take up to 24 hours for any changes to propagate, updates are usually completed and passed through to providers like our trusty friends at MXToolbox within minutes.

If you’re feeling overwhelmed, take a step back from all the acronyms, and focus on solving one issue at a time. Each policy is essentially a recipe; get to know the ingredients and the method, and you’ll be cooking in no time.

If you’re lucky enough to have an IT team that looks after all of this for you… maybe bake them something. They deserve it.

And if you’ve done this yourself, you deserve the whole damn cake.