Email Security – SPF, DKIM, and DMARC Demystified

What are SPF, DKIM, and DMARC? If you work with email infrastructure in any administrative or security role, you have likely heard of them and may need to work with them at some point. In short, they are three standards created to protect email domains from being spoofed by malicious actors. This article aims to provide a clear overview of what these technologies are, how they work, and how they are used effectively.

A basic understanding of Domain Name Service (DNS) is required, as all three of these standards leverage DNS records to secure an email domain against domain name spoofing; specifically using the TXT record type.

A TXT record is a DNS record that contains a plaintext string. Any type of information can therefore be contained in a TXT record, such as approved sender addresses (SPF), a public encryption key (DKIM), or policy instructions (DMARC). Only one TXT record can be specified for each domain or subdomain. E.g.: hacksanity.com or mail.hacksanity.com.

Sender Policy Framework (SPF)

SPF is the most basic and straightforward method for ensuring that an email sender is valid. Without any kind of verification, it’s easy for a miscreant to change the header of an email to falsely show that it came from a specific domain, fooling the recipient into believing it came from a valid and trusted source (this is a common tactic in spear phishing attacks). SPF mitigates this by using the TXT record for a domain to list the addresses of servers that are allowed to send mail on its behalf. Since DNS records are public, any receiving MTA (Mail Transfer Agent) that receives a message claiming to be from the domain can query the SPF record and verify that the sending server is authorized.

As an example, a TXT lookup on hacksanity.com shows the following record:

v=spf1 include:_spf.google.com ~all

This specifies SPF version 1, includes _spf.google.com as an approved sender, and soft fails all other addresses. Further details on SPF syntax can be found at: http://www.open-spf.org/SPF_Record_Syntax/

Unfortunately, the address of a sending server can also be spoofed; so SPF by itself is not enough to securely validate the authenticity of a sender. This brings us to DKIM.

DomainKeys Identified Mail (DKIM)

DKIM secures messages using public-key cryptography. The public side of a cryptographic key pair is published in a TXT record, and the private key is used to digitally sign messages before they are sent. Recipients can obtain the public key from the TXT record and use it to verify the authenticity of the signature, as well as verify that the message has not been modified in transit. As long as secure cryptographic protocols are used and the private key is not compromised, it is not possible to spoof a cryptographic signature.

A TXT lookup on google._domainkey.hacksanity.com shows the following record:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCB0yUXa/m2jnnaLluWcqYgJ6i8Fp0KfZshoHcYRBkK3VXEwkTR0UCaJC1MzzXLieh4ASFXEbvHzeS3TkFErTAFuqxwJ0EYlzIgP0pbVC0/qm8nLKUAzRYrnEi1kstYZLgu9FOd9JEvyg9NeG7Lo5olJr+v6Ok9shMEMzYCVqdmdQIDAQAB

This specifies DKIM version 1, indicates RSA as the cipher type, and the string following “p=” is the public key. Further technical details for DKIM can be found at: https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail

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

DMARC builds on the previous two protocols to provide a more advanced level of control and visibility for email activity related to a domain. Whereas SPF and DKIM can be implemented independently, DMARC requires both to already be configured for the domain. DMARC acts as a policy/management framework to inform recipients how messages from the given domain should be handled, and provides reporting to email administrators for the sending domain. A TXT record for DMARC includes:

• A primary rule specifying whether receiving systems should allow, reject, or quarantine messages that fail SPF and/or DKIM authentication for the domain (required).
• One or more email addresses to report relevant activity to (required).
• Other rules related to subdomains and how strictly message information must match SPF and DKIM signatures (optional).

An example TXT record for DMARC:

v=DMARC1; p=reject; rua=mailto:admin@hacksanity.com, mailto:dmarc@hacksanity.com; pct=100; adkim=s; aspf=s

In this example, DMARC version 1 is specified, mail that fails authentication is to be rejected, reports are to be sent to admin@hacksanity.com & dmarc@hacksanity.com, DMARC policy is to be applied to 100% of messages from the domain, and SPF & DKIM signatures are to be matched strictly. Further details on DMARC syntax can be found at: https://dmarc.org/overview/

DMARC provides much more flexibility and control for email authentication, but also adds administrative complexity. It is typically configured for larger organizations with more advanced email infrastructure and requirements.

Important Considerations in Practice

For Email Recipients

Administrators who configure SPF checking for their email infrastructure must ensure it is performed by the first MTA to receive mail from the outside internet. Many networks direct mail through multiple MTAs, such as spam filters or other security appliances, before it is received by the mail server. If SPF checking is performed by a latter MTA within a network, it will only see the address of the previous MTA – rather than the address of the sending mail server – and all messages will fail SPF verification.

DKIM checking is not dependent on visible addresses. However, some spam filters or other security-related MTAs may potentially remove or modify the digital signature, causing DKIM verification to fail. It is therefore typically best practice to perform DKIM verification on the first receiving MTA on your network as well as SPF.

For Email Senders

It is important to have a complete understanding of your email infrastructure to ensure DNS TXT records are configured appropriately. It is also important to keep said records updated with any changes that are made. If, for instance, a mail server was moved to a different address and the SPF record was not updated to reflect this, all mail sent from that server would then fail SPF verification. Recipients may notice this and attempt to notify the domain administrator. If the problem went unresolved, they would need to make a decision to either exclude the domain from SPF checking – making it vulnerable to spoofing – or simply reject all mail from the domain until the record is updated.

DNS Records

DNS records are the linchpin for SPF/DKIM/DMARC. These standards are effective because a properly managed DNS record can only be published and/or modified by the owner of the domain. It is therefore extremely important to ensure that access to the account for your domain registrar is thoroughly secured and only accessible by the appropriate people. It is equally important to ensure the registration for your domain is renewed as needed before expiring; as an expired domain name could be bought and taken over by someone else.