Introduction

Many SPF failures aren’t caused by a misconfigured record, they happen because the email was forwarded.

An IT admin sets up SPF correctly, verifies it passes, and considers the job done, then a user forwards a message through a third-party relay. The receiving server sees an IP address that isn’t on the authorized list, the check fails, the admin reviews the record and it looks fine. The problem isn’t the record, but how SPF works.

SPF alone isn’t sufficient for email authentication, and SPF and DKIM don’t serve the same purpose. Each protocol protects a different layer of the email delivery process. Remove either one and you leave gaps that forwarding infrastructure and attackers can both exploit, in different ways, for different reasons.

In this blog, you’ll learn what separates SPF from DKIM, why forwarding breaks one but not the other, and why both are required for DMARC to work.

What Is SPF and How Does It Work?

SPF (Sender Policy Framework) is an email authentication protocol that lets a domain owner specify which mail servers are authorized to send email on the domain’s behalf.

The domain publishes an SPF record in its DNS as a TXT entry listing the approved IP addresses and servers. When a receiving mail server gets a message, it checks the sender’s domain against this published record to confirm the sending server is permitted. 

Based on the result, the receiver decides whether to accept, flag, or reject the message. SPF exists to prevent spammers and attackers from forging the sender address, reducing email spoofing and phishing. It works alongside DKIM and DMARC to verify message legitimacy. 

What SPF Checks

SPF checks whether the server sending a message is allowed to send mail for the domain it claims to be from. This happens the moment a receiving server accepts the incoming connection, before it even processes the message body.

However, SPF doesn’t check the From address your recipients actually see. It only checks the envelope sender, also called the Return-Path or MAIL FROM, which is the address used behind the scenes during the SMTP transaction. 

So an attacker can pass SPF on the envelope domain and still show a forged From address in the inbox. DMARC helps close this gap by tying the SPF result back to the visible From domain.

The receiving server takes two inputs: 

1. The sending IP address
2. The envelope sender’s domain

It then looks up that domain’s SPF record in DNS. It works through the record’s mechanisms in order, things like ip4, ip6, a, mx, and include. If the sending IP matches an authorized source, SPF passes. If it runs to the closing all mechanism without a match, the outcome depends on how you’ve configured that mechanism.

SPF doesn’t return a simple yes or no. It returns one of the following results:

• Pass: The server is authorized.
• Fail (-all): Not authorized. You want this mail rejected.
• SoftFail (~all): Probably not authorized. Accept it, but mark it suspicious.
• Neutral (?all): You’re making no assertion either way.
• None: No SPF record exists for the domain.
• PermError / TempError: The record is broken, or a DNS issue blocked the lookup.

The receiving server treats this result as one signal alongside DKIM and DMARC to determine the legitimacy of the email before your message is delivered, flagged, or rejected. 

What Is DKIM and How Does It Work?

DKIM (DomainKeys Identified Mail) is an email authentication protocol that attaches a cryptographic signature to every message a domain sends. The sending server signs the message with a private key and adds the signature to the email’s header. The domain publishes the matching public key in its DNS as a TXT record. 

When a receiving server gets the message, it retrieves that public key and verifies the signature. A valid signature confirms two things: 

1. The message genuinely came from the stated domain
2. Its content was not altered in transit. 

DKIM exists to prevent tampering and sender forgery, and it works alongside SPF and DMARC to verify message legitimacy. 

What DKIM Signs

DKIM signs two parts of every message: a selected set of header fields and the message body. It does not sign the envelope, the connecting IP, or anything outside those two areas. That’s the dividing line between the two protocols: SPF checks the envelope and the sending server, while DKIM signs the message itself.

The signature isn’t applied to the raw text. The sending server hashes the body and the chosen headers, then encrypts that hash with its private key. The result goes into the DKIM-Signature header, which the server adds to the message. Inside that header, a few tags tell the receiver exactly what was signed:

