Ultimate Guide to Email Authentication

What is email authentication?

The role of email authentication is to confirm that you, the sender, are who you say you are. This makes it much harder for spoofers to impersonate you. Authentication also improves your email deliverability by providing mail servers with the assurance that they are indeed dealing with you, and only you (not that “J0hn from M1cr0s0ft” guy who urgently needs you to update your credit card).

When an email is processed by the incoming server set up for your recipient, the results (success or failure) of your authentication efforts are received. With this information, the server can then determine if the message should be delivered to an inbox, sent directly to spam, or discarded from the server.

If your emails are not authenticated at all, there’s a good chance your message will be considered spam or rejected. The same may happen if you’ve set up one or more authentication methods, but any of them fails. For this reason, quickly setting up a single authentication method can cause more harm than good. The best thing you can do is set up multiple methods, and regularly monitor how they affect your emails.

What are the available email authentication protocols?

There are several methods 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 the email was sent from an authorized IP address. DKIM, on the other hand, is a form of email domain authentication. It checks that 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 (more on this later). Additionally, the email sender can give instructions to 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 method, 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.

And finally, there’s a new kid on the block, BIMI Record. BIMI is not publicly available yet but is being tested as we speak. When it goes live, it will give corporate brands a way to visually authenticate their emails; more on this a bit later.

Let’s now talk about each of these methods in more detail.

Sender Policy Framework (SPF)

SPF is a record that belongs to the domain’s DNS. It is a simple TXT file (previously used SPF has been deprecated). In this file, domain owners specify the list of IP addresses (mail servers) that are authorized to send emails from a given domain. When an email arrives at a server that processes incoming mail on behalf of a recipient, a quick check is performed.

A server runs a DNS lookup of an “envelope sender address” (aka “return-path address”). When it finds an SPF record, it scans the list of authorized addresses for the record. If there’s a match, the result of an SPF test is positive. In any other case, the check is negative; in this case, a “SoftFail” will be triggered. This means that the server should still accept the email, but will mark the SPF check as failed, which serves as a reason for an email to be discarded.

Because of its wide adoption, SPF is considered to be a must-have for all regular email senders. Having SPF immediately increases the changes of valid email delivery. If you’re not sure if you have SPF set up or if it’s up to date, you can quickly check via easily available tools (for example, those from MX Toolbox).

Example of an SPF record

Now, let’s stop theorizing and see what an actual record looks like. If you were to look up our domain, you would find the following record:

v=spf1 include:_spf.google.com include:sendgrid.net include:_spf.reply.io ~all

Let’s examine this step by step:

• v=spf1 -> The beginning refers to the version of SPF in use. In almost every case, it’s simply “spf1’” – version 1, also known as SPF Classic.
• include: -> Here, we specified which domains we use to send emails from the mailtrap.io domain. As you can see, we use SendGrid, Reply.io, as well as Google (Google Apps to be specific). Optionally, an additional parameter can be added before “include”, but does not change anything here.
• ~all -> Finally, this specifies that all other domains are not authorized to send on our behalf. ‘~’ in this case means a SoftFail recommendation.

Instead of server names, you can also use IP addresses in both ip4 and ip6 formats. Here’s the example for SendGrid:

v=spf1 ip4:167.89.32.5 ip4:167.89.32.50 ip4:50.31.36.199 ip4:50.31.36.205 ip4:50.31.36.208 ip4:50.31.36.213 ip4:50.31.36.197 ip4:167.89.25.84 include:_spf.google.com include:partners.sendgrid.com include:_labs.sendgrid.com -all

There are several optional parameters that may be useful if you want your records to be more (or less) strict. For more about this, please check our article on SPF Records where we also address common misconceptions, SPF setup, and validation instructions.

How to use SPF correctly

SPF comes with several qualifiers that give an email server information about how to treat IPs/hosts outlined in an SPF record. The available qualifiers are:

• ~ -> SoftFail – accept emails but marks SPF as failed
• – -> Reject – reject emails
• + -> Pass – allow emails (if no qualifier is used, + is assumed)
• ? -> Neutral – no policy (results of a check are not marked)

Note that these are just suggestions given to a server; they can be ignored. An IP with a “Pass” policy may be rejected or sent to spam, while a ‘Reject’ policy may not stop an email from finding its way to an inbox.

In the example above, you can see two different approaches:

• SendGrid chose “-all” policy, which means they suggest rejecting all emails if they don’t meet the earlier criteria. This approach is generally recommended only for the most secure domains, as it can lead to legitimate emails getting discarded.
• Our SPF includes “~all” policy. IPs failing a test still have a chance to be accepted, but will be marked as “SPF failed”. This more relaxed approach is recommended for most email senders, and makes for a good balance between security and deliverability. The “Neutral” approach is also frequently used.

