SPF and Email Forwarding: Why It Breaks and How to Fix It

Why SPF Breaks on Forwarded Mail

SPF authenticates by checking if the sending server's IP is authorized to send for the From domain.

Normal email flow:

Your ESP (IP: 192.0.2.1) → Recipient's server
SPF check: Is 192.0.2.1 authorized for yourdomain.com? Yes → Pass

Forwarded email flow:

Your ESP (IP: 192.0.2.1) → Forwarder (IP: 198.51.100.1) → Final recipient
SPF check: Is 198.51.100.1 authorized for yourdomain.com? No → Fail

The forwarding server's IP is never in your SPF record—why would it be? You didn't authorize them to send for your domain.

The Forwarding Problem Scenarios

Scenario 1: Auto-forwarding to Personal Email

User has work email auto-forward to Gmail:

[email protected] → [email protected] → [email protected]

Gmail sees company.com's server sending as example.com → SPF fail.

Scenario 2: Mailing Lists

User subscribes to a list with their work email:

[email protected] → [email protected] → subscribers

List server sends as example.com (or keeps original headers) → SPF fail.

Scenario 3: Email Aliases

Domain alias forwards to main inbox:

[email protected] → [email protected] → [email protected]

Alias server sends as example.com → SPF fail.

Practitioner note: The auto-forward scenario burns clients constantly. An executive sets up forwarding to their iPhone, then complains that "important emails are going to spam." SPF failure is usually the culprit.

Solutions

Solution 1: Rely on DKIM

DKIM survives forwarding because it validates the message content, not the sending IP.

Configure DKIM for all senders. If SPF fails but DKIM passes and aligns, DMARC passes.

DMARC evaluation:
- SPF: fail (forwarded)
- DKIM: pass (signature intact)
- Result: DMARC pass (DKIM aligned)

This is the primary reason to always configure DKIM alongside SPF. SPF alone is insufficient for modern email.

Solution 2: ARC (Authenticated Received Chain)

ARC lets forwarding servers attest to the authentication state before they forwarded.

How ARC works:

1. Original sender sends authenticated email
2. Forwarding server receives it (SPF/DKIM pass)
3. Forwarder adds ARC headers signing that authentication passed
4. Final recipient checks ARC and trusts the forwarder's attestation

ARC header example:

ARC-Authentication-Results: i=1; mx.google.com;
    dkim=pass header.d=example.com;
    spf=pass smtp.mailfrom=example.com;
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
    d=google.com; s=arc-20160816; ...
ARC-Seal: i=1; a=rsa-sha256; t=1234567890;
    d=google.com; s=arc-20160816; ...

Limitation: ARC only works if:

• The forwarding server implements ARC
• The receiving server trusts that forwarder's ARC signatures
• Major providers (Gmail, Microsoft) trust ARC from reputable forwarders

Solution 3: SRS (Sender Rewriting Scheme)

SRS rewrites the envelope sender (Return-Path) to the forwarding domain:

Before SRS:

Return-Path: [email protected]
From: [email protected]

After SRS:

Return-Path: [email protected]
From: [email protected]

SPF now checks forwarder.com (for the envelope), which passes. The visible From remains original.

Limitation: SRS only fixes SPF for the envelope. It doesn't help DMARC alignment if you're relying on SPF alignment (Return-Path no longer matches From).

With SRS, you must rely on DKIM for DMARC alignment.

Solution 4: Whitelist Forwarders (Receiving Side)

If you're the recipient experiencing issues, you can whitelist known forwarding IPs:

In Gmail: Create a filter to never send to spam for messages from specific forwarders.

In Microsoft 365: Add forwarding server IPs to your connection filter allow list.

This is a receiving-side workaround, not a sender-side fix.

DMARC Considerations

DMARC passes if either SPF or DKIM aligns. This is intentional—it accommodates forwarding.

Scenario	SPF	DKIM	DMARC
Direct delivery	Pass	Pass	Pass
Forwarded (DKIM intact)	Fail	Pass	Pass
Forwarded (DKIM broken)	Fail	Fail	Fail

The risk: Forwarding servers that modify messages (add footers, change headers) can break DKIM signatures. Then both SPF and DKIM fail, and DMARC fails.

Practitioner note: Some mailing list software adds footers or reformats messages, breaking DKIM. When diagnosing forwarding issues, check if the forwarder modifies content. Content modification is a separate problem from the IP address issue.

Best Practices for Senders

1. Always configure DKIM — Not optional. DKIM survives forwarding; SPF doesn't.

2. Use relaxed DMARC alignment — adkim=r; aspf=r allows subdomains to align, providing flexibility.

3. Don't rely on SPF alone — DMARC alignment via DKIM is more reliable for forwarded mail.

4. Monitor DMARC reports — Aggregate reports show SPF failures from forwarding. This is normal, not a problem, if DKIM passes.

Best Practices for Forwarders

If you operate forwarding infrastructure:

1. Implement ARC — Sign that you received authenticated mail before forwarding.

2. Implement SRS — Rewrite envelope senders so SPF checks your domain.

3. Preserve DKIM — Don't modify message content or signed headers.

4. Consider wrapper mode — Send forwarded mail as an attachment, preserving all original authentication.

For how ARC preserves authentication through forwarding, see ARC and email forwarding. For the complete SPF setup, see the SPF setup guide. For the broader authentication picture, see the email authentication guide. If forwarding issues are affecting your email deliverability and you need help configuring authentication to survive forwarding, schedule a consultation.

Sources

• RFC 7208: Sender Policy Framework (SPF)
• RFC 8617: Authenticated Received Chain (ARC)
• RFC 6530: Internationalized Email
• Gmail Help: Email forwarding and authentication
• Microsoft: Email authentication in Microsoft 365

---

v1.0 · March 2026