Email Authentication: SPF, DKIM, DMARC (Oh my?)

15 September 2023 by mikevarian Security

Email is open protocol without any strict governing body in control of it, which makes them ubiquitous but also inherently untrustworthy. Much like anyone can send a letter via the US Mail that has someone else’s return address label on it, anyone can send email with someone else’s email address on it in the “From” field, known as spoofing or impersonation.

SPF, DKIM, and DMARC are email authentication mechanisms which aim to help receiving email servers discern which emails legitimately came from the organization that they claim to be from, and which are impersonations and not authentic.

In the following explanations, we’ll be referring to sending organizations and senders, and receiving organizations and recipients. If [email protected] sends an email to [email protected]:

Each of these three email authentication mechanisms are optional, some organizations implement all of them, some do some, some implement none. This makes judging incoming email that much more complicated as emails could be legitimate without any of these factors, and also email that has all 3 of these factors passing could still be illegitimate (most commonly in the case of a compromised account).

Each serve as a positive indicator of a message’s authenticity, but none are the end-all be-all. As a sending organization, it is ideal to set these up as it helps protect the organizations that you interact with from falling victim to those who might spoof and impersonate your domain - which is to the benefit of both of you.

Sender Policy Framework (SPF)

Quick Explanation

Imagine a scenario where you are trying to get access to a private invite-only event. At the door, there is a bouncer who is asking everyone their names and checking to make sure they are on the invite list.

In this analogy, you are the email, trying to get into the inbox of the recipient. SPF is like the invite list. The server that you sent your email from must be on this invite list in order to get into the event, and if it’s not then it fails SPF.

The invite list is actually a list of allowed email servers that are configured and published by your organization, the sender, to publicly list all of the servers which should be legitimately sending email under the name of your organization.

In other words, the bouncer is really just trying to make sure that when you say you came from example.com, you really did come from example.com. So they call up Example.com and ask who is allowed to be sending people to the event. If that email server is on the list, you’re in, if it’s not, you’re out.

More Technical Explanation

Sender Policy Framework (SPF) is a method where the sending organization publishes a list of which email servers are allowed to legitimately send email from their domain name @example.com. This is a list of email server hostnames and IP addresses published in a special DNS record that receiving email servers know to look for.

When an email arrives from [email protected] to @acme.net’s email server, the Acme email server will look up the SPF record for @example.com and compare that to the actual server that sent the email.

If the server that sent the message from [email protected] to [email protected] is included in the SPF record, the message is determined to have passed SPF.

If the server that send the message is not listed in the SPF record, the message is determined to have failed SPF.

A failure of SPF is meant to indicate that the message is a spoof and that is not sent by the actual sending organization it claims to have been sent from. However, there can be more mundane reasons that SPF fails even on legitimate emails:

  • SPF could be misconfigured or out of date, which means the sending email server could be the legitimate server, but the SPF record needs to be updated and corrected to properly reflect it.

  • It could be that a third party system in addition to the primary email server is being used to send legitimate email, but that server is not listed in the SPF record. Most commonly, this happens with email marketing platforms or third party billing platforms that get set up by different departments who don’t realize the importance of coordinating with IT before configuring those systems to send email from the company domain.

When SPF fails, most email systems will automatically mark the message as junk/spam, if not quarantine them altogether. When SPF passes, it improves deliverability and is a helpful indicator to the receiving email server that the message is authentic.

Domain Keys Identified Mail (DKIM)

Quick Explanation

Using the same invite-only event with a bouncer analogy, DKIM is a more robust form of a guest list that also has the bouncer check your ID before you get in to confirm that you really are who you say you are, and also confirms that the ID itself is authentic.

DKIM authenticates that your email legitimately came from the sending organization, and also that your email was not altered or modified in transit. In other words, the received email is the exact same email that you originally sent. It does this by leveraging special cryptography which allows for any recipient to validate the details of the message.

More Technical Explanation

DKIM is a robust method for the receiver to verify that an email was indeed authorized by the sending organization and that it wasn’t modified or altered in transit. When DKIM is enabled by the sending organization, all messages sent through legitimate email servers are cryptographically signed with a unique signature that is embedded in hidden technical details alongside the visible email message.

DKIM leverages public key cryptography. With this method, there is a secret private key and a non-secret public key. The public key can be used by anyone encrypt information that can only be decrypted and read by the organization that has the private key - and the opposite is also true. Anyone with the public key can decrypt information that was encrypted by the private key. This allows for two organizations who have never previously interacted before to exchange secure and trustworthy one-way communications by using public information.

Another way to put it is the sending organization has a machine that can encrypt messages, and they provide any receiving organization with a free machine to decrypt those messages. If the decryption machine that they say should be used doesn’t work, then the receiving organization knows the message either wasn’t really encrypted with the true encryption machine, or it has been tampered with or damaged in transit.

With DKIM enabled, when the sender clicks send on an email, their email server calculates a hash of the message contents. A hash is another application of cryptography that generates an effectively unique signature for the message, like a fingerprint. This hash is added into the hidden technical details of the message, and additionally the hash is encrypted into a digital signature using the sending organization’s private key.

When the receiving organization gets a message and sees that it has been signed, it looks up the sending organization’s public key using a special DNS record published by the sender. That public key is used to validate the digital signature and check if it matches the unencrypted hash that was included in the message. If they match, then DKIM has successfully validated and we can confirm 1) The message really came from the sending organization and 2) The received message is the exact complete message that the sender sent, without any unauthorized modifications.

Domain-based Message Authentication, Reporting, and Conformance (DMARC)

Quick Explanation

DMARC builds on DKIM and SPF to allow the sending organization to how they would like receiving organizations to handle mail sent from their organization, particularly if it fails DKIM or SPF.

Say the bouncer has someone try to attend the event who either isn’t on the list or presents a fake ID, the question now is what do they do with that person? DMARC is a set of instructions that the sending organization publishes that tells that bouncer what to do. Some examples of what that DMARC policy could say to do if the bounce encounters someone who isn’t on the list or doesn’t have a valid ID:

  • Don’t let them in, send them away, and/or put them in jail.

  • Don’t make a big deal out of it, just ignore it and let them in (if the sending organization is in the process of phasing in DMARC, this is away for them to do so in an evaluation mode without breaking things).

  • Let 50% of people in, and 50% of them send them away. (This is another method for easing in the implementation of DMARC in a less potentially impactful way)

  • Send a list of all the people who shouldn’t get in back to us, the sending organization, once per day so we know about it.

More Technical Explanation

DMARC allows the sending organization to state a series of preferences:

  • Alignment: How strict does the sending domain name need to match the organization name? I.e. must all messages be from @example.com, or could they also be from @billing.example.com using the name @example.com? (This is a technical detail related to sending infrastructure.)

  • Action or Policy: What to do if something fails DMARC: ignore/do nothing, quarantine the message, or reject the message.

  • Percentage of messages to apply this policy to: A fully implemented DMARC policy would be 100%, but a phased implementation may start at 0%, then move to 10%, and so on to ease into enforcement and catch issues at a smaller scale.

  • Reports: Should the receiving email server report any failures to the sending organization, and if so where should it send them? Usually this is an email address at the sending organization that collects these specially formatted reports so it can analyze the failures, and if they are really illegitimate or if there are legitimate systems that need to be reconfigured.

Related posts

  • No related post found