Note that when you use DMARC along with SPF, your SPF policy will not apply.

DomainKeys Identified Mail (DKIM)

DKIM is another must-have authentication. It’s a digital signature that’s attached to an email, encoded at the moment of sending and validated when an email is about to arrive to a recipient. When DKIM is configured, a public key is generated and added to the domain’s DNS along with the DKIM record.

When an email is created and sent, a DKIM signature is created. It contains hashed details such as email headers and a body, encrypted with an individual, private key. When an email arrives, a server retrieves a public key from the sender’s DNS. With this key, it can recreate the hashes for the received message, and compare them against the ones it received. If they match, the test is passed. If a message was modified on the way (for example, its body has been changed), the DKIM test will fail and the message is likely to be discarded.

Example of a DKIM Record

A typical DKIM looks a bit more complex than SPF. Let’s look at an example:

DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=newyork;
c=relaxed/simple; q=dns/txt; t=1117574938; x=1118006938;
h=from:to:subject:date:keywords:keywords;
bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
VoG4ZHRNiYzR

It features a number of tags, the most important being:

• s= -> selector, which is a label associated with a given domain’s DNS. A domain can have multiple selectors, letting its owner create multiple DKIM records for different purposes (e.g. one for sales email, another for newsletters, etc.)
• bh= -> hashed message body
• b= -> the digital signature in hashed format

There are a number of other mandatory and optional tags you can use in DKIM. Please check our dedicated DKIM article for a detailed overview of DKIM records, and instructions on how to set up and test DKIM.

Good practices for using DKIM

DKIM offers no mechanics for telling a server how to treat failed attempts; it focuses on just one aspect of phishing prevention. Because of that, it’s highly recommended to combine DKIM with SPF whenever possible. This way, you can verify where the message originates from, and if it has been modified in the process.

A good practice is to also update your private and public keys on a regular basis (once or twice a year is perfectly fine). It’s also a good idea to have a few available selectors, and change keys one at the time. Why?

When keys change, some emails may still be processed and their DKIM tests will fail. To prevent this from happening, you can add two signatures to an email with two different selectors. When keys change for one, the second will remain unchanged, and DKIM tests will most likely pass.

Domain-based Message Authentication Reporting and Conformance (DMARC)

DMARC is not an authentication method, strictly speaking. It builds on SPF and DKIM and adds an additional level of security, known as domain alignment. DMARC also allows you to set up a policy for failed checks, and can help with generating email performance reports. All of these features combined make it the most reliable measure you can take against spoofing.

DMARC requires either SPF or DKIM to be present, but best practice is to have both in place. This way, your emails are more secure and DMARC operates at its full strength.

When a DMARC-aligned email arrives, at first it’s business as usual. SPF and/or DKIM checks are performed. Then, a domain alignment is performed. The server checks if:

• SPF: the “envelope from” email address matches the “return-path” address. In other words, it checks if the sender email address is the same as the address a potential reply would go to.
• DKIM: the value of the ‘d’ tag (sender’s domain) matches the sender’s domain.

Domain alignment can be set to either “relaxed” or “strict”. Picking the right option is particularly important for those who use external services (ESPs) to send emails. For example, if you forget your Mailtrap password and wish to reset it, you’ll receive an email from [e-mail]. At the same time, the return-path address for this email would be something like “bounces+8208408-cfe8-user=[e-mail]”.

If you were to set the “strict” SPF alignment, DMARC would fail, as the domains of both addresses are different. If you chose the “relaxed” setting, the alignment test would succeed.

With DMARC you can also provide guidance to the recipient’s email server on how it should handle failed tests. You can pick from the following three policies:

• Reject – discard the message
• Quarantine – admit a message but send it to spam
• None – do nothing

Finally, if you use DMARC, email servers will send aggregate diagnostic reports on the performance of your emails. This way, you can quickly spot when legitimate emails fail a DMARC test, and you will be able to take action accordingly.

For a more detailed explanation of how DMARC works, please refer to our DMARC article.

Example of a DMARC record

Now, let’s look at the example of a DMARC record:

v=DMARC1; p=none; rua=mailto:[e-mail]; ruf=mailto:[e-mail]; fo=1; adkim=r; aspf=r

The tag descriptions are explained as follows:

