Proud Slytherin. Reformed red teamer. Infosec professional?
In 2018, 93% of breaches began through a phishing or pretexting campaign (Verizon DBIR 2018). All it takes is one user falling for a campaign to potentially put your company at risk. This is why it’s extremely important to make sure the fundamental technical controls are in place, so that you can work on educating your users knowing that the appropriate controls are in place.
Three key controls have been created to help combat phishing and spam — while there may be similarities in a few of these, there are enough differences it is important to implement all three — SPF, DMARC, and DKIM.
Sender Policy Framework (SPF) is simply a DNS TXT record that lists the servers that are allowed to send mail for a specified domain. This allows recipients to determine if an email really is coming from who it says it’s coming from. The recipient can then take an action based on whether the sender was authorized. Typically, recommended actions include a “soft fail” or a “hard fail” — a hard fail recommends not delivering the message at all, and a soft fail recommends delivering, but flagging it as suspicious.
Problems with SPF
DKIM, or DomainKeys Identified Mail, is a complement to SPF, and establishes a mechanism to digitally sign outgoing email from your domain. This protects against emails that could have been altered in transit between the sender and the recipient by establishing a protocol that verifies that the organization delivering the email has the right to deliver the message.
There is no requirement for users to change their behavior, unlike using something such as PGP or S/MIME, and DKIM has been adopted by most major email providers.
So what does DKIM actually do?
Recipients of an email are able to leverage DKIM to confirm the sender’s identity and determine if the message was altered at any point during transit. To do this, the sender’s mail transfer agent (MTA) will hash a subset of message headers, and signs this hash using a private key. The public key will be stored in a DNS TXT record. The receiving MTA can then look up the public key for the sending domain and validate the signature and obtain the original hash values, which are then compared to the newly created hash values. If the values match, then DKIM was valid.
When a domain is configured for DKIM, email messages from their domain will be sent with a DKIM-Signature header, containing:
To configure DKIM, check the settings in your email provider. The email provider will generate a public/private keypair, and provide the public key needed for your DNS TXT record.
Important Note: DKIM by itself is not a reliable method of authenticating the identity of the email sender, and does not prevent spoofing the visible domain in the “From” header.
So with all the issues present in SPF, namely that it relies on the receiver to take action, along comes our new savior…Domain-Based Message Authentication, Reporting, & Conformance! Yup, DMARC is much easier to say. In short, DMARC allows you the sender to indicate that the message is protected with SPF and/or DKIM, and to specify a policy with clear instructions for the receiver to follow if an email doesn’t pass SPF or DKIM (e.g. reject message, mark as spam, etc.). DMARC will also provide a report on messages that both pass and fail DMARC evaluation.
While DMARC uses SPF as one of it’s foundations, a host of other features have been added:
When configuring your SPF record, you can use one of four modifiers per mechanism:
There are 7 possible results of an SPF evaluation:
So what does a DKIM record look like? The record relies on the use of a DKIM Selector, which is used to point to a specific DKIM record in your DNS (this will be a DNS TXT record). Your public key record will then look like selector._domainkey.domain. For example, on my domain, the DKIM record looks like protonmail._domainkey.caliburnsecurity.com. The value of the record looks like:
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC/9Ep3UzhLwCDqJh75ve/rLgBq/vOxmxuwQ WAW9QlbJvIbttZwBi/TDT7j1YmjAOmCIlxJrYWmK+QSXvg0DL1tgVYb4oTjWQrZLEv8mYNGLXqO OPGHI87fkI/FfsPNSkPPrQE2m7M2IUYDPwF7pxyt4wl+uc/nVtgcu7S2VD194wIDAQAB
So let’s break down what these different fields are:
v=DKIM1 — This is the version of the DKIM record. There is only one version in use currently, and this is the first tag. Any deviation from this, and the record will be ignored entirely (while it is optional to include this tag, it is highly recommended to use it).
p=… — This is the public key used by the email provider to match the DKIM signature generated using the private key. This is generated along with the private key during the DKIM set-up process.
k=rsa — This optional tag specifies that the key type is rsa. Note that RSA is the default value, and must be supported by both the signers and the verifiers
There are a few other tags that may be useful:
n — This tag allows you to provide notes that may be useful to an individual looking at the header. This tag should be used sparingly, given the character limits of a DNS record. This should be used by administrators.
g — Granularity of the key, with a default of “*”. This value must match the local-part of the “i=” tag. The purpose of this flag is simply to constrain which signing address is allowed to use the selector record.
s — The service type to which the record applies. A default value of * is applied, which allows all service types. The only other accepted value at this time is “email”. This tag is more forward looking, and as such can be skipped over for now.
t — This provides a list of flags that can be used to modify the interpretation of the selector.
Great, so we talked a bit about the public key used for DKIM, stored in a DNS TXT record. Now how do we actually go about using this?
Here is an example of a Dkim-Signature header on a marketing email that I received recently from Atlassian:
Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=engagement.atlassian.com; h=content-type:from:mime-version:reply-to:to:subject; s=s1; bh=sNszhoSMPuyPkJZe6/yem+4zarc0ined1ljTPO1RyjU=; b=oJzun0+R2xFGe Xt8DyG7uG5m3M0Q0X/J1yNNwtFsUDXegO1vSTpZDyr0wIKnypWW8EyFAww1Gz1O0 LsVcr7GZV4EgW2yuQTnihlW8lkuE8BeEesM4JRjkemGHDkXtP2BJZGNW+kb2RRai 0hk2eY296cClV+3wmzlZ9ONQ+1eodI=
The common fields used in a signature:
v=1 — The version used for DKIM, currently only at version 1. This must be included.
a — The algorithm used to generate the signature (required). Verifiers must support both “rsa-sha1” and “rsa-sha256”. Signers should sign using “rsa-sha256” unless the system does not have enough computational resources.
c — This optional tag informs the verifier of the type of canonicalization used to prepare the message for signing. There are two names, used to indicate the algorithms used for both the header and the body. If only one name is used, that name is used for the header, and “simple” is used for the body. Options include “relaxed” or “simple”
So now that we think DMARC sounds awesome, how do we go about implementing it? Well, you guessed it, we are looking at another DNS TXT record!
Let’s take a look at my DMARC record for caliburnsecurity.com:
v=DMARC1; p=none; firstname.lastname@example.org
Let’s explore the tags available in these records (note — Only “v” and “p” are required tags; all others are optional):
Some other fields that aren’t included (which I may start adding soon):
This article is meant to be a very basic introduction to three technologies. Please see below references for more information: