Introduction

There are certain factors in an email that have nothing to do with how well your email is written or designed, but still impact the effectiveness of your email marketing.

These factors are technical, and can be neatly summed up with the term “Email Authentication.”

Email authentication has the largest impact on your deliverability. And poor deliverability rates translate to poor ROI from your email marketing. A bounced email is no better than a deleted email. Maybe even worse, since your subject line and email content have no opportunity to work if the email is rejected or goes to the spam folder.

So, properly setting up your email authentication is the groundwork for maximizing your email marketing performance.

There are several parts to setting up a complete email authentication system. So, we’ve split this guide into a few pieces that you can read through as you need them.

We’ll start from the very basics.

What is email authentication?

Email authentication a set of methods that receiving email servers use to ensure that emails are not forged. Authenticating an email verifies that the email message actually came from the sender listed in the “from” field in the email header, and that the email wasn’t changed by someone while it was in transit.

Email providers use email authentication to protect users from spam, phishing scams, and other malicious emails.

Most authentication information is transmitted in the email message header. The person reading the email usually doesn’t see the authentication information. So, authenticating your emails has no impact on the quality of your email content.

Simple Mail Transfer Protocol (SMTP), the basic email sending protocol, doesn’t include any authentication mechanisms.

So, SPF, DKIM, and DMARC standards were developed to enhance the security of SMTP. We’ll cover these standards in detail a little further on. For now, just know that you need to use all three of them to get a fully functioning email authentication system.

What are the available email authentication protocols?

Several methods exist that focus on different aspects of email messages.

Two of the most commonly used methods are SPF and DKIM. SPF is a form of email sender authentication. It validates if an email was sent from an authorized IP address. DKIM, on the other hand, is a form of domain authentication. It checks that an email arrives with exactly the same content that was sent.

Then there’s DMARC, the most sophisticated of these. It runs SPF and/or DKIM checks, and then performs an additional alignment check. Additionally, the email sender can instruct the recipient on how to treat messages that fail this test.

There’s also a Reverse DNS lookup. This is not, strictly speaking, an authentication protocol, but is also a vital way of validating a sender. If a PTR record is set up by a domain owner, an email server can resolve an incoming IP address to validate if that domain is authorized to send emails.

Configuring your email authentication is fairly easy, if you know what to do. Even so, it’s best if you work with your development team or domain administrator to ensure that you get everything set up correctly.

Let’s go over each of these methods in more detail.

What is SPF? How does SPF work?

Simply speaking, Sender Policy Framework (SPF) is a security mechanism created to prevent the bad guys from sending emails on your behalf. The mechanism is all about communication between DNS servers… and this is the point when it all starts to sound scary! But don’t panic. I’ll try to keep it as simple as possible.

Let’s say you’ve sent an email to Bob. But how does Bob’s DNS server know that the email was in fact sent by you? The problem is, it doesn’t really. Unless you have SPF set on your DNS server.

SPF defines which IP addresses can be used to send emails from your domain.

Bob's email server will look up for the spf record of your domain and check if the email received is from one of the IP addresses mentioned in the spf record. If the records match the email is accepted.

What apps should you include in your SPF?

The general idea is to make sure all applications that send emails on your behalf (and are using their own SMTP, not yours) are included in your SPF.

For instance, if you’re using Google Apps to send emails from your domain, you should put Google in your SPF. Here’s Google’s instruction on how to do this.

But it’s important to make sure, if Google is the only app that you should “allow” in your SPF. For instance, we’re using Outlook and MailChimp to send our newsletters. We include both of them in our SPF.

Should I include Clodura.AI in my SPF as well?

No. Like I mentioned, you should remember to put into your SPF record the apps that send emails on your behalf, but are using their own SMTP. Clodura.AI uses your SMTP to send your emails, so it’s more of an online email client with super powers than a mass email sending app.

That said, the deliverability of the emails sent from Clodura depends on the reputation of your domain. Setting SPF and DMARC will help you protect the good reputation of your domain, and thus improve the deliverability of your emails.

What is DKIM?

DomainKeys Identified Mail (DKIM) standard has been created for the same reason as SPF: to prevent the bad guys from impersonating you as an email sender. It’s a way to additionally sign your emails in a way that will allow the recipient’s server check if the sender was really you or not.

By setting DKIM on your DNS server, you’re adding additional way to tell your receivers “yes, it’s really me who’s sending this message”.

The whole idea is based on encrypting and decrypting the additional signature, put in the header of your message. To make that possible, you need to have two keys:

• the private key (which is unique to your domain and available exclusively to you. It allows you to encrypt your signature in the header of your messages.)
• the public key (which you add to your DNS records using DKIM standard, in order to allow your recipient’s server retrieve it and decrypt your hidden signature from the header of your message).

Setting DKIM is just putting the information about the public key into your server’s records. It is also a txt record that needs to be put in the right place.

Once you have set that up, each time someone gets an email from you, the receiver’s server will try to decrypt your hidden signature using the public key. If it succeeds, this will additionally authenticate your message and in result increase the deliverability of all your emails.

What is DMARC?

Domain-based Message Authentication Reporting and Conformance (DMARC) is an email security measure that protects your domain against being used by the bad guys and gives you better control of your email deliverability. It’s based on the SPF and DKIM mechanisms.

DMARC allows you to conclude if an email you got was legitimately sent by the person who claims to have sent it. That’s the authentication part.

If the email doesn’t pass the DMARC test, it will be handled in line with the DMARC policy that has been set by the receiver. That’s the conformance part.

DMARC also makes it possible for the receiver to send reports to the sender, describing how the message was handled: was it let through to the main inbox, did it end up in a spam folder or was it rejected. And that’s the reporting part.

All in all, DMARC allows email receivers to check if the incoming email matches with what they know about the sender. And if it doesn’t, it tells the receivers’ servers what they should do with such a message.

It’s not set up by default – you need to do it yourself if you want to put an additional email security measure on top of your SPF and DKIM mechanisms.

DMARC is published in the DNS by the domain owner, alongside SPF and DKIM. It’s a simple one-line record.

Here’s an exemplary one:

    v=DMARC1; p=none; rua=mailto:admin@clodura.ai;

How does DMARC work?

DMARC specifies what has to happen for the message to go through to the inbox, and what will happen if the conditions aren’t met.

When an email is being tested by DMARC, 4 things might (or should) happen:

• DKIM pass – the additional signature put in the header needs to be validated: the private key matches the public key published in DNS.
• DKIM alignment – the parent domain matches the Header From domain.
• SPF pass – the receiving server will take the domain included in the Envelope From address and check for an existing SPF record (and it checks if the IP address is included in the SPF record).
• SPF alignment – the domain in Envelope From matches the domain in the email’s Header From.

A message will fail DMARC if it fails both SPF and DKIM.

Keep in mind, though, that if you forward a message, only the DKIM stays aligned.

DMARC policies and reporting

There are three possible DMARC policies:

• none - all the emails will go through, even if they don’t pass the SPF and/or DKIM test
• quarantine - the ones that don’t pass will be redirected to the spam folder
• reject - they will bounce