Mail security (SPF/DKIM/DMARC) — and why forwarding can break it

Email is still built on a trust model from the 1980s: any server can claim it’s sending on behalf of any domain. Modern defenses (SPF, DKIM, and DMARC) add cryptographic and policy signals to reduce spoofing. Unfortunately, common forwarding setups can accidentally strip or invalidate those signals—causing silent delivery failures.

The problem email authentication is trying to solve

SMTP (the protocol used to transfer email between servers) does not, by itself, guarantee that a message claiming to be from alice@example.com actually originated from infrastructure authorized by example.com. That gap is exploited by phishing and impersonation.

SPF, DKIM, and DMARC are three complementary mechanisms used by receiving providers (Gmail, Outlook, Yahoo, etc.) to decide whether to accept, reject, quarantine, or flag messages.

SPF: “Is this server allowed to send mail for this domain?”

SPF (Sender Policy Framework) lets a domain publish which IPs/hosts are allowed to send mail for it. When a receiving server gets a message, it checks the envelope sender (the address used during SMTP, often called the MAIL FROM or “Return-Path”) and compares the connecting server’s IP against the sender domain’s SPF record.

SPF is a path-based check: it describes whether the current hop is an authorized sender. That’s why simple forwarding can cause SPF to fail.

How forwarding breaks SPF

If example.com authorizes only its own mail servers, then a forwarder at forwarder.net will not be on that allowlist. When forwarder.net re-sends the message onward, the receiver sees the forwarder’s IP and SPF for example.com fails.

DKIM: “Is the message content intact and signed by this domain?”

DKIM (DomainKeys Identified Mail) uses a cryptographic signature over selected headers and (usually) the body. The sending domain publishes a public key in DNS; the receiver verifies the signature.

DKIM is a content-integrity check. Unlike SPF, it can survive multiple hops. But it is fragile when intermediaries change the message.

How forwarding can break DKIM

Header edits: adding/removing headers included in the signature can invalidate it.
Body changes: footers, “external sender” banners, subject prefixes, or line-ending rewrites can invalidate it.
Re-encoding: content transfer encoding changes can also affect canonicalization and break verification.

DMARC: “Do SPF or DKIM pass, and do they align with the From address?”

DMARC ties authentication to what users actually see: the header From: domain. A domain publishes a DMARC policy like: p=none (monitor), p=quarantine (treat as suspicious), or p=reject (block).

DMARC generally requires that at least one of SPF or DKIM passes and that it aligns with the visible From: domain (alignment is why “it passed SPF somewhere” isn’t enough).

Why the failure is sometimes silent

Forwarding failures are often confusing because you might not get a bounce. Depending on the receiver’s policy and spam posture, a message that fails DMARC may be:

Rejected during SMTP (sometimes with a clear error, sometimes not surfaced to end users).
Accepted but dropped later in filtering (appearing “lost”).
Quarantined (spam, junk, or a hidden “suspicious” bucket).

This is especially common with large providers: they optimize for user safety and may not give full diagnostics.

The classic forwarding trap: you look like the attacker

Consider a message that claims to be from billing@vendor.com with a strict DMARC policy. If your forwarder re-sends it from an unrelated IP, SPF fails. If the forwarder modifies the message (banners, subject tags), DKIM can fail too. At that point the receiver sees: “a message pretending to be from vendor.com, sent from an unauthorized server, with no valid content signature.” That’s indistinguishable from a common spoofing attack.

Why “just whitelist it” usually isn’t a real fix

Users often try to fix this with mailbox rules (“never send to spam”) or contact whitelists. But DMARC enforcement typically happens before user-level filters apply. If the receiver rejects the message, your mailbox never sees it.

Reliable patterns that avoid breaking authentication

There are a few established approaches that improve reliability. Each has tradeoffs.

1) Don’t forward: deliver directly

The most reliable approach is to change delivery so the destination inbox receives mail directly for that address (for example, by changing MX records or migrating the mailbox). There’s no forwarding hop, so SPF/DKIM/DMARC behave as intended.

2) Preserve DKIM and avoid content changes

If a system must relay messages, it should avoid rewriting the content. Even “helpful” modifications can break DKIM. Unfortunately, many organization mail gateways intentionally modify mail for safety and compliance.

3) Use SRS when forwarding (to help SPF alignment)

SRS (Sender Rewriting Scheme) rewrites the envelope sender when forwarding so bounces work and SPF can pass for the rewritten domain. This can help with SPF, but it does not fix DKIM breakage, and DMARC still depends on alignment.

4) “Inbox injection” instead of re-sending

A fundamentally different pattern is to avoid acting like a mail sender at all. Instead of forwarding via SMTP, a system can append a copy of the received message into the destination mailbox (for example via IMAP). This bypasses many of the forwarding-path authentication pitfalls because the destination provider isn’t asked to accept a new SMTP delivery from a third-party relay.

This is one of the reasons “it arrives as if it was always there” approaches tend to be more reliable than classic provider-to-provider forwarding.

How this relates to MagicForward

If your goal is to keep using Gmail as a unified inbox, but you’re seeing missing messages with classic forwarding, the root cause is often these authentication and filtering interactions. The key is choosing a delivery pattern that doesn’t make legitimate mail look spoofed.