SPF, DKIM and DMARC: What are they and how do they work together?
Internet protocols for email authentication -- SPF, DKIM and DMARC -- coordinate defense against spammers, phishing and other spoofed email problems.
Email has always had security problems, and unfortunately, simply encrypting message transfers between email servers is not enough to stop spammers and other senders of unwanted email. Phishing scams, spamming and email spoofing rely on techniques that forge messages to make them appear like they originate from a legitimate sender. The key to reducing unwanted and malicious email is to use techniques to validate that an email originated from an authorized sender and that the email itself was not modified in transit.
Simple Mail Transfer Protocol (SMTP), a protocol used to transmit email messages, was first published in 1982 without any concern about email security. The expectation was that security would eventually be addressed by some other mechanism. SMTP traffic between email servers can now be encrypted and authenticated using the TLS protocol. Left out of the original protocol, however, was any consideration of how to authenticate email.As email continues to act as a primary vector for cybersecurity threats of all kinds, three main email authentication and validation protocols have been developed to fight the flood of spam, phishing and email spoofing:
- Sender Policy Framework (SPF) defines a process for finding out whether a mail server is authorized to deliver email for a sending domain in DNS.
- DomainKeys Identified Mail (DKIM) defines a process for digitally signing and authenticating email messages as coming from an email server authorized to send email for the originating domain. DKIM signatures enable email providers to authenticate on behalf of the email domain owners.
- Domain-based Message Authentication, Reporting and Conformance (DMARC) defines a process for discovering the appropriate response to receiving an email that fails to authenticate using SPF (unauthorized email server) or DKIM (digital signature fails to authenticate).
Implementing a brand-new protocol to address security in a protocol such as SMTP after it has been widely adopted is neither desirable nor practical. As a result, internet standards for email validation and authentication methods rely on existing protocols. For email authentication, that means using DNS to distribute the information needed to validate email from a given domain. This is done in part because it is simplest to rely on existing protocols and infrastructure and because it can help reduce impact on email deliverability.
The following validation protocols publish their authentication and authorization information on DNS:
- SPF uses DNS to publish the domains, subdomains and mail servers from which authorized email can be sent.
- DKIM uses DNS to advertise the public keys that can be used to authenticate email messages as having legitimately originated from the domain.
- DMARC uses DNS to advertise the policies that should be applied to email that fails to authenticate with SPF, DKIM or both.
SPF, DKIM and DMARC use requires an email server software that supports the protocols. Configuration depends on the use case, but SPF, DKIM and DMARC data is stored in DNS TXT records. Configuration may largely be completed by creating DNS records for the domain or subdomain from which email will be sent.
What is SPF?
The SPF protocol is defined in RFC 7208, Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1, published in 2014. SMTP does not restrict email servers from using any domain as the source for messages; SPF was intended to address that issue. SPF defines a process for domain owners to identify the IP addresses and domains authorized to be used as the source for emails sent from the domain.
When SPF is in use, spam can be reduced, and phishing messages from spoofed domains can be flagged and discarded based on the domain included in the sender address of the email.
An SPF record is a one-line DNS TXT record containing the IP addresses of authorized email servers and the domain or subdomain for which those servers are authorized to send email. SPF-supporting mail servers that receive messages that appear to have been sent from a domain that uses SPF must do a DNS lookup for the SPF DNS TXT record that contains the list of authorized email sources.
The following are the seven valid responses to an SPF verification query:
- Pass means the sending mail server is authorized to send mail for the domain.
- Fail means the sending mail server is not authorized to send mail for the domain. It is sometimes called hard fail to differentiate from soft fail.
- None means no SPF record was found for the domain in question.
- Neutral is returned when the domain owner has an SPF record in the DNS system that explicitly does not assert any authorized IP addresses or domains. Recipients may interpret this result either as a pass or a fail, depending on the DMARC configuration for the domain.
- Soft fail means the sending host is probably not authorized to send email for the domain. Depending on the DMARC configuration and the receiving mail server, this result may be treated either as pass or fail.
- Temporary error means the query failed due to a temporary error condition, such as a DNS timeout. After receiving a temporary error, the receiving mail server terminates its SMTP exchange with the sender, and delivery of that message is delayed.
- Permanent error means the SPF record could not be correctly processed, and the message fails to be delivered. This type of error can occur if there is more than one SPF record for the sending domain or if the SPF record has syntax errors.
It is not mandatory to implement DKIM and DMARC to make SPF function, but they work better together. For example, DMARC provides the extra functionality to guide recipients on whether to reject or accept messages that fail SPF in some way.
What is DKIM?
The DKIM protocol is defined in RFC 6376, DomainKeys Identified Mail (DKIM) Signatures, published in 2011. It defines a mechanism for the email sender to claim responsibility for messages by linking their domain to the messages using digital signatures.
DKIM message signatures are incorporated into custom message headers that conform to the internet standard for message syntax. This means any SMTP server implementation that supports DKIM automatically processes messages with DKIM signatures in the email header by attempting to authenticate the signature.
DKIM authentication enables domain owners to specify different signing keys for use by different email service providers. Those could be internal to the sending organization -- i.e., mail sent from remote branches or subsidiaries -- or they could be used by commercial email service providers to send mail on behalf of the domain owner.
In any case, the private keys of the DKIM public key pairs are held securely by whoever controls the email servers. The public keys are published in DNS; anyone who receives email from the domain can easily find them.
What is DMARC?
The DMARC protocol is defined in RFC 7489, Domain-based Message Authentication, Reporting, and Conformance (DMARC), published in 2015. With DMARC, the owner of a domain can specify the actions to be taken when a receiving server can't authenticate a message.
Email senders who use SPF and DKIM can benefit from those protocols without implementing DMARC. The recipient, however, must decide how to deal with messages that may not have originated from an authorized sender or that fail to authenticate a digital signature.
When SPF and DKIM are used with DMARC, the domain owner can solicit feedback in the form of forensic reports about individual messages that have failed to authenticate or in aggregate reports that summarize all messages that failed SPF, DKIM or both. DMARC enables the domain owner to build an email security policy that helps recipients avoid spoofed or other unauthorized mail and that helps the domain owner to flag when hackers are attacking the domain.
DMARC policies include the following:
- None means no action is necessary related to the message -- it may be delivered as legitimate. This policy gives the domain owner a method of logging information about how often the policy was invoked and is generally used when first implementing DMARC.
- Quarantine means the message may be suspicious. It can be delivered but should be routed to an appropriate folder -- e.g., the recipient's junk or spam folder.
- Reject means the message is definitely not authorized and must not be delivered.
DMARC records, stored in DNS TXT records, contain additional information about how the policies are to be applied, as well as specify what kind of reports are expected and where they should be sent.
How do SPF, DKIM and DMARC work together?
SPF underlies this three-way standard for email authentication by providing a framework for authenticating ownership of a domain. This is fundamental to getting the benefit of DMARC and DKIM because SPF records enable email systems to authenticate the domain from which a message is being sent is, indeed, a domain that is authenticated as being the owner and controller of the domain.
The SPF protocol defines the use of DNS records, as well as the exchange of SPF information between email servers, all to authenticate email servers. SPF itself doesn't specify what to do with the information it provides, namely whether a message is being sent from an authenticated domain owner -- nor can it detect whether the message is spoofed or not.
That is where DKIM and DMARC come into play.
Mail sent by servers implementing DKIM are digitally signed. Those digital signatures are authenticated using public keys connected to the sending server. These public keys are stored in DKIM records, which are added to the sending domain owner's DNS records. The DKIM signature enables domain authentication to validate that the message was legitimately sent from the specified domain.
The DMARC protocol depends on both SPF and DKIM to authenticate email. DMARC enables domain owners to specify how receiving servers should handle unauthorized or unauthenticated messages. DMARC defines another DNS record, the DMARC record, in which the public key for the sending domain is stored. With these three different records, receiving email servers can do the following:
- determine the sender is authorized to send email from the source domain using SPF;
- authenticate a message by verifying the message's digital signature, using DKIM; and
- determine the desired action for unauthenticated messages using DMARC.
While email system administrators may wish to be overly cautious about unauthenticated mail, with DMARC, they can be sure suspicious mail is treated correctly.
While DKIM, SPF and DMARC together provide a great tool for reducing the threat of spam, phishing and other email attacks, they don't protect against all threats. For example, business email compromise attacks can be difficult to defend against, but training for BEC attacks can help mitigate the risks.
