The Relay in the Middle: Why a Harmless Forward Can Look Exactly Like Spoofing

Forwarding feels like the most innocent setting in email. Someone leaves, you add a rule so their post goes to the shared inbox. A director wants a copy of every invoice at a personal address. A catch-all catches typos and punts them to a colleague. Nobody thinks of it as infrastructure. But every forward creates a new delivery event, and delivery events are exactly what SPF, DKIM and DMARC are built to judge.

That is the awkward bit. The original sender can be perfectly well configured, the recipient can be perfectly legitimate, and the message can still arrive at the final mailbox wearing a suspicious expression. The forwarder in the middle has changed the story the receiver sees.

The forward is not a copy — it is a new delivery event

When a message lands in a mailbox and a rule sends it onward, the receiving server does not usually replay the original SMTP conversation. It creates a new one. Think of it like a post room that opens an envelope, reads the letterhead, puts the letter in a fresh envelope and sends it out again. The letterhead may say one thing; the postmark says another.

That distinction matters because SPF does not look at the visible From header. It looks at the envelope sender — the MAIL FROM identity used in the SMTP conversation. If a message from yourco.co.uk is forwarded by a third-party mailbox, the immediate sender may be that third party, or a relay operated by it. The receiving server checks SPF against the domain it sees in the envelope. If the forwarder has not rewritten the envelope sender properly, the check can fail for the original domain even though the original domain did nothing wrong.

SPF checks the envelope, not the letterhead

This is where a lot of UK businesses get caught. A shared mailbox at a .co.uk domain receives a supplier invoice. An auto-forward rule sends it to a Gmail account used by the finance team. Gmail receives a message that still says From: supplier.co.uk, but the envelope path may now involve Google infrastructure rather than the supplier's mail server. If the supplier's SPF record does not authorise that path, the SPF result can be fail or softfail.

Worse, DMARC alignment can still be broken even when SPF passes for the forwarder. DMARC asks whether the authenticated domain aligns with the visible From domain. If the envelope domain is the forwarder's domain and the visible From is still the original sender, SPF may pass technically but fail alignment. The receiver then leans on DKIM. If DKIM has survived intact, you may be fine. If it has not, the message lands in quarantine or spam with the original sender looking guilty.

DKIM is surprisingly fragile in the middle

DKIM is a signature over selected headers and the body. It is designed to survive ordinary transit, but forwarding is not always ordinary transit. A mailing list may add a footer, change the subject line, rewrite links or strip attachments. A forwarder may add a disclaimer. A security gateway may modify a header. Any of those changes can break the body hash or the header hash, and the signature fails.

Some forwarders preserve the original DKIM signature and add their own. Some break the original but sign again with their domain. That second signature can help authentication, but it does not necessarily satisfy DMARC alignment for the original From domain. This is why two messages that look identical in the inbox can get completely different verdicts: one arrived direct, one arrived through a relay that edited the edges.

Why the original sender gets the blame

From the final recipient's point of view, the visible sender is the supplier, the colleague or the NHS trust. The authentication failure is attached to that domain. The forwarder is invisible. So the supplier gets a bounce, a spam placement or a quiet quarantine, and nobody can work out why the same email reached the same person last week.

The frustrating part is that the original sender often cannot reproduce the problem. Direct mail works. The forward works for some recipients and not others, because different providers apply different weight to SPF, DKIM alignment and local reputation. A Microsoft 365 tenant and a Google Workspace tenant can disagree about the same forwarded message. Add a third-party filtering layer and the postcode lottery gets wider.

The hidden forwarding estate

Most organisations have more forwarding than they think. There are user-level auto-forwards, admin-set rules, shared mailbox redirects, distribution groups with external members, catch-all aliases, ticketing systems that ingest and re-send, and mailing lists that relay to subscribers. Some are documented. Many are archaeology.

You can usually find the obvious ones in the admin centre. The harder ones are the rules created by users years ago, the aliases pointing at old addresses, and the third-party tools that forward on your behalf. If a message to sales@ is copied to a CRM, a helpdesk and a director's personal address, you have three potential relays before the message reaches a human.

An audit you can do this week

Start with a simple inventory. List every domain you send from, every domain you receive on, and every place a message can be redirected. Then work through the following:

• Pull all mailbox-level forwarding rules, including rules that redirect rather than forward. Check whether they point outside your domain.
• Review catch-all addresses. A catch-all that forwards everything to one inbox is a relay with a very wide mouth.
• Check distribution groups and shared mailboxes for external members or auto-forwarding.
• List mailing lists and ticketing systems that accept mail on your behalf and re-send it. Ask whether they use Sender Rewriting Scheme or preserve DKIM.
• Send a test message through each route to a Gmail address, an Outlook.com address and a corporate mailbox. Inspect the full headers, not just the inbox placement.
• Look at Authentication-Results headers. Note whether SPF passes for the forwarder, whether DKIM verifies, and whether DMARC alignment succeeds.
• Check your own SPF record for lookup count and include chains. A record that is already near the limit can behave unpredictably when a relay is added.
• Document every forward with an owner and a purpose. If nobody can explain why it exists, that is a finding.

Fixes that do not involve banning forwarding

Forwarding is not evil. It is how a lot of small UK businesses actually operate. The aim is to make it visible and authenticated, not to outlaw it.

Where possible, use forwarding methods that rewrite the envelope sender correctly, such as SRS, or keep forwarding inside the same mail platform where authentication can be preserved. For mailing lists, choose software that does not mangle DKIM or that signs with its own aligned domain. For catch-alls, consider whether a shared mailbox or alias is safer than a blanket redirect. And if a business-critical flow depends on forwarding to an external mailbox, test it after every change to SPF, DKIM or DMARC.

The relay in the middle is not a scandal. It is a configuration detail. But configuration details are exactly what authentication protocols notice, and a harmless forward can make an honest sender look like a spoof. Audit the rules before the spam filter does it for you.