The Simple Mail Transfer Protocol (SMTP) does not have any intrinsic methods of proving the authenticity, integrity, and confidentiality of individual messages. As such, it’s relatively easy for third parties to spoof the source of an email, to intercept and modify authentic email, and to monitor the contents of an email. In fact, anybody may claim to have sent an email from an arbitrary source domain.

Over the decades, multiple additional protocols have been developed in order to address these three basic weaknesses of email. Some serve to prove the identities of users of the email protocol (PGP/GPG or other public key cryptography based on individuals), while others are more focused on proving the authenticity and integrity of any email from a particular domain. In this article, we will explore three protocols of the latter category.

SPF – Sender Policy Framework

The SPF was developed to let domain owners explicitly state which hosts were allowed to send email from that domain. Email receivers may then use the SPF to ascertain the authenticity of an email by way of one or more Domain Name System (DNS) lookups. However, the SPF does not provide cryptographic assertions as to the authenticity of an email. It consists merely of a set of rules to match host names or IP addresses.

A domain may specify the SPF policies within a DNS TXT record, which will tend to look something like the following if the domain owner does not host their own mail servers:

"v=spf1 include:spf.protection.outlook.com -all"

Notice, that the SPF policy entry starts with a header that specifies the SPF version (v=spf1), and is followed by a series of statements (or mechanisms) that specify the policy in left-to-right direction. The SPF recognizes eight such statements, which we’ll look into a bit further down. One of the two we see in the example above, include, merges another domain’s SPF policy with the owned domain. Its SPF policy is much longer, and itself includes to two other domains recursively. Note, that when specifying the SPF policy, the SPF proposed standard explicitly states that a maximum number of DNS lookups (usually 10) for the verifying party must be enforced. So take care not to nest too many SPF policies.

"v=spf1 ip4:207.46.101.128/26 ip4:207.46.100.0/24 ip4:207.46.163.0/24 ip4:65.55.169.0/24 ip4:157.56.110.0/23 ip4:157.55.234.0/24 ip4:213.199.154.0/24 ip4:213.199.180.0/24 include:spfa.protection.outlook.com -all"

Apart from include, SPF also recognizes the statements ip4, ip6, a, ptr, mx, exists, and all. The all statement is a catch-all statement and should only be used at the end of a policy. The statements ip4 and ip6 allow the specification of the IP addresses of hosts that are allowed to send email from the domain in question. The statements a and mx allow domain owners to specify a host name whose IP address(es) in the equivalent DNS record (A or MX) must match the source address of the email under scrutiny. The ptr statement requires a two-step DNS lookup (IP address ⇒ domain name ⇒ IP address) to result in equal IP addresses for a match. And, lastly, the exists statement requires the specified domain name entry (A record) exist for a match. The big part here is that the exist statement allows macro expansions on the side of the verifying party.

The aforementioned statements may each be prefixed with one of the qualifiers + “Pass”, - “Fail”, ~ “SoftFail”, and ? “Neutral”, which change what qualifies as a match to the following statement. The qualifier - will cause the email to be refused completely upon rule match. The qualifier ~ will recommend to the evaluating party that an email is accepted, but categorized as SPAM. The qualifier ? will issue no recommendation to the evaluating party. If no qualifier is specified, + is assumed.

In addition to mechanisms and qualifiers, modifiers may be used to either redirect (or defer) to the authority of another domain, or to specify an exp-planation for the denial of an email, which will be relayed to the recipient of the denied email. The latter modifier also allows macro expansions.

DKIM – Domain Keys Identified Mail

While the SPF does not provide cryptographic guarantees for the authenticity of email, DKIM does so by signing every legitimate outgoing email with a private key defined by the domain owner. In order to work, DKIM relies on two things: first, a DNS TXT record that will contain the public key for DKIM email validation, obtained from a DNS TXT record lookup of a name of the form {selector}._domainkey.example.com.

"v=DKIM1; k=rsa; p=[Base64-encoded public key]"

Second, every authentic email sent by the domain in question will contain the header Dkim-Signature. Its value will contain at least 8 parameters that serve to specify the DKIM protocol version, the signature algorithm, what parts of the email were included in the signature, the aforementioned selector and domain to be queried for the DKIM public key, as well as the Base64-encoded cryptographic signature.

Thus, the DKIM protocol will allow email recipients’ servers to verify the authenticity and integrity of the signed parts of an email (note, that the body is not always signed). But because the DKIM protocol cannot be enforced, it does not protect against fraudulent email, and as such, the DKIM protocol should be used at least in conjunction with the SPF.

DMARC – Domain-based Message Authentication, Reporting and Conformance

The DMARC protocol builds upon the SPF and DKIM by introducing the ability to monitor a domain for illegitimate email. In order for DMARC to work, both the SPF and DKIM must be set up. Akin to the SPF and DKIM, DMARC uses the DNS TXT record of the DNS name _dmarc.example.com to specify its policy:

"v=DMARC1;p=reject;pct=100;rua=mailto:aggrep@example.com"

Apart from the protocol and version parameter, DMARC defines ten parameters in total. The parameter p specifies the policy for the domain with one of three values none, quarantine or reject, which have similar functions to the SPF qualifiers ?, ~ and -. Specifying this parameter is necessary for DMARC to function. The parameter sp allows setting a distinct policy for subdomains. The parameters adkim and aspf allows changing how email from subdomains is treated when the DKIM or SPF policies were issued only for the organizational domain. The parameters rua and ruf specify where the DMARC reports should be sent to. The former address will receive aggregate reports, while the latter will receive detailed reports for each DMARC validation failure. The parameters pct, rf and ri allow the fine-tuning of the behavior of the DMARC policy. Note too, that the parameters p and pct can be changed to allow domain owners to gradually enforce the DMARC policy.

About the Author

Eleanore Young has completed her master degree in electrical engineering and information technology in 2014 at ETH Zurich. Her areas of focus include computer architectures, operating systems and applied research.

Links

• http://www.openspf.org/RFC_4408#macros
• https://tools.ietf.org/html/rfc6376
• https://tools.ietf.org/html/rfc7208
• https://tools.ietf.org/html/rfc7489