• h= lists the header fields included in the signature, such as From, To, Subject, and Date.
• bh= holds the hash of the message body.
• b= holds the signature itself, the encrypted hash of the signed headers.
• c= sets the canonicalization, which decides how strictly whitespace and formatting have to match.

The From header is always signed. DKIM requires it, because the point is to bind the signature to the domain the recipient actually sees.

Anything not listed in h= is not protected. If a header isn’t in that list, it can be changed in transit without breaking the signature. The body is covered in full unless the optional l= tag limits signing to the first portion of it, which is why l= is generally discouraged. Any content added after the signed length would slip through unsigned.

When a receiving server checks DKIM, it recomputes the body hash and the header hash, decrypts b= with your published public key, and compares the two. If both match, the signature is valid and the signed parts of the message arrived unaltered.

SPF Vs DKIM

SPF and DKIM solve two different problems. SPF authorizes which servers are allowed to send mail for your domain, while DKIM proves a message wasn’t altered and genuinely came from your domain, using a cryptographic signature. Here’s a quick overview of how SPF and DKIM differ.

Neither protocol knows what the other knows.

SPF can confirm a message came from an authorized server, but once that message left the server, SPF has no visibility into what happened to it. 

In the same way, DKIM can confirm the content arrived intact and that the signing domain controlled the private key, but it says nothing about whether that server had permission to send in the first place.

Here’s what it means when a receiving server evaluates both results:

DMARC reads both results and applies your published policy based on alignment with the From domain. That’s why the two protocols are built to complement each other, not compete.

Why SPF Fails on Forwarding but DKIM Doesn’t?

The SPF Forwarding Problem

SPF breaks when an email is forwarded. It’s one of the most common reasons a legitimate message fails SPF, and it comes directly from how the protocol works.

SPF checks the connecting server’s IP against the SPF record of the envelope sender’s domain. Forwarding breaks that match. When a server forwards a message, three things happen:

1. The forwarding server becomes the new connecting IP.
2. The envelope sender still points to the original sender’s domain.
3. The original domain’s SPF record doesn’t list the forwarding server, so the check returns Fail.

For example, a message from your domain passes SPF on the first hop. The recipient’s server then forwards it to a second address, like an alumni account or a mailing list. At that second destination, the connecting IP is now the forwarding server, but the Return-Path still shows your domain. Your SPF record never authorized that server, so SPF fails even though the message is genuine.

This shows up most often with:

• Mailing lists
• Account-level auto-forwarding rules in Gmail or Outlook
• Alumni or role-based forwarding addresses
• Spam filters and gateways that relay mail onward

Two things keep forwarded mail from being rejected:

1. SRS (Sender Rewriting Scheme): The forwarding server rewrites the Return-Path to its own domain before relaying the message. SPF then checks against the forwarder’s domain, which does authorize that server, so the check passes. Most reputable forwarding services apply SRS automatically.
2. DKIM and DMARC: A DKIM signature survives forwarding as long as the forwarder doesn’t alter the signed content. So even when SPF fails on a forwarded message, DKIM can still pass, and DMARC only needs one of the two to align. This is the main reason you shouldn’t rely on SPF alone.

Why DKIM Survives Forwarding

DKIM survives forwarding because it signs the message, not the path the message travels. The signature lives inside the DKIM-Signature header, so it moves with the email through every hop. No matter how many servers relay the message, the signature is still there when it reaches the final destination.

Verification doesn’t depend on the connecting server either. The receiver fetches the signing domain’s public key from that domain’s DNS and uses it to check the signature. The IP that delivered the message is irrelevant. This is the opposite of SPF, which fails on forwarding precisely because it checks the connecting IP, and forwarding changes that IP.

As long as the forwarder relays the message without changing the signed content, the body hash and header hash still match, and DKIM passes.

DKIM survives plain forwarding, but it isn’t immune to everything. The signature breaks when an intermediary modifies signed content. The most common offenders are mailing lists, which often:

• Append a footer or unsubscribe link to the body
• Add a tag like [list-name] to the subject line
• Rewrite or insert headers that fall inside the signature

