Securing Email Communications

A Deep Dive into SPF, DKIM, and DMARC Against Phishing and Impersonation

With phishing being the #1 way for adversaries to get an initial foothold in an organization, email security is paramount and the ability to authenticate emails is one of its linchpins. In this post, we will look at SPF, DKIM and DMARC, the 3 leading standards for email authentication.

There are two different angles to look at email authentication from:

1. How an organization should analyze external emails to protect themselves from phishing
2. How an organization should harden their own email domain to prevent attackers from impersonating it in an attempt to phish other organizations they do business with.

Both rely on SPF, DKIM and DMARC.Let’s start by getting some terminology out of the way. When it comes to the “From:” and the “To:” fields in any email, there actually are always two “From:” and two “To:” fields:

1. The envelope “From:” and “To:” fields
2. The header “From:” and “To:” fields

The first set of fields are the ones used in the SMTP transaction, which is the protocol used to deliver emails. So it’s all about email routing and delivery, hence the term envelope that draws the analogy with a mail carrier and how one would write someone’s address on an envelope, as well as their address at the back so that the mail could be returned if it can’t be delivered. The second set of fields are the ones used by the email client (e.g. Outlook, GMail, etc.) to show who the email is addressed to, and who it’s coming from. A useful analogy would be the letter within an envelope, and how it could start with “Dear James” (recipient) and be signed by “Sincerely, Paul” (sender). We will see in a second why it’s important to understand that difference.

SPF

The first – and oldest – email authentication standard we are going to discuss is SPF.SPF’s goal is to authenticate emails at the transaction (SMTP) level, meaning it only focuses on the envelope “From:” and “To:” fields, that is to say it does not try to authenticate the “From:” and “To:” fields the recipient sees, in their email client (aka the header “From:” and “To:”).So, let’s say an organization is using Hubspot for their marketing campaigns: obviously those emails do not come from the @hubspot.com domain, but from @theorganization.com domain, and there’s a need for the organization to tell the world they have authorized Hubspot to send emails on their behalf, meaning Hubspot is not impersonating their domain and it’s legitimate for them to send emails that appear to be directly coming from that organization.

SPF is the way to do that. Without getting too much into the weeds, SPF relies on the organization publishing a DNS record on their authoritative DNS servers that tells everyone which organizations (by way of listing their email servers, to give a simplified overview) have been authorized to send emails on their behalf.

The key thing to understand is that, again, that authentication is at the “envelope”/SMTP protocol level, i.e. the intent here is to allow the email servers of a recipient organization (the one targeted by the marketing emails) to gain some assurance – since it is Hubspot’s email servers that initiate a connection to them to deliver those emails – that Hubspot has been authorized by the organization to send emails on their behalf, aka inject mail in the post system, to keep drawing analogies. It gives no guarantee whatsoever about the actual content and sender of the email, the only thing it does is that it indicates Hubspot is allowed to bulk send emails on behalf of the organization. For example, the actual email could pretend to be coming from potus@whitehouse.gov, and SPF wouldn’t care / raise any red flag. That SPF DNS record allows the organization to also publish a policy as to how they would like recipient organization to react if they receive emails from some organization, IP address, etc. that aren’t explicitly authorized by their SPF record (reject, maybe reject or “no guidance”); selecting anything but reject doesn’t make sense unless an organization doesn’t have a good handle on their mail flows (who sends emails for them, etc.), or they are in the process of implementing SPF (i.e. it’s being phased in slowly).

So, SPF was the first attempt by the Internet community to authenticate emails, but as you can see, it’s far from perfect… The main reason for that, to make sure to drive the point home, is that it does not validate or even look at the fields that really matter to the end user that could potentially get phished: all that user sees, through their email client interface, are the header “From:” and “To:” fields. There are other issues, such as how forum email distribution lists break SPF when they dispatch the sender’s email to the entire group, how the DNS lookup for the SPF record cannot elicit more than a total of 10 DNS lookups, etc.

DKIM

DKIM takes a different approach that relies on digitally signing emails. Indeed, DKIM allows an organization or one of its authorized partners to send emails and affix a digital signature to them to attest to the fact those emails either originated from the organization or from one of its authorized partners, on its behalf.While S/MIME and PGP, two email encryption and signing technologies, rely on a PKI and a web of trust, respectively, both of which require a significant amount of effort to implement and maintain, DKIM adopts a very simple approach of publishing public keys (aka certificates, to simplify) through DNS records.

In a nutshell, here’s how the DKIM protocol works:
The sending organization’s email servers compute a hash on the body of the email, as well as select email headers of importance (“From:”“,”To:““,”Subject:““,”Date:““, etc.)

