Email authentication is a technique used to improve email deliverability (reduce the risk of emails ending up in the recipients’ spam folders). It allows antispam filters to better verify the identity of the sender, and prevent spoofing and phishing scams.
Terms to know
MAIL FROM address
The email address to which bounce messages are delivered. This address is included in the SMTP envelope (data part of the SMTP protocol).
It is also known as RFC5321.MailFrom, Envelope sender address, Envelope from address, Return Path address, Bounce address, …
Display From address
The email address that is displayed to the end user within their email client (MUA). This address is contained in the header (meta data) of the email. The email client (MUA) doesn’t have access to the SMTP envelope (and thus can’t see the aforementioned MAIL FROM address). The Display From address can be different than the MAIL FROM address.
The MAIL FROM address is used by the SMTP. The Display From address is used by the MUA to display the address in the Form field.
It is also known as RFC5322.From, header From address, …
There are 3 main protocols allowing email authentication:
DKIM – DomainKeys Identified Mail
The sender creates an MD5 hash value of some elements of the email (e.g. the email header). The sender then uses a private key (only known by him) to encrypt that MD5 hash. The encrypted string is inserted into the mail, known as the DKIM signature. The sender stores a public key in a DNS record.
The receiver finds the public key from the DNS for that domain. The receiver then uses this public key to decrypt the DKIM signature from the email back to the original MD5 hash. The receiver generates a new MD5 hash from the elements of the email signed by DKIM, and compares it with the original MD5 hash. If they match the receiver knows that:
The sending email domain is the owner of that domain (it is mathematically almost impossible to spoof a correct DKIM signature that decrypts to the original MD5 hash using the public key).
The elements of the email signed by DKIM were not changed in transit (otherwise the original MD5 hash and the receiver’s generated MD5 hash would not match).
The shortcoming of DKIM is that it can only protect mail that has been signed, but it doesn’t provide a mechanism to prove that an unsigned message should have been signed.
SPF – Sender Policy Framework
SPF enables the sender domain to publicly state which MTA servers (IPs) may send emails on its behalf.
The receiver server checks if SPF exists in the DNS for the domain in the MAIL FROM address (also called envelope sender address). If SPF exists, the receiver checks if the IP address of the sending server matches in the list of IPs in the SPF.
The shortcoming of SPF is that it validates the originating server only looking at the domain in the MAIL FROM address, not the mail header From address. The MAIL FROM address is the email address that receiving servers use to notify the sending server of delivery problems; it is also called envelope sender, envelope from, bounce address or Return Path address. The problem with this limitation is that the From address is what recipients see in their email clients.
DMARC – Domain-based Message Authentication, Reporting & Conformance
DMARC is built on top of SPF and DKIM to address the shortcomings of these two authentication standards. DMARC allows to enforce DKIM or SPF validation, and confirm that the Display From address is authentic.
The sender adds a DMARC policy in the DNS.
looks up the DMARC policy in the DNS;
performs DKIM signature validation and/or SPF validation;
performs domain alignment checks;
applies DMARC policy.
Domain alignment consists of verifying that the From address (address displayed to the final recipient) matches with:
for SPF, the envelope sender (MAIL FROM) domain;
for DKIM, the DKIM d= domain (the signing domain included in the DKIM signature header alongside the encrypted hash).