Any of these changes the hash, and the signature no longer validates. ARC (Authenticated Received Chain) was created for exactly this case, preserving the original authentication results as a message passes through intermediaries that modify it.

This is why DKIM matters for forwarded mail under DMARC. DMARC passes when either SPF or DKIM passes and aligns with the From domain. On forwarded messages SPF usually fails, so DKIM is what holds DMARC alignment together. The signing domain stays the same through forwarding, so alignment survives with it. Relying on SPF alone and forwarded mail from your domain can fail DMARC and land in spam.

How Do SPF, DKIM, and DMARC Work Together?

SPF and DKIM each solve a different problem, but neither one enforces anything on its own. DMARC connects their results to an action and ties both checks back to the domain your recipients actually see.

Here’s what happens when a receiving server evaluates an incoming message:

1. SPF runs first: The server reads the envelope sender, the MAIL FROM address exchanged during the SMTP session, not the From header the recipient sees, and checks the sending IP against your SPF record. If the IP is authorized, SPF passes. If not, it fails.
2. DKIM runs next: The server reads the DKIM-Signature header, looks up your public key in DNS using the selector and domain tags, and verifies the cryptographic signature against the message content. A valid signature confirms the message came from a domain controlling the private key and wasn’t altered in transit.
3. DMARC evaluates last: It retrieves your policy record and checks alignment:
   1. Does the domain that passed SPF match your From domain? 
   2. Does the d= tag in the DKIM signature match your From domain? 

If either aligns, DMARC passes. Your published policy then determines what happens to the message.

What alignment means in practice

SPF can pass on any domain listed in the envelope sender. DKIM can pass on any domain with a valid signing key. Neither check on its own confirms the From header, the field showing [email protected] in the recipient’s inbox, is legitimate. DMARC adds that verification by comparing the authenticated domain against the From domain.

Alignment runs in two modes:

1. In relaxed mode, the default, an organizational domain match is enough, where mail.yourcompany.com aligns with yourcompany.com. 
2. In strict mode, the domains must match exactly. Most organizations use relaxed alignment because strict mode creates delivery problems for subdomains unless every sending source is configured precisely.

The outcome on legitimate vs. spoofed mail

For a properly configured legitimate message:

• Sending IP matches your SPF record → SPF passes
• DKIM signature validates, d= matches your From domain → DKIM passes
• Both results align with your From domain → DMARC passes
• Your p=reject policy → message is delivered

For a spoofed message sent from an unauthorized server with no valid signing key:

• Unauthorized IP → SPF fails
• No valid signature → DKIM fails
• Neither result aligns with your From domain → DMARC fails
• Your p=reject policy → message is rejected before it reaches any inbox

This is why SPF and DKIM together are more effective under DMARC than either one alone. DMARC can pass on either result aligning, so when SPF fails on forwarded mail, DKIM alignment keeps DMARC passing on legitimate messages. When both fail on spoofed mail, DMARC acts on your policy.

Once your domain reaches p=quarantine or p=reject with both SPF and DKIM passing and aligned, you’ve also met the enforcement prerequisite for BIMI, the standard that displays your verified brand logo in supporting inboxes like Gmail and Apple Mail.

Do You Need Both SPF and DKIM?

Yes, you need both SPF and DKIM. 

A domain running SPF without DKIM has no message-level integrity verification. No way to confirm the content wasn’t altered in transit. No DKIM alignment to offer DMARC, which means if SPF fails (and it will, on any forwarded email), DMARC has no fallback. One forwarding rule between a user’s work inbox and their personal account, and authentication falls apart on mail that was entirely legitimate.

Google and Yahoo made both mandatory in February 2024.

Google requires SPF, DKIM, and a DMARC record for all bulk senders dispatching 5,000 or more messages per day. Yahoo requires at least one of SPF or DKIM plus DMARC, though deploying only one means failing Google’s requirements simultaneously. If you send to recipients on both platforms , configuring both is the only way to satisfy all requirements at once.

