Why forwarded email fails SPF — and why DKIM is the only thing saving you

You look at your DMARC aggregate report and something feels off. There are authentication failures from IP addresses you don’t recognize, routing to gmail.com or outlook.com from addresses you’ve never heard of. SPF is failing. DMARC shows a disposition of quarantine or reject for those rows. Did someone start forging your domain?

Probably not. The rows you’re looking at are almost certainly forwarded email — and forwarding breaks SPF by design, every time, on every domain.

Here’s what’s happening and why you shouldn’t add those IPs to your SPF record.

Already in p=none and unsure how exposed you are? Check your domain now at DMARC Guardian’s free domain checker to see your current policy and what’s failing.

What forwarding does to the email authentication stack

When someone receives an email and their mail server forwards it to another address — an alumni account, a role address, a “forward to my Gmail” setting — the forwarding server re-sends the message from its own infrastructure. The original From: header stays intact. The SMTP envelope changes.

That envelope change is the problem.

SPF evaluates the IP address the message arrived from against the domain in the SMTP MAIL FROM (the envelope sender, not the From: header). When the forwarding server re-sends your message, it uses its own domain in the envelope — not yours. The receiving server sees an IP that belongs to, say, a university mail system, and checks whether that IP is authorized to send mail for yourdomain.com. It isn’t. SPF fails.

This isn’t a configuration error. It’s exactly how SPF is supposed to work. SPF was designed to authorize servers to send from your domain. A forwarding server was never authorized to send as you — that’s the whole point.

DKIM handles this differently. A DKIM signature is a cryptographic hash of the message content and certain headers, signed with your private key. That signature travels with the message through forwarding — as long as the forwarding server doesn’t modify the signed portions of the message, the signature remains valid. The receiving server verifies the signature against your public DNS record, it checks out, and DKIM passes.

This is why DKIM alignment is more robust than SPF alignment in the real world. See SPF passes, DMARC fails: the alignment trap for why alignment matters and how DKIM is the mechanism DMARC actually relies on.

How forwarded rows look in aggregate reports

Forwarding creates a distinctive pattern in your DMARC reports that distinguishes it from spoofing:

The tell is DKIM passing while SPF fails. A real attacker spoofing your domain can’t produce a valid DKIM signature — they don’t have your private key. If DKIM is passing, the message is authentic. The SPF failure is a forwarding artifact, not a security problem.

A spoofing attack looks different: DKIM either fails outright, returns none (no signature), or passes with the attacker’s own domain (which doesn’t align with your From: domain). DMARC alignment fails because nothing authenticates against your domain.

The common sources of forwarding failures in reports

Alumni and educational email addresses. Universities commonly forward name@university.edu to the student’s personal Gmail or Outlook after graduation. Your email to a former student hits their alumni forwarding address, gets re-sent from university servers, fails SPF.

Role addresses. A contact@vendor.com or info@partner.com that routes to a shared inbox, which then auto-forwards to individuals. The forwarding hop shows up in your reports.

“Forward to Gmail” setups. A common pattern for small businesses: buy a domain through a cheap registrar, enable their built-in email forwarding to a personal Gmail. Every message you send to their business address gets forwarded through the registrar’s mail servers.

Mailbox migrations. During a migration from one provider to another, old addresses often forward to the new inbox while users get settled. This creates a temporary burst of forwarding failures in your reports.

Mailing list redistribution. Mailing lists — traditional listserv-style lists — receive a message and redistribute it to all subscribers. Some lists rewrite the From: header, add subject-line tags, or append footers. Any of these modifications break the DKIM signature along with the SPF alignment, so the redistributed message fails both. This is a distinct case from simple forwarding and leads to DMARC failures even when DKIM was originally configured correctly.