• v -> version of DMARC. It’s always “DMARC1”.
• p -> DMARC policy in use
• rua -> email addresses that will receive daily aggregate reports about emails failing DMARC checks.
• ruf -> address that will receive real-time, individual alerts about failed checks. This can be the same or different than “rua”.
• fo -> (optional) setting for ruf reports. Available options: 0 – send if DMARC check fails; 1 – send if any check within DMARC fails (e.g. domain alignment for SPF); d – send only if DKIM fails; s – send only when SPF fails. Default value – ‘0’
• adkim -> (optional) domain alignment for DKIM, can be either ‘r’ (relaxed) or ‘s’ (strict). Default value – ‘r’
• aspf -> (optional) domain alignment for SPF, same options and default value as “adkim” above.

For further explanation and more optional tags, please check the DMARC guide we mentioned at the top of this section.

Doing DMARC right

Seeing how robust DMARC is, you would expect wide adoption across businesses and organizations. Sadly, the adoption rate is still low, and maybe that’s why spoofing is still a serious threat. If you’ve already taken care of SPF and DKIM, there’s a strong case behind adding a DMARC to your portfolio.

It’s not worth rushing, though. It’s fairly easy to fail one of DMARC’s tests without proper preparation. For this reason, the “none” policy (as in the example above) is a recommended start. This way, DMARC checks are still performed and you receive forensic reports, but legitimate emails are not affected. A handy “pct” tag lets you also choose the percentage of emails that will be subject to a chosen policy. All others will be processed using “none”.

Reverse DNS & PTR Record

Another important mechanic that makes scammers’ lives miserable is a Reverse DNS. It differs from typical authentication methods, but is fairly easy to understand and configure.

Every domain on the internet resolves to a particular IP address. To make browsing and emailing easier, we use domains such as Mailtrap.io rather than the corresponding IPs (54.160.117.161 in this case). If you want to load our homepage, either method will work for any modern web browser.

Since we also use domains rather than IPs when sending emails, email servers need to fetch the IP behind every domain each time. This process is called DNS Lookup. The record we’re looking for is an A Record. To add a layer of security, email servers run a reverse process simultaneously. It’s aptly named “Reverse DNS lookup”, and the records involved in it are called PTR records.

When a PTR record is detected, a server runs a check. For an email to pass this check, A PTR record needs to match an A record, as in the example above. When it does not match or no record is found, an email is unlikely to reach the recipient’s inbox. Because of this, consider Reverse DNS to be a must-have solution, along with other authentication methods.

Check out our article on PTR Records for more on what they are, and how to set them up. Also, feel free to check this DNS guide to know more about spam prevention using these records.

BIMI Record

And finally, a new option on the market is quickly emerging. It’s also aimed at spoofers but unlike all of its predecessors, it doesn’t run any background checks. Instead, Brand Indicator for Message Identification (BIMI) is aimed at improving the credibility of legitimate emails. How?

BIMI is a text (TXT) DNS record file. In it, brand owners can store the brand’s visual representation – most often a logo. When an email is received by a server, the server runs the usual DNS lookup for the sender domain. If it finds a BIMI record, it will fetch it, and supporting email clients will display next to the message, as in the example below:

At first, this may seem like only a marketing gimmick, but it has the potential to be much more than that. When more businesses start using BIMI, customers will become used to seeing their logos next to emails. If a phishing email arrives, no BIMI record will be detected or retrieved. As a result, the email will look different than expected, quickly raising a red flag for many recipients.

Don’t worry – BIMI won’t be the only layer of security. All brands participating in the program must be DMARC-certified. As a result, very few phishing emails will likely go through. And if they do, BIMI will be waiting for them.

It also won’t be easy to impersonate your brand (e.g., by creating a BIMI record for a similar domain), stealing your logo in the process. All participants of the BIMI program will need to register, obtain a valid certification, and maintain a good email sending history. Check our BIMI Records article for more details about these requirements.

BIMI is currently in the beta stage and is being tested by several email providers. We’ll be sure to update the article when a more open version of the program is launched.

Other considerations

With email authentication, it’s not a question of whether you should have it, but how many methods you should implement. In most cases, the more the better; but not without proper research and testing.

When testing your authentication, you’ll inevitably send several test emails. Sure, you can spam your own or a colleague’s inbox, or create dummy accounts, but there’s always a chance that your test emails will reach your customers. To prevent that from happening, consider setting up a safe testing environment with a tool like Mailtrap.

With Mailtrap, you can capture all of your outgoing emails, and inspect them in dedicated inboxes. You can quickly detect any HTML/CSS issues, view the spam score of each message, and forward individual (or all) emails to colleagues or clients; all of this with zero chance of spamming real users.

---

I hope our guide was useful for you! You can find the original version here at Mailtrap Blog. See you next time!