I recently went down a rabbit hole to understand how email works. As usual, it’s what we take most for granted that ends up being the least secure. Email is sent through a protocol called Simple Mail Transfer Protocol (SMTP), which runs on top of TCP. When an email is sent from hello@alice.com to hello@bob.com, Alice’s mail server uses SMTP to establish connection with Bob’s mail server and send the email.

In particular, the sent email consists of three parts:

Email envelope: This isn’t part of the actual email but is rather metadata that Bob’s mail server uses to handle the delivery. The email envelope consists of one or more recipient addresses (hello@bob.com) and one return address (hello@alice.com). The recipient address is self-explanatory; Bob’s mail server needs this to know who the email is for (hello@ instead of help@, for example).

On the other hand, the return address isn’t quite just the “sender” of the email. Instead, it indicates to Bob’s mail server who to contact in case the email doesn’t get delivered. For example, in the case hello@ was misspelled helo@, Bob’s mail sender would send an error email to hello@alice.com stating the message could not be delivered.

Email headers: So how do you specify a sender address? This is done in the email headers. These are additional metadata included inside the email message that serves numerous properties from spam filtering to security. SMTP is indeed Simple and doesn’t define any other metadata apart from the envelope. Therefore, all other metadata, such as the Subject header or the Content-Type, are included as headers in the email. The From header denotes the sender of an email and is what shows up on your email client, not the envelope return address described above.

Email clients parse the headers to understand the email in order to properly display it. These headers are then hidden as it is metadata and not the main email.

Email body: This is the actual email that Alice composed.

Dear Bob,

How are you doing? Great that you have an email server now!
Eve has been snooping around my house lately... Keep an eye out!

Best,
Alice

With these three parts, email works flawlessly! Just kidding. What about if Eve uses her mail server to send an email to Bob’s mail server, but includes the hello@alice.com in the From header? How can Bob make sure the email is actually from Alice?

SMTP actually doesn’t define any form of authentication at all. Again, it really is Simple. Therefore, over the years additional standards have been developed to ensure email authenticity. This is really important to limit email phishing and spam There are three main standards being used:

Sender Policy Framework (SPF): SPF is a standard that allows domain owners (i.e. Alice, who owns alice.ecom) to specify what email servers are allowed to send on their behalf. Other mail servers, like Bob’s, can then use SPF to check whether the email they received is truly from one of Alice’s trusted email servers. In particular, SPF authenticates the email envelope return address, not the From header. (Why? )

SPF relies on DNS. Alice puts an SPF record as a TXT field on her domain alice.com that could look like v=spf1 ip4:203.0.113.10 -all (SPF records get a lot more complicated but this is an example). Let’s break it down:

• v=spf1 specifies the version of SPF being used (version 1). It serves as the magic bytes for a email server to know that this TXT record is a SPF record.
• ip4:203.0.113.10 specifies that the IPv4 address 203.0.113.10 is a valid email server to send emails on alice.com’s behalf.
• -all indicates that the receiver mail server should reject/fail any other email servers. Instead of -all, Alice could specify ~all which tells the receiver mail server to “softfail” any other email servers which might mean to accept the email but mark it as spam. You can check the SPF record of any domain here!

Let’s say Alice had SPF configured to only allow her IP address 1.1.1.1. IF Eve attempted to use her own mail server at 2.2.2.2 to send an email to Bob with return address equal to hello@alice.com it would fail because:

• Bob’s email server would use DNS and retrieve the SPF record for alice.com
• The SPF record says only allow 1.1.1.1, but Eve’s server is at 2.2.2.2
• Bob’s email server would reject Eve’s spoofed email.

But wait! The From: header is still unauthenticated even when we are using SPF. So I can use my own email address as the envelope return address (evil@eve.com) but include the header From: hello@alice.com!

As stated on the Wikipedia page “To authenticate the email address which is actually visible to recipients on the “From:” line, other technologies, such as DMARC, must be used.” So what is SPF useful for? One benefit is the prevention of unsolicited error messages. Without SPF, Eve could send undeliverable emails to Bob’s mail server but use hello@alice.com as the envelope return address. Bob would then send error messages to Alice even though she had nothing to do with this. But it is clear that SPF is not enough! The next standard is DKIM.