Even below the 5,000-message threshold, these requirements have effectively become the deliverability standard across major inbox providers. 

What each one covers that the other can’t:

SPF breaks on forwarded mail, by design, per RFC 7208. The forwarding server’s IP replaces the original, that IP isn’t on your authorized list, and the check fails even though nothing went wrong. DKIM doesn’t care about IP changes. The signature travels with the message and validates regardless of which servers it passed through, as long as the content wasn’t modified.

DKIM confirms the message is intact and that the signing domain controlled the private key, but it says nothing about whether the server that sent it had network-level authorization to do so. SPF covers that check.

Neither knows what the other knows. Running both means a receiving server evaluating your mail has the full picture, authorized path and intact content, rather than half of it.

How to Set up SPF and DKIM: Step-by-Step Guide

If your domain doesn’t have SPF and DKIM configured yet, the setup process is straightforward. The steps below cover what you need to get both protocols configured and verified. 

Step 1: Build Your SPF Record

Start by listing every service authorized to send email from your domain like:

1. Your primary mail server
2. Marketing platform
3. CRM
4. Helpdesk tool
5. Transactional email provider, and anything else that sends on your behalf.

Each authorized service gets an include: mechanism in your SPF record, or a direct IP range using ip4: or ip6:. Close the record with -all to tell receiving servers that any IP not on the list is unauthorized.

Before adding IP ranges directly with ip4: or ip6:, confirm the ranges belong to the right sending service. PowerDMARC’s WHOIS IP Lookup lets you verify IP ownership before it goes into your record. 

A basic SPF record looks like this:

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

Watch your DNS lookup count as you add services. RFC 7208 caps SPF evaluation at 10 lookups. Each include: mechanism consumes at least one, and nested includes count toward the same limit. Most domains hit the limit faster than expected once they’re running four or five third-party senders simultaneously.

Use PowerDMARC’s free SPF Generator to build your record without writing the syntax manually, and PowerSPF to keep it under the 10-lookup ceiling automatically as your sending infrastructure changes.

Step 2: Generate and Publish Your DKIM Keys

For each service sending on your behalf, you need a DKIM key pair: 

1. A private key the sending server uses to sign outgoing mail
2. A matching public key published in your DNS for receiving servers to verify.

If a service like Google Workspace or Microsoft 365 handles DKIM signing, they provide the public key record and selector name. Publish the record in DNS at selector._domainkey.yourdomain.com and enable signing in the service’s admin console.

For environments where you generate keys yourself, use at least 2048-bit RSA, 1024-bit is no longer considered adequate. PowerDMARC’s free DKIM Generator produces a ready-to-publish DNS record without requiring command-line tools.

If you’re managing DKIM across multiple sending services, Hosted DKIM handles key generation, DNS publishing, and rotation from one place, without manual DNS edits each time a key needs to change.

Step 3: Add a DMARC Record

Once SPF and DKIM are in place, add a DMARC record to your DNS. Start at p=none to collect aggregate reporting data without affecting mail delivery.

A minimal starting record:

v=DMARC1; p=none; rua=mailto:[email protected];

p=none does not block spoofed messages. It puts DMARC in monitoring mode, so you receive aggregate reports showing which sources are passing and failing authentication, but no mail is quarantined or rejected. 

Use that data to identify misconfigurations and alignment issues, then advance to p=quarantine and eventually p=reject.

A domain sitting at p=none indefinitely is not protected from spoofing. The monitoring phase needs a defined endpoint, not an open timeline.

Step 4: Verify Your Configuration

After publishing your records, confirm each one is resolving correctly before considering setup complete.

Although records resolving correctly is necessary, it is not sufficient by itself. Send a live test to confirm authentication headers are passing end-to-end. PowerDMARC’s SMTP Test tool lets you test your mail server connection and verify SPF, DKIM, and DMARC are passing on actual outbound mail, not just in DNS. 

Common Mistakes

Two most common mistakes that cause authentication failures in production are: 

SPF 10-Lookup Limit

