SPF checks the server that sent your mail. DKIM signs the message itself. They answer two different questions, which is exactly why receivers like Gmail, Yahoo and Microsoft now expect both on any domain sending real volume. If you only have one, your mail is one forwarded message or one alignment mismatch away from the spam folder.
Here is the short version: SPF (Sender Policy Framework, RFC 7208) publishes a list of IP addresses allowed to send for your domain, and the receiver checks whether the connecting server is on that list. DKIM (DomainKeys Identified Mail, RFC 6376) attaches a cryptographic signature to each message so the receiver can confirm the content and the sending domain have not been tampered with. You need both because SPF breaks when mail is forwarded and DKIM does not, and because the big mailbox providers now treat both as a baseline requirement.
Reads public DNS only. Nothing is stored unless you save the domain to an account.
The one-line mental model
SPF is a guest list at the door. When a server connects to deliver mail claiming to be from your domain, the receiver looks up your SPF record and asks a simple question: is this IP address allowed to send for this domain? If yes, SPF passes. If no, SPF fails. It says nothing about the content of the message.
DKIM is a tamper-proof seal on the envelope. Your sending server signs selected headers and the body with a private key, and publishes the matching public key in DNS. The receiver recomputes the signature and confirms two things: the message was not altered in transit, and it was genuinely authorized by the domain in the DKIM signature. DKIM cares about the message, not the server that carried it.
That single difference (server versus message) drives everything else, including why you cannot safely drop either one.
SPF vs DKIM side by side
| Property | SPF | DKIM |
|---|---|---|
| What it checks | The sending server's IP address | A cryptographic signature on the message |
| Where it lives | A TXT record on your domain | A public key in DNS, signature in the mail header |
| RFC | 7208 | 6376 |
| Survives forwarding | No, the forwarding server's IP is not on your list | Yes, the signature travels with the message |
| Protects message content | No | Yes, the body hash detects tampering |
| Main failure mode | Too many DNS lookups, wrong IPs, +all | Broken signature, wrong selector, body modified |
| Identity it validates | The MAIL FROM (return-path) domain | The d= domain in the DKIM signature |
The last row matters more than it looks. SPF authenticates the hidden return-path address, not the From: address your recipient sees. DKIM authenticates the d= domain in its signature. Neither one, on its own, guarantees the visible From: is legitimate. That gap is what DMARC closes by requiring alignment, which is why these three are usually discussed together in SPF, DKIM and DMARC explained.
Why forwarding breaks SPF but not DKIM
This is the single best reason to run both. Say someone on your team forwards a message, or a mailing list relays it, or a user set up a forward from an old address to a new one. The message now leaves a server that is not in your SPF record. SPF checks the connecting IP, sees a server you never authorized, and fails. Nothing was wrong with your mail. The forwarding hop simply changed the sending server.
DKIM does not care. The signature was calculated before the message left your infrastructure, and it travels inside the message headers. As long as the forwarder does not rewrite the signed headers or mangle the body, DKIM still validates at the final destination. So on a forwarded message you typically get SPF fail and DKIM pass, and DMARC only needs one of the two to pass with alignment for the message to survive. A domain with DKIM alone would lose direct-to-mailbox SPF alignment; a domain with SPF alone loses everything the moment a message is forwarded. The deeper mechanics are covered in why email forwarding breaks SPF.
Do you need both? Yes, and here is why
Three reasons make this non-negotiable in 2026.
Redundancy across delivery paths
Direct mail from your own servers usually passes SPF cleanly. Forwarded and relayed mail usually only passes DKIM. Running both means at least one authentication method survives on almost every path your mail can take. Drop one and you create a category of legitimate mail that quietly fails.
DMARC needs something to align with
DMARC (RFC 7489) does not add a new check, it enforces the ones you already have. It passes when SPF or DKIM passes and the passing identity aligns with the visible From: domain. If only SPF is set up and a message gets forwarded, DMARC has nothing left to pass on, and your policy sends the message to quarantine or reject. Two aligned mechanisms give DMARC two chances to pass.
Gmail, Yahoo and Microsoft now require both
Since February 2024, Google and Yahoo require bulk senders to authenticate with both SPF and DKIM and to publish a DMARC record. Microsoft has rolled out equivalent enforcement for high-volume senders to Outlook and Hotmail. "Bulk" starts around 5,000 messages a day to a single provider, but the safe assumption is that both are expected of any real sender. The full checklist is in the Google and Yahoo sender requirements guide.
What each record looks like
An SPF record is a single TXT record on your root domain. It should end in -all (hard fail) or ~all (soft fail), never +all:
v=spf1 include:_spf.google.com include:sendgrid.net -all
A DKIM record is a TXT record at a selector-specific subdomain. The selector (here s1) lets you run and rotate multiple keys:
s1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB..."
Set SPF up carefully to stay under the 10 DNS-lookup limit, walked through in how to set up SPF. Then publish DKIM and confirm the selector matches what your sending platform signs with, covered in how to set up DKIM. Always confirm the exact record values in your sending provider's own console, since selectors and include hosts differ per platform.
Which one is my domain missing?
The fastest way to answer is to look at a live result rather than guess. Run your domain through the scanner above and it will show, in one view, whether SPF resolves within the lookup limit, whether a valid DKIM key is published, and whether both align under your DMARC policy. Most domains that land in spam are missing DKIM entirely or have an SPF record that silently exceeds ten lookups and returns a permanent error. Seeing which of the two is broken tells you exactly where to spend the next ten minutes.
Frequently asked questions
Is DKIM more important than SPF?
Neither replaces the other. DKIM is more resilient because it survives forwarding, but SPF is still the check that validates your direct sending servers and is explicitly required by Gmail, Yahoo and Microsoft. Run both, then add DMARC so a visible From: domain gets protected.
Can I use just SPF or just DKIM?
Technically the protocols work independently, but you should not rely on one alone. SPF-only mail fails the moment it is forwarded, and DKIM-only mail loses direct SPF alignment. The major mailbox providers now expect both for bulk sending, so a single method risks deliverability.
Does SPF or DKIM stop spoofing on its own?
No. SPF validates the return-path and DKIM validates the d= domain, but neither guarantees the From: address your recipient sees. Only DMARC ties a passing SPF or DKIM result to the visible From:, which is what actually blocks lookalike spoofing.
What if SPF passes but DKIM fails, or the reverse?
That is normal and often fine. DMARC only needs one of the two to pass with alignment. A common pattern is DKIM passing while SPF fails on forwarded mail. If both fail, or the passing one is not aligned, DMARC enforcement kicks in and the message can be quarantined or rejected.