DKIM vs SPF: What's the Difference?

DKIM and SPF are both email authentication protocols, but they solve different problems. Understanding the difference helps you configure them correctly—and explains why you need both.

The Short Answer

SPF verifies that an email came from an authorized server.

DKIM verifies that an email wasn't modified in transit.

They're complementary, not competing. Most email systems require both.

Quick Comparison

How SPF Works

SPF (Sender Policy Framework) is an IP allowlist for your domain.

You publish a DNS record listing which servers can send email for your domain:

v=spf1 include:_spf.google.com include:sendgrid.net -all

This says: "Only Google and SendGrid servers can send email from our domain. Reject everything else."

When a receiving server gets an email, it:

1. Checks the envelope sender (MAIL FROM)
2. Looks up the SPF record for that domain
3. Verifies the sending IP is on the allowed list
4. Passes or fails the email

Limitation: SPF checks the envelope sender, not the visible "From" address. It also breaks when emails are forwarded because the forwarding server's IP isn't on your SPF record.

How DKIM Works

DKIM (DomainKeys Identified Mail) uses cryptographic signatures.

When you send an email, your server:

1. Creates a hash of the message content
2. Signs that hash with a private key
3. Adds the signature to the email header

Receiving servers:

1. Extract the DKIM-Signature header
2. Look up your public key via DNS
3. Verify the signature matches the message
4. Confirm the email wasn't altered

Advantage: DKIM signatures survive forwarding because they're embedded in the message itself.

Why You Need Both

Neither protocol is complete on its own:

SPF alone:

• Doesn't verify message content
• Breaks on forwarding
• Doesn't check the visible From address

DKIM alone:

• Doesn't verify the sending server is authorized
• Requires key management
• Signature can be stripped by malicious actors

Together:

• SPF confirms the server is authorized
• DKIM confirms the message is authentic
• DMARC ties them together with policy enforcement

The Forwarding Problem

This is SPF's biggest weakness.

When someone forwards your email:

1. The original message goes to their inbox
2. They forward it to another address
3. The forwarding server sends it onward
4. The receiving server checks SPF
5. The forwarding server's IP isn't in your SPF → FAIL

DKIM handles this better because the signature travels with the message. As long as the forwarder doesn't modify the signed headers or body, DKIM passes.

What Each Checks

SPF and DKIM check different "From" addresses:

SPF checks: The envelope sender (MAIL FROM / Return-Path). This is the technical sender used for bounces.

DKIM checks: Whatever domain is specified in the d= tag of the signature, which should align with the visible From header.

This is why DMARC requires "alignment"—the domains in SPF, DKIM, and the visible From header should match.

Setting Up Both

SPF Record

Add a single TXT record to your domain:

Type: TXT
Host: @
Value: v=spf1 include:_spf.google.com -all

Include all services that send email for your domain.

DKIM Record

Add a TXT record for each selector:

Type: TXT
Host: google._domainkey
Value: v=DKIM1; k=rsa; p=MIGfMA0GCS...

Your email provider gives you the specific values.

Common Mistakes

SPF:

• Too many DNS lookups (limit is 10)
• Using +all instead of -all or ~all
• Forgetting to include all sending services
• Not updating SPF when adding new email services

DKIM:

• Wrong selector name
• Truncated key (especially with 2048-bit keys)
• Not enabling DKIM signing in the email service
• Forgetting to add records for all sending services

Which Matters More?

Neither is more important—they serve different purposes.

However, if you're using Gmail, Microsoft 365, or any major email provider, both are required for good deliverability. The 2024 sender requirements from Google and Yahoo mandate both SPF and DKIM for bulk senders.

Next Steps

1. Check your SPF — Verify your SPF record includes all sending services
2. Check your DKIM — Use our DKIM tester to validate your records
3. Set up DMARC — Add a DMARC policy to tie everything together
4. Monitor all three — Get alerts when any record changes or breaks