DKIM vs. SPF: Understanding the difference to improve email deliverability

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.

Key takeaways -SPF and DKIM validate different parts of an email message, making them stronger when used together. -SPF is vulnerable to forwarding issues, while DKIM offers better resilience by signing message content. -DMARC brings SPF and DKIM together, aligning them with the visible From header to protect your domain and improve deliverability.

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.

Not sure what your SPF record currently looks like? Use our SPF checker to get an understanding of your SPF status:

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.

Why SPF and DKIM matter today

In early 2024, Gmail began requiring bulk senders to authenticate emails using DKIM to ensure inbox placement. Around the same time, Yahoo also mandated both SPF and DKIM for successful delivery to Yahoo-hosted mailboxes.

Now, Microsoft requires DMARC, SPF, and DKIM to be able to send email if you’re a bulk sender. They’ve started rejecting email, making SPF and DKIM even more important to your email sending.

These provider-level requirements make full email authentication not just best practice—it’s essential infrastructure.

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.

Protocol	What it validates	Strength	Limitation
SPF	Sending server IP (Return‑Path) approval	Simple to configure; helps stop spoofed return-paths	Breaks when emails are forwarded; doesn’t validate visible From header
DKIM	Message content integrity & sender’s domain via signature	Survives forwarding if content isn’t altered; cryptographically secure	Can fail if message is modified during transit (e.g., mailing list footers)
DMARC	Alignment of SPF/DKIM to visible From header, plus policy/reporting	Enforces domain alignment, boosts deliverability, offers failure reporting	More complex to deploy; requires SPF and/or DKIM already in place

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.

Step-by-step SPF and DKIM implementation guide

Implementing email authentication doesn’t have to be overwhelming. With the proper steps and the right solutions, you can bring your domain into full compliance with SPF, DKIM, and DMARC—and significantly boost your email deliverability and security in the process. The following checklist outlines a clear path to get started, monitor your progress, and confidently move toward full enforcement.

1. Publish your SPF record with only authorized outbound servers and set a strict (-all) policy.
2. Configure DKIM signing, ensure the visible From header is included and rotate key selectors over time.
3. Add a DMARC record in “none” mode, collect and analyze failure reports (RUA/RUF).
4. Adjust your SPF/DKIM based on insights, resolve misalignment issues with third-party senders promptly.
5. Increase DMARC policy rigor over time, progressing to quarantine and then reject.
6. Continuously monitor deliverability impacts, authentication performance, and policy effectiveness using dashboards or Valimail solutions.

Get complete email authentication and protection

Now that you know the differences between SPF vs. DKIM, it’s time to get complete domain protection.

With Valimail Monitor, you can analyze your SPF and DKIM configurations for free to uncover gaps, misalignments, or third-party senders using your domain without authorization.

Monitor gives you a comprehensive view of your domain’s authentication status, helping you identify risks before they become problems.

FAQs about SPF vs DKIM