SPF breaks the moment an email is forwarded — it is the single most common SPF failure pattern in UK business email. This article explains why forwarding breaks SPF, when the breakage matters and when it does not, how DKIM and ARC compensate, and what UK practitioners can and should do when their mail flows through local authority gateways, university relays, or customer forwarding rules.
SPF's core mechanism is "check whether the IP that connected is authorised to send for this domain". When email is forwarded — by a mailing list, a university gateway, a corporate inbound relay, or an individual user's forwarding rule — the IP that connects to the final receiver is the forwarder's IP, not the original sender's. That IP is not listed in the original sender's SPF record. SPF fails.
The failure is not a bug. It is a direct consequence of how SPF is defined: it authenticates the sending server, not the message. When the sending server changes (because the message is now being re-sent by a different server), the authentication changes too.
This is why SPF alone is inadequate for modern email. Any message that passes through any forwarder will fail SPF. Without a compensating mechanism, strict DMARC enforcement (p=reject with SPF-only) would block a large fraction of legitimate mail — including, notoriously, every message sent to a university alumni relay, every forwarded post from a former-staff-member-to-new-staff-member handover, every message through an inbound spam filter that relays to an internal mail server.
Consider a message sent from a Cardiff charity to a recipient at a Manchester university. The university has a policy of forwarding [email protected] addresses to the alumni's current personal email, often at Gmail or Outlook. The path looks like this:
[email protected] connects to mx1.manchester.ac.uk from IP 203.0.113.10. MAIL FROM is [email protected]. SPF is evaluated — IP 203.0.113.10 is in charity.org.uk's SPF. SPF passes.[email protected], Gmail checks SPF for charity.org.uk. IP 155.198.10.5 is not in the charity's SPF record. SPF fails.From: domain. SPF has either failed or passed on the wrong domain (university, not charity). DKIM — if intact — aligns with charity.org.uk, which matches the From:. DMARC passes via DKIM.This is the critical insight: DKIM is the fail-safe when SPF breaks under forwarding. A properly signed message will survive forwarding as long as the forwarder does not modify the signed content.
Every UK university operates alumni forwarding: [email protected] forwards to whatever personal email the alumnus configured. Millions of messages per year cross these forwarders. DKIM compensates.
Many UK councils operate an inbound gateway that applies spam filtering then relays to internal mailboxes. The gateway IP is different from the internal mail server IP. DKIM preserves authentication across the hop.
NHS email addresses routed via NHS.net are relayed by central infrastructure before reaching the clinician's mailbox. The relay is authenticated at the NHS.net perimeter; SPF is checked there and authentication results are passed via ARC to the downstream NHS mail servers.
A UK user might forward their work email to a personal account. SPF will fail on the personal inbox's receiver. DKIM — or the receiver's trust of the forwarder — is what keeps the mail flowing.
Jisc Mail, Mailman-based academic lists, Google Groups, Microsoft 365 Groups — every mailing list is a forwarding hop. Well-configured lists use From-rewriting and ARC to maintain authentication.
Compliance archiving solutions (Mimecast, Proofpoint, Barracuda Journal) often relay mail through their infrastructure before delivery. The hop adds a layer of forwarding. These providers are experts in maintaining authentication; their deployments work correctly by default for most enterprises.
DKIM's cryptographic signature is attached to the message itself rather than to the sending server. As long as the forwarder does not modify the signed headers or the signed body (beyond canonicalisation that DKIM explicitly tolerates), the signature remains valid through any number of forwarding hops. Gmail, Outlook, Yahoo and all major receivers verify DKIM regardless of which server delivered the message.
Three things can break DKIM in forwarding:
h= tag.For messages that do not undergo modification — most simple forwarders, well-behaved gateways — DKIM survives and DMARC passes via DKIM alignment.
ARC (Authenticated Received Chain, RFC 8617) was designed specifically to solve the forwarding problem. An ARC-aware forwarder does three things:
ARC-Authentication-Results header.ARC-Message-Signature header acts like a DKIM signature but is designed to survive modifications.ARC-Seal header cryptographically seals the two previous headers together so that tampering with either is detectable.When the final receiver evaluates a forwarded message, it can walk the ARC chain backwards to verify the original DMARC result reported by the first ARC-aware hop — even if the current SPF and DKIM have failed due to modifications in transit. Gmail and Microsoft 365 both honour ARC chains signed by trusted forwarders and override DMARC failures accordingly.
ARC does not eliminate the forwarding problem entirely — it depends on receivers trusting the forwarder's signature — but it dramatically reduces the false-positive rate for DMARC enforcement across forwarders.
SRS is an older solution that predates ARC. When a forwarder rewrites the envelope sender (MAIL FROM) to an address on its own domain, SPF passes on the forwarder's domain and the bounce path is preserved for delivery failures. SRS is widely implemented in academic Exim deployments and in some corporate gateways.
Example: a message originally sent with MAIL FROM: [email protected] is forwarded by Manchester University. SRS rewrites the envelope to:
MAIL FROM: [email protected]When Gmail receives the message, SPF is evaluated on manchester.ac.uk — the university's SPF authorises their forwarding servers — and passes. The hashed portion of the SRS address lets the university route bounces back to the original sender correctly.
The downside of SRS: SPF now passes on the forwarder's domain, not the original sender's. Under DMARC, this does not count as aligned SPF (envelope sender domain is manchester.ac.uk, but the From: is still charity.org.uk) — so you still need DKIM or ARC to produce a DMARC pass.
Modern mailing list software (Mailman 3, Sympa, most commercial lists) tackles the forwarding problem at the From: header level. When a message is sent to a list, the list software rewrites the From: to an address on the list's own domain:
Original: From: [email protected]
After list processing: From: "Member Name via List Name" <[email protected]>
Reply-To: [email protected]The list then signs the modified message with its own DKIM and publishes its own SPF to cover the new envelope sender. Because the From: is now [email protected] — an address on the list's domain — both SPF and DKIM align with it, and DMARC passes cleanly.
For UK professional bodies (CIPD, ICAEW, RIBA lists), academic lists and many charity discussion groups, this is now the default behaviour. Subscribers see the original author's name in the display portion but the machine-readable From: domain is the list's.
h= tag — signing too many headers makes DKIM more fragile when forwarders modify them. At minimum: From, Date, Subject, Message-ID, Content-Type, MIME-Version.c=relaxed/relaxed tolerates whitespace and header-folding changes that are common during forwarding. simple canonicalisation breaks at the slightest modification.adkim=r, the default) is forgiving of subdomain signing. Strict only when you have full control.If you run a receiving UK mail server — as every SmartXHosting email customer does through the Axigen platform — the forwarding problem manifests on both sides. You receive forwarded mail (and need to handle it gracefully) and you may forward mail (which your downstream recipients need to handle).
DKIM-Signature header must remain intact.When DMARC aggregate reports show failures from IPs you do not recognise, follow this diagnostic tree:
dig -x 155.198.10.5. The PTR record often reveals the forwarder — university.ac.uk, proofpoint.com, mimecast.co.uk.Q: Does every forwarder break SPF?
A: Every forwarder changes the sending IP, so SPF on the original sender's domain fails. Whether this matters depends on whether DKIM or ARC compensates. For a well-configured origin domain, forwarding is usually invisible to users; for a poorly-configured origin domain, forwarded mail disappears into spam folders.
Q: Should I relax my SPF to authorise common forwarders?
A: No. Authorising third-party forwarders in SPF opens your domain to spoofing by anyone who can send through those networks. Solve forwarding through DKIM and ARC, not through SPF permissiveness.
Q: What is the difference between ARC and SRS?
A: SRS rewrites the envelope sender to an address on the forwarder's domain so SPF passes on the forwarder, preserving bounce routing. ARC preserves the original authentication results in signed headers so downstream receivers can trust the original DMARC verdict even after modifications. They are complementary: a modern forwarder often does both — rewrite via SRS, then sign with ARC.
Q: Do I need to do anything special for my mail flow on a SmartXHosting email plan?
A: No. The platform handles DKIM signing, MTA-STS enforcement and ARC signing of forwarded mail automatically. For senders whose mail might later be forwarded, the default configuration produces messages that survive typical UK forwarding scenarios.
Q: Can I test whether my mail survives forwarding before rolling out strict DMARC?
A: Yes. Send test messages to a personal Gmail address configured with a forwarding rule (to another inbox). Inspect the final delivered message's Authentication-Results header — it shows whether SPF, DKIM and DMARC passed on the final receiver side. If DKIM survives, your policy is forwarding-resilient.
Q: Are there situations where SRS is still the right answer?
A: Yes — gateways that cannot sign ARC (legacy MTAs), or forwarding where bounce routing is genuinely needed. Most modern deployments prefer ARC for new forwarders and retain SRS only where legacy interop requires it.
Q: What happens if a forwarder breaks DKIM by modifying the body?
A: DKIM verification fails, DMARC alignment via DKIM fails, and unless ARC compensates the message fails DMARC. The sender domain's DMARC policy then applies — p=none allows delivery anyway, p=quarantine sends to spam, p=reject rejects.
Q: Does publishing relaxed DMARC alignment help with forwarding?
A: No — alignment mode affects how the domain match is judged, not whether SPF and DKIM pass in the first place. Forwarding breaks SPF regardless of alignment mode.
Q: Are there UK-specific forwarding gotchas?
A: The JANET and NHS.net environments are heavily ARC-dependent — any UK public-sector supplier whose mail traverses these networks must rely on ARC for authentication preservation. Local authority networks often have similar patterns. Central government domains on gov.uk use DMARC p=reject and depend on ARC being honoured throughout the forwarding path.
Q: If my DMARC policy is p=reject, will forwarded messages just disappear?
A: They may do, on receivers that do not honour ARC and on messages whose DKIM has been broken by modifications. For normal personal forwarding that preserves DKIM, they will pass. The safest rollout path is to reach p=reject only after monitoring reports show forwarded mail passing via DKIM or ARC alignment at rates you are comfortable with.
Q: Can I detect when a forwarder is silently corrupting my DKIM?
A: Yes — DMARC aggregate reports show per-source results. A source where SPF fails and DKIM also fails (for a legitimate-looking forwarder) is a strong signal that the forwarder is modifying content. Contact the forwarder operator or work around them with ARC-aware alternatives.
Q: Do any major UK institutions still use pre-ARC forwarders that routinely break DMARC?
A: Fewer than before. Most universities adopted ARC between 2020 and 2023. Some legacy academic and research institutions still operate Exim-based forwarders that require manual ARC integration. If your domain's DMARC reports show JANET or specific UK academic domains producing persistent authentication failures, raise the question with that institution's IT team — they will usually have an ARC roadmap or a specific workaround to recommend.
Q: Does inbound gateway filtering count as forwarding for SPF purposes?
A: Yes. An inbound filter (Mimecast, Proofpoint, Barracuda, etc.) receives mail for your domain, inspects it, then relays to your actual internal mail server. Your internal server sees the filter's IP as the sending IP, not the original sender. For the internal evaluation this typically does not matter (the gateway is trusted), but if your internal system then re-evaluates SPF, the results must be ignored in favour of ARC results propagated from the perimeter.
Q: Is there a standard way to indicate in the DKIM signature that this message is tolerant of forwarding?
A: No — DKIM has no such flag. The message either survives modification or it does not, based entirely on the canonicalisation algorithm and which headers were signed. Use c=relaxed/relaxed and sign a minimal essential header list for maximum forwarding survival.
Q: What is the practical impact on mailing lists of modern DMARC enforcement?
A: Old-school mailing lists (Majordomo, early Mailman 2) preserved the original From: and simply re-sent the message. Under DMARC p=reject this causes every list message to fail authentication and be rejected — the UK academic community saw this bite hard when Yahoo published p=reject in 2014. Modern list software rewrites the From: to the list's domain and signs with the list's DKIM, which survives DMARC cleanly. If you run a UK list on old software, upgrading is urgent.
Q: How does ARC get deployed in practice?
A: At the mail server level. For Postfix the opendkim/opendmarc stack supports ARC via OpenARC. Microsoft 365 and Google Workspace both sign ARC on their forwarders by default. The Axigen platform powering SmartXHosting email signs ARC automatically — customers do not configure it. On-premises mail administrators need to enable ARC-signing explicitly.