SPF allows a maximum of 10 DNS lookups when a receiving server evaluates your record, a limit set by RFC 7208. Mechanisms like include, a, and mx each trigger a lookup, and they nest. 

Most domains blow past 10 by stacking third-party senders, since every service you authorize with an include consumes lookups. Once you exceed the limit, SPF returns a PermError, and receiving servers treat it as a broken record that no longer authorizes your mail. 

Flattening fixes it by replacing your include mechanisms with the actual ip4 and ip6 ranges they resolve to, dropping your lookup count toward zero.

DKIM Key Rotation

DKIM key rotation is the practice of replacing your DKIM key pair on a schedule, retiring the old private signing key and publishing a new public key in its place. Rotating limits how long any single key is exposed, so if one is ever compromised, the damage window stays small. Most teams rotate every quarter or twice a year, and some providers rotate their own keys automatically.

Most rotation failures come from the steps around the swap. Here’s what admins miss most often.

Removing the old public key too soon

Messages already in transit were signed with the old key, and the receiver needs the matching public key in DNS to verify them. Delete the old record the moment you switch and that in-flight mail fails DKIM. Keep the old key published through an overlap period until all mail signed with it has cleared.

Reusing the same selector

Rotate selectors, don’t overwrite one. Publish the new key under a new selector, move signing to it, then retire the old selector after the overlap. Overwriting a single selector’s record creates a gap where mail signed with the old key can no longer validate.

Switching before DNS propagates

If you flip-sign to the new key before the new public key has propagated, receivers can’t find it and DKIM fails. Publish the new record first, allow for the record’s TTL, then move signing over.

Forgetting third-party senders

Each sending service, like your ESP or CRM, manages its own DKIM keys and selectors. Rotating your primary domain key doesn’t touch those. Rotate each service’s key separately, or confirm the provider handles it for you.

Splitting a 2048-bit record incorrectly

A 2048-bit public key, the current standard and worth upgrading to if you’re still on 1024, often exceeds the 255-character limit of a single DNS TXT string and has to be split into multiple quoted strings. A bad split breaks the record, and the key won’t validate even though it looks present.

Rotating without monitoring

DMARC aggregate reports are how you confirm the new key is validating. Without them, a broken rotation shows up as falling deliverability rather than an alert. Check your reports after every rotation.

Both failures come from records that change faster than you can maintain by hand. PowerDMARC keeps your SPF flattened under the 10-lookup limit and your DKIM keys rotating cleanly, then alerts you the moment something breaks, before it costs you deliverability.

Start your free trial to see where your domain stands today.

FAQs

Does DKIM replace SPF?

No. DKIM verifies message integrity with a cryptographic signature, but it doesn’t confirm the sending server was authorized. SPF handles that check, so both are needed for complete coverage. 

Why does my email fail SPF after forwarding?

SPF checks the delivering server’s IP against your authorized list, and forwarding replaces the original IP with the forwarder’s, which isn’t on your record. This is expected behavior under RFC 7208, and DKIM is designed to survive it because it validates content, not the path. 

Which is more important: SPF or DKIM?

Neither. SPF authorizes at the server level, DKIM verifies at the message level, and both are required for reliable DMARC alignment. Having both lets your mail still pass when one fails on forwarding. 

How many DKIM selectors can I have?

There’s no limit. Publish as many as you need, typically one per sending service or key rotation cycle. Each one lives as a separate DNS TXT record at selector._domainkey.yourdomain.com. 

What happens if I only have SPF but no DKIM?

You lose message-level integrity and have no DKIM alignment fallback, so DMARC can fail on legitimate forwarded mail when SPF breaks. Google’s bulk sender rules also mandate DKIM, which puts high-volume senders out of compliance. 

The post SPF Vs DKIM: What’s the Difference and Do You Need Both? appeared first on PowerDMARC.

*** This is a Security Bloggers Network syndicated blog from PowerDMARC authored by Melika. Read the original post at: https://powerdmarc.com/spf-vs-dkim/