DomainKeys Identified Mail (DKIM): DKIM is a standard allowing email senders to attach a digital signature of the email header and body, so a receiving server knows that the email is trusted. DKIM also relies on DNS. Alice publishes a TXT record that contains her public key (a DKIM record). Whenever Alice sends an email, she can sign her emails using her private key. Such a signature could look like:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=alice.com; s=mail;
 h=from:to:subject:date:mime-version:message-id;
 bh=JqjS3pGcE3cLtz1RqjUwsl5kPJds6+1HiqLwZ+0q0iQ=;
 b=KjYOw9zgZVtVhb6vW2PzEh6LUXDhGnpMVnp3xvRj0F7zemkjxR7dV
   cm6R2vQH0yGq1OcyrkF3iEdUR8W7cD0MMsb3tIZVBkMlzRex+9QGdU
   Mb3YVzI5q1cRXSt2t3WqQ+bssxzBc+2rPo4Zm8cL7mBXRboSWh8fW
   T9Uyc3z+tsq+UqQj5uO0=;

In particular, the signature includes a domain section (d=alice.com). This claims that this email is from the legitimate owners of alice.com. Receivers, like Bob’s email server, use DNS to get the correct public key from the DKIM record at alice.com and verify this claim using the signature.

Since Eve does not have Alice’s private key, Eve cannot create a valid DKIM-Signature with d=alice.com. Of course, Eve could sign it with her own key and include d=eve.com. But then Bob could see that the email claims to be From: hello@alice.com but isn’t signed by alice.com, from there knowing that something is wrong. We say that this email is not DKIM aligned (either not signed at all or signed by another domain) But what should Bob’s email server do in this case? This takes us to the final component of email authentication: DMARC.

Domain-based Message Authentication, Reporting, and Conformance (DMARC): Now we have these two methods of email authentication: SPF and DKIM. However, what should a receiving email server do if these checks don’t pass? SPF defines three levels: accept, softfail, and fail, but what does a softfail or fail actually mean? In addition, it would be great if Alice could get feedback that Eve was trying to spoof her email address - perhaps Bob could report these attempts to Alice?

DMARC ties SPF and DKIM together by allowing a domain to specify exactly what a server should do if these checks don’t pass. A DMARC record is posted as a TXT record (just like SPF and DKIM) and looks like:

v=DMARC1; p=reject; fo=1; rua=mailto:dmarc_rua@emaildefense.proofpoint.com; ruf=mailto:dmarc_ruf@emaildefense.proofpoint.com

(This is the DMARC for princeton.edu. You can check the DMARC of any domain here!)

The most important part is policy (p=reject) that specifies what Bob’s email server should do if DMARC fails. DMARC fails if both SPF alignment or DKIM alignment fails:

• SPF alignment: SPF passes (not softfail) AND the From email domain matches the envelope return address domain
• DKIM alignment: The From email domain matches a DKIM signature domain as described above.

Princeton has configured their DMARC so if DMARC fails, the receiving email server should reject that email. In addition, they specified rua and ruf which are the emails where aggregate and failure/forensic reports should be sent to.

Superb! For a real world example, if I try to spoof my own email princeton.edu address (using emkei.cz) to Gmail, I get an error message saying that the email could not be delivered due to pricneton.edu’s DMARC policy. Email authentication solved! Right?

Of course not. Poor SMTP is too Simple for our complex digital world and even with our best buddies SPF, DKIM, and DMARC, it is still possible to get things wrong. Of course, the first issue is that you actually need to both setup all these records and make sure they are correctly configured (to prevent people from spoofing your domain), in addition to ensuring that your mail servers actually enforce these rules as well (to prevent getting spoofed by other domains). Another issue is email hopping.

Enterprise email services will have numerous email servers and might bounce an email around multiple of these before it reaches its final destination. This is beneficial for the usual distributed systems reasons: load balancing, geographic distribution, etc.

How does email hopping interact with SPF, DKIM, and DMARC? If Alice’s email hops through Charlie’s email server, Charlie will still use hello@alice.com as the envelope return address. Therefore, if Alice doesn’t include Charlie’s IP on her SPF record, SPF will not pass. In a similar manner, it is possible for email hopping to mess up DKIM as well. It follows that DMARC will not work as expected either, since it relies on SPF and DKIM.

In order to deal with this issue, a standard named Authenticated Received Chain (ARC) was made. The standard was published in 2019, which is quite recent. I might go into the details of ARC in another blog post, but it allows trusted enterprise email services to relay emails to each other while not messing up SPF and DKIM as described above.

To conclude, I hope you have enjoyed getting to know email authentication security a bit better! If you have a domain, make sure you double check your SPF, DKIM, and DMARC records! Hopefully I’ll write a another blog or two on other aspects of email security including spam/malware filtering and encryption.