DomainKeys Identified Mail (DKIM) and Sender Policy Framework (SPF) are two internet standards for email authentication. Both define methods for validating that a domain’s use in an email message is authorized, but they do so in different ways. In this post, we’ll discuss what they are, how they work, and how they might help you achieve better results with your email messaging.
What is SPF?
SPF (Sender Policy Framework) is what’s known as “path-based authentication,” meaning that validation of the domain in question is based on the source of the message. SPF validation of an email message focuses on the domain part of what’s known as the Return-Path in an email message. The Return-Path is analogous to the return address found on an envelope sent by physical mail; some grizzled email veterans might even refer to the Return-Path as the “envelope sender” of an email message. However, unlike the return address on an envelope, the Return-Path is almost never seen by the recipient of a message.
A domain owner wishing to participate in SPF will publish a record in the Domain Name System (DNS) for that domain. This record will use defined keywords and other text to list the servers and networks authorized to use the domain in the Return-Path of email messages, along with a keyword to essentially indicate if the list is complete or incomplete. A server receiving a message using that domain in the Return-Path can then look up the SPF record for the domain in DNS, determine based on the source of the message whether or not the usage is authorized, and if not, decide whether to reject the message immediately or subject it to further processing.
SPF validation is prone to a common failure, known throughout the industry as the “forwarding problem.” A domain owner can publish an SPF record that lists all the servers and networks that are under the domain owner’s control, but that list will never contain all the servers that a message might pass through, due to forwarding on its way to its final destination, and so a message can fail SPF validation when it gets there.
To illustrate how this might happen…
- The domain foo.com publishes an SPF record
- firstname.lastname@example.org sends an email to email@example.com using foo.com’s servers; the message passes SPF validation when it gets to bar.org.
- However, Joe has configured his mailbox to automatically forward everything to firstname.lastname@example.org.
- The message is sent to baz.net from bar.org’s servers, but the Return-Path is still email@example.com.
- The message fails SPF validation at this step because bar.org’s servers are not part of foo.com’s SPF record
To partially combat this problem, the email industry developed a second authentication technology, known as DKIM.
What is DKIM?
DKIM allows an organization to take responsibility for an email message in a way that is verifiable by the receiving site. DKIM differs from SPF in that it doesn’t rely on the path the message takes. Instead, DKIM validation is based on the content of the message.
An organization participating in DKIM will perform an operation on outbound email messages that is known as “DKIM signing” (or just “signing”) the message. DKIM signing a message involves calculating a pair of cryptographic hashes from specific parts of the message, and then inserting those hashes, information used in calculating them, and the name of the domain that calculated the hashes into an email header known as the the “DKIM-SIgnature header.” As with the Return-Path header, this header is almost never seen by the recipient of an email message.
When the message reaches its destination, the receiving site can use the information in the DKIM-Signature header to attempt to compute the same two hashes. If it succeeds, then it knows that the message has not been altered since it was signed, and so it can trust that the signing domain really did sign the message. If it fails, the receiving site will assume that the message was altered after signing and so the signing domain cannot be deemed responsible for the message in the format in which it arrived.
It is less common for a legitimate DKIM signature to fail to validate (or break) when a message takes several hops to get to its destination, although it can happen. Some mailing lists, for example, will add a footer to the message or change the subject, thus altering the content and causing the signature to break.
How Can Authentication Help You?
While both SPF and DKIM are considered best practices for email, by themselves they do not mean that your email is good or better than any message that doesn’t use them. SPF and DKIM are only meant to verify that a domain’s usage in an email message is authorized by the domain owner. If the domain owner is following all best practices for sending email, then SPF and DKIM will allow the domain owner to get credit for that good behavior in ways that unauthenticated email can’t, and that credit can lead to better results for your email programs.
Use DMARC To Get Full Benefit
As mentioned above, neither SPF or DKIM focus on information that is typically visible to the message recipient. Beyond that, there is no requirement that the domains used for SPF or DKIM validation have any relationship to the domain in the visible From header (the one that the message recipient typically sees) or with each other. Domain-Based Message Authentication, Reporting, and Conformance, or DMARC, can help with both of these and ensure that you get the deliverability your mail deserves.DMARC is another internet standard that isn’t an authentication protocol itself, but rather relies on SPF and DKIM, and it is used to validate the use of the domain in the visible From header.
To participate in DMARC, a domain owner will publish a record in DNS at a specific location. This record serves to announce that the domain owner wants use of its domain to be validated, and allows the domain owner to request how a receiver should treat messages that don’t pass DMARC validation checks. In order for a message to pass DMARC validation checks, it must pass either an SPF check or a DKIM check, AND the domain used for SPF or DKIM must have some relationship to the domain in the visible From header. The domains can either be identical, or they must at least be “in alignment” which means that they belong to the same organization. For example, “sales.foo.com” and “marketing.foo.com” are aligned, because both belong to “foo.com”, but “sales.foo.com” and “mail.esp.com” are not.
This domain alignment requirement means that when a message passes SPF or DKIM validation checks, any benefit that might accrue to the validated domain due to its use of good sending practices will go to the same domain that’s in the visible From header. Since a good sending reputation can result in inbox placement, and since inbox placement is usually required in order to drive recipient engagement, ensuring that the visible From domain earns a good reputation is the best way for you to build up brand recognition and trust with your recipients. DMARC therefore ensures that your domain gets the deliverability it deserves based on the sending practices you follow through the domain’s use in all phases of email authentication for your messages.