As discussed in Lesson 1, the history of email, Deliverability is forever developing, not only to suit how people are intereacting with email but also to try and prevent some of the attacks that threaten ESPs, ISPs and their consumers.

One of the burning questions with email is, how do we know this email is from who it says its from, how do we know if this is a legitimate email?

Luckily for us, there are ways in which we can obtain this information and this is vital for us to have confidence in the knowledge that our emails are authenticated.

There are several types of authentication, to name the most commonly known ones they are:

Below i shall briefly describe how they work to authenticate emails and prevent the attacks mentioned in Lesson 3.

SPF

SPF stands for Sender Policy Framework, this is an open standard specifying a technical method to prevent sender address forgery.
SPF protects the envelope sender, which is sometimes referred to as the return path. The envelope sender is used to transport the message from mail server to server. Please note this is different from the ‘header sender address’ the difference being the header sender address is often displayed by email programs and is often not looked at by ISPs, whereas the ‘envelope sender’ is often not displayed, however these can be obtained by looking at the headers of the email.

In this Policy there are certain rules the sender needs to adhere to, they are:

– domain owner publishes information in the form of an ‘SPF record’ in the domain’s DNS Zone
– the receiving server can check if the email complies with the domain stated policy

To simplify the words used, often the a sender declares in their DNS, which IP addresses or range of IP addresses, messages from said domain will be sent from.
So then when the server on the receiver side checks, and can see that the domain is indeed sending from the said IP addresses, then this can be determined to be a ‘pass’
On the other hand if a message is received from the said domain from an IP address not in the SPF policy of the sender, this can be deemed an SPF ‘failure’.

The next move is with the ISP, how do they handle SPF failures?
This as we have seen with experience, is handled differently across the board, the key take away point here is, ensure your sender from address (return path)
adheres to their SPF policy and that you are confident in theory and practically speaking, that it will pass.

DKIM

DomainKeys Identified Mail (DKIM) gives the responsibility to the organisation who are putting messages into transit.
The orginisation who is the sender of the message, for example an ESP, who is either the originator or intermediary.
The senders reputation is a key point here, this is how one can decide if the source can be trusted.

There is a technical setup with DKIM, which enables the senders to sign each message digitally using encryption, cryptography.
The first version of DKIM helped to enhance Yahoo!’s DomainKeys and Cisco’s Identified Internet Mail specifications.

So to simplify, firstly the sender from address must have their DNS records setup appropriately.
A process is then run on the side of the mail server who is responsible for sending the email, each message is signed with a key.
Once the email is sent the ISP shall then check to ensure if DKIM is present and if the email is sufficiently signed.
For certain ISPs this is a deal breaker, as if to say will my email make the inbox?

The general rule of thumb is DKIM is needed for good inbox placement rates. Please bare this in mind.

Sender ID

Sender id Framework, published in 2006 is another form of authentication technology that helps to address the issue of spoofing and phishing, by verifying the domain name from the email sent. In a nutshell, Sender ID validates the origin of the e-mail address by verifying the IP address of the sender against the alleged owner of the sending domain.
How does it work?

First of all the domain owner must publish a full list of servers that it would like to authorize to be able to send emails. The verification is then automatically performed by the ISP, or the recipients mail server before accepting the email or not.

The validation check, must also validate that the emails are coming from the IPs that have been declared (SPF) therefore this adds an additional measure into place.
If the mail is coming from the authorized server and sender from an IP in the SPF record, this results in a ‘pass’ of the Sender ID.

Whilst the integration of SPF and DKIM has helped considerably with the battle against forged mails, it doesn’t stop them all together. There is still a long way to go in terms of awareness and compliancy with the protocols to ensure these numbers of fraudulent emails are kept to a minimum.

As prevention techniques become more sophisticated so do the attacks, that is life. One story to illustrate this is that it became apparent that DKIM keys of a 512 bit length were being cracked, then gmail changed their policies to cater for a longer key length 1024.

The final point in terms of authentication in this lesson, is DMARC which is a combination of the SPF and the DKIM protocols.

DMARC

DMARC stands for Domain-based Message Authentication, Reporting & Conformance.
This standard and protocol was created to address existing issues of authenticated in earlier protocols such as DKIM and SPF. The whole goal of this protocol was to standardize message authentication across the board, with ISPs such as AOL, Gmail, Hotmail and Yahoo.

It builds upon the protocols of SPF and DKIM then enables the ISP to have their own decision making abilities, based upon the results. One basic example is that if a message is received from source A, and the SPF fails and the DKIM fails, the ISP or receiving source (user side)
could make the decision to not accept emails from sources A or to put them all in the Junk folder.
Another example to help us understand, is if emails are received from source B, and pass SPF and DKIM procedures the ISP or webmail may now decide with their own rules that emails from source B can pass through into the Inbox.

Contributors to DMARC:

Summary of authentication techniques

Its important at the lowest level to understand why authentication techniques are in place, then to apply these in order to adhere to best practices.
From a deliverability perspective it is crucial to ensure your mailing domains are fully authenticated to increase the probability you will be trusted, and to increase your inbox placement rates.

This all being said, it doesn’t cover our backs for all types of ‘attacks’, particular dealing with your list hygiene.
Please look out for the next lesson in the series, Lesson 5, Spam traps and Honey traps.

[…] adding security, there’s some main techniques, which are already covered in the post: “[Beginners guide to Deliverability] Lesson 4, Authentication and Prevention” and discussed on our YouTube channel Deliverability.TV (will be published 30th of March […]