Do you know the differences between DKIM vs. SPF? Is one better than the other, or should you always have both?
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.
Below, we’ll discuss the differences between SPF vs. DKIM, how they work, and how you can use both to achieve better results with your email messaging.
What is SPF?
SPF is known as “path-based authentication,” meaning that validation of the domain in question is based on the message’s source. 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 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 rarely 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 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.
The problem with SPF validation
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 under the domain owner’s control. Still, 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.
- sally@foo.com sends an email to joe@bar.org 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 jjones@baz.net.
- The message is sent to baz.net from bar.org’s servers, but the Return-Path is still sally@foo.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 the receiving site verifies. DKIM differs from SPF because it doesn’t rely on the message’s path. Instead, DKIM validation is based on the content of the message.
An organization participating in DKIM will perform an operation on outbound email messages 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 “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 reach 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 DKIM and SPF help your email program
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 follows 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.
That credit can lead to better results for your email programs.
Use DMARC with SPF and DKIM
As mentioned above, neither SPF nor DKIM focuses 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. 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 the 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.
Messages must pass SPF or DKIM checks
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 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.
Get complete email authentication and protection
Now that you know the differences between SPF vs. DKIM, it’s time to get complete domain protection.
DMARC isn’t easy to implement, and we’re here to help you. Our Valimail Enforce product contains everything you need to deploy DMARC to help your organization best. Contact us today.