The ARC protocol (Authenticated Received Chain, RFC 8617) was designed to address this: forwarding and mailing list servers can append cryptographically signed headers documenting the authentication state they observed, so the final receiver can credit the original authentication even after the envelope changed. ARC is supported by Gmail and Outlook and helps forwarded mail survive stricter DMARC policies. But ARC adoption among smaller mail hosts is uneven, and you can’t control whether the forwarding servers your recipients use implement it.

What NOT to do: don’t add forwarder IPs to your SPF record

The instinct is understandable. You see forwarding failures. You think: add those IPs to SPF and the failures go away. Don’t do this.

SPF is an authorization mechanism. Adding a university’s mail server, a registrar’s forwarding host, or an ISP’s SMTP relay to your SPF record tells the world: “This server is authorized to send email as my domain.” That’s not what you want. You’ve just handed SPF authorization to an infrastructure you don’t control. Anyone on that infrastructure — or anyone who can compromise it — can now pass SPF checks as your domain.

The forwarding failures are benign. They’re not hurting your recipients. The solution is to leave them alone and make sure DKIM is carrying the authentication weight, which it already is if DKIM passes for those rows.

What p=reject does to forwarded mail

This is important to understand before you tighten enforcement.

Under p=none, forwarding failures are recorded but no action is taken. Under p=quarantine or p=reject, what happens to forwarded messages depends entirely on whether the receiving server credits DKIM alignment.

If DKIM passes and aligns with your From: domain: DMARC passes (DKIM alignment is sufficient even when SPF fails). The message is delivered normally, regardless of p=reject. This is the correct outcome.

If DKIM doesn’t pass — because the forwarding server modified the message body, stripped attachments, added a footer, or did anything else that invalidates the signature — DMARC fails. Under p=reject, the receiving server is instructed to reject the message entirely. Your legitimate email to someone who forwarded their inbox gets silently dropped.

This is why DKIM configuration for every active sending service is mandatory before moving to p=reject. See Moving from p=none to p=reject safely for the full rollout process.

For the forwarding case specifically: if you’re seeing forwarded messages where DKIM is failing (not just SPF), dig into why. The most common causes are:

• DKIM not configured for that sending service at all — SPF-only setup means forwarding breaks everything
• DKIM signing domain mismatch — the service signs with d=sendgrid.net instead of your domain, which doesn’t survive DMARC alignment evaluation
• Message modification by the forwarding server — some legacy mail systems strip MIME parts or add banners, which invalidates the signature

How to identify forwarding rows in your reports

1. Filter for rows where SPF result is fail or softfail and DKIM result is pass
2. Look at the source IP — resolve it to a hostname: dig -x <ip> +short
3. Check the recipient domain pattern — .edu, .gov, .ac.uk, or consumer provider domains (gmail.com, yahoo.com, outlook.com) receiving from infrastructure of those same types is characteristic of forwarding
4. Check volume — forwarding rows are typically low volume, often 1–10 messages from a given IP

If source IPs reverse-resolve to things like mx1.university.edu or mail.smallbusiness.net or forward.registrar.com, and DKIM is passing, that’s forwarding. It’s benign. File it mentally and move on.

The practical takeaway

DMARC aggregate reports exist to help you find problems. Forwarding failures aren’t a problem — they’re your recipients’ email infrastructure doing its job. The rows look alarming until you understand the pattern.

The actual failure modes to watch for:

• DKIM failing for a legitimate sender you control → Fix DKIM for that service
• Both SPF and DKIM failing from your known sending IPs → Configuration problem in your records
• High-volume failures with DKIM not passing → Possible spoofing or misconfigured sender

DKIM is doing the work here. Keep it configured on every service that sends on your behalf, and the forwarding rows will be the least interesting thing in your reports.

The row that looks like an attacker forging your domain is usually a university forwarding address or a registrar relay — and confusing the two is how teams burn hours chasing a non-problem or, worse, add a third-party server to their SPF and hand attackers a valid pass. DMARC Guardian’s per-source breakdown and IP attribution maps each row to its sending service so you can tell forwarding from spoofing in seconds, not hours.