The sending organization’s email servers encrypt that hash with a private key to compute the digital signature for that email. -The sending organization’s email servers add a”DKIM-Signature:” header to the email that indicates, among other things: - What email headers are covered by the signature (the body is always covered) - What the signature is - In which DNS record (selector field in the “DKIM-Signature” header) the matching public key can be found, in order to allow the recipient’s email servers to verify the email signature - The recipient organization’s email servers will then look at the “DKIM-Signature:” header and: - Fetch the public key via DNS - Use it to decrypt the signature, yielding the hash that the sending organization attested to as the valid hash, through the signing process - Compute the email hash, following the same process the sending organization followed - Compare both hashes. If the hashes match, then the email has been authenticated, if not then either the email has been spoofed, or some of its content (body or email headers) on which the signature was computed was modified in transit, either for nefarious purposes or not (there could be several reasons as to why something is modified: an “[External] flag” could have been added to the “Subject:” header, a warning could have been added to the beginning of the email to indicate to the recipient that the email was received from outside the organization in order to elicit caution, etc.)Contrasting DKIM with SPF, DKIM is definitely a drastic improvement over SPF: - We have an email signature to autheticate the email, vs. the fact it came from an authorized IP for SPF (e.g. we could have Microsoft 365’s Exchange Online IPs as authorized IPs, but so many organizations use it, so can hackers, that it doesn’t really mean anything) - The integrity of the email content and some choice headers are also attested to by the signatureOn the flip side, when it comes to protecting the email recipient from phishing, we are still lacking sufficient protection. Indeed, there’s nothing stopping a hacker.com domain to sign phishing emails to their own domain, pretty much telling the receiving organizations nothing more than the fact those emails indeed came from the hacker’s organization/domain, but still using a header “From:” field of potus@whitehouse.gov.So it’s clear a better solution is needed…

DMARC

Enter DMARC! DMARC takes care of the problem in a very simple yet elegant way: for an email to be DMARC compliant, two things are required: 1. The email needs to be attributed to a sending organization, either through SPF and/or through DKIM authentication 2. The domain the email is attributed to through SPF and/or DKIM must match the domain in the “To:” header of the email to ensure said attribution/authentication is actually relevant to the end-user recipient of the email, allowing them to trust that the email indeed came from the organization/domain their email client shows it came fromAs with SPF and DKIM, DNS plays a key role for DMARC as well. Indeed, the sending organization has to publish a record on their domain’s DNS to indicate that DMARC is in use on that domain, as well as publish a policy as to how they would suggest a receiving organization treat emails appearing to be coming from that domain but not passing the DMARC check: none (no guidance provided as to how to handle those emails), quarantine (emails should be delivered but “placed in quarantine”, which could mean delivered to the hosted quarantine, to the spam folder, flagged as suspicious, etc. depending on the capablities of the email system), reject (the emails should be rejected).One last thing to mention is that even though DMARC allows the end-user recipient to know the email did indeed come from the domain displayed in their email client, it says nothing about whether it actually came from the user/mailbox the “From:” header says it came from.

So, what should a company do?

Nowadays, every company should:

1. Implement SPF, DKIM and DMARC, to ensure other organizations (customers, partners, etc.) cannot be phished by emails pretending to be coming from them

2. Ensure their email servers are adequately configured to validate the SPF, DKIM and DMARC status of each received email, and have adequate policies that leverage that information and handle those emails according to the risk level inferred from it. Coverden has a deep understanding of those protocols and stands ready to help organizations implement them.

Beyond DMARC

It’s worth briefly mentioning a couple of emerging protocols: BIMI and ARC.BIMI leverages a passing DMARC check on a received email and displays a company’s official logo (the sending domain’s) in the recipient’s email client if that organization publishes a DNS record with that information.

That achieves two things:
‍
1. It gives a visual indication/cue to the recipient end-user that the email can be trusted

2. It affords a sending organization the dual benefit of advertising exemplary email hygiene practices, as well as the branding/marketing benefit of having their official logo appear on the email clients of the organizations they conduct business with.

ARC is a protocol that allows the results of authentication checks along the path of mail transport agents to be recorded and attested to, via digital signatures. It’s helpful if for example organization A sends emails to organization C, and those email transit through some organization B (ISP, email routing, etc.): if organization B is able to validate SPF, DKIM and DMARC, but by the nature of the way it handles those emails and forwards them along the way to organization C it ends up modifying the emails in such a way that those checks would fail when performed by organization C. ARC allows organization B to record that the SPF, DKIM and DMARC checks all passed, and attest to that through digital signature; that gives the ability to organization C, based on the trust relationship it may have with organization B to elect to consider those emails as valid from a SPF, DKIM and DMARC standpoint, even if they failed the checks they performed, due to the aforementioned changes.