Why DMARC Fails on Forwarded Emails (and How ARC Fixes It)

When Gmail returns 421 4.7.26 Your email has been blocked because the sender is unauthenticated on a message you actually sent, the hop in the middle — not your DNS — is usually where DMARC broke. This is the shape of almost every modern forwarding failure: a legitimate message leaves your server with SPF and DKIM intact, a forwarder rewrites the envelope, and the final receiver sees an unaligned message that your own policy tells it to reject.

421 4.7.26 Your email has been blocked because the sender is unauthenticated.
Gmail requires all senders to authenticate with either SPF or DKIM. Learn more at
https://support.google.com/mail/?p=auth_error_rcpt_ipv6

The stakes are no longer theoretical. Our State of Email Authentication 2026 scan of 5,499,028 domains found 702,000 (12.8%) publishing p=quarantine or p=reject — every one of those domains will quarantine or bounce a forwarded message that cannot produce an aligned DKIM or a trusted ARC chain. When someone forwards a message from a p=reject domain through Gmail, through a mailing list, or through an alumni alias, the enforcement teeth clamp down on legitimate mail.

This guide explains exactly why DMARC fails on forwarded emails, when DKIM survives the trip, and how the Authenticated Received Chain (ARC) preserves the original authentication verdict across every hop. You will also see the ARC chain analyzer we built specifically for this class of failure — paste raw headers in, see each seal validate or fail.

What “DMARC Fail” Means on a Forwarded Email

A DMARC fail on a forwarded email means neither SPF nor DKIM produced an aligned pass at the receiver. SPF typically fails because the forwarding server’s IP is not in the original domain’s SPF record. DKIM can survive unmodified, but any footer, subject tag, or body rewrite invalidates the signature.

The mechanics underneath that answer matter because three distinct outcomes — SPF fail, DKIM fail, and alignment fail — each point at a different fix.

SPF fail is the baseline: the forwarder’s IP was never authorized by example.com’s SPF record, so the receiver sees a mismatch between the Return-Path domain and the IP that delivered the message. DKIM fail is narrower — the signature covers a specific set of headers and the body, and mailing-list footers, security-gateway URL rewrites, and subject tags all invalidate the hash.

Alignment fail is the subtlest of the three. SPF and DKIM can each produce a pass for the wrong domain. If a forwarder re-signs with d=forwarder.example and rewrites the Return-Path to its own domain, both auth checks return pass, but neither aligns with the original author’s From header. DMARC requires alignment with the From-header domain, not authentication against any domain. The DNS authentication DMARC fail that appears in bounces and aggregate reports is a superposition of these three outcomes; reading the Authentication-Results header tells you which one you are dealing with.

Authentication-Results: mx.google.com;
       spf=fail (google.com: domain of alice@example.com does not designate
            209.85.220.41 as permitted sender) smtp.mailfrom=alice@example.com;
       dkim=pass header.i=@example.com header.s=mail header.b=a1b2c3;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.com;
       arc=pass (i=1 spf=pass dkim=pass dmarc=pass) smtp.remote-ip=209.85.220.41

Why Email Forwarding Breaks DMARC

Forwarding was never a first-class citizen in the SPF, DKIM, and DMARC designs. SMTP assumes mail is forwarded, modified, and re-routed by cooperating intermediaries; the authentication protocols bolted on between 2006 and 2019 assume it is not. The mechanics fall apart at different hops for different reasons — and each is fixable with a different lever.

The SPF path breaks at the first hop

SPF checks whether the sending IP is authorized by the domain in the envelope’s MAIL FROM. When [email protected] forwards to Gmail, the message leaves Gmail’s forwarder with Gmail’s IP — and that IP has never been, and never will be, in example.com’s SPF record. The receiver checks Return-Path against the original domain and mismatches.

Google states this plainly: “Email forwarding can affect message authentication, and forwarded messages often fail SPF authentication.” (support.google.com/a/answer/175365, 2025). Microsoft uses almost identical language: “SPF breaks after messages encounter server-based email forwarding that redirects or relays messages.” (learn.microsoft.com, 2025).

The Sender Rewriting Scheme (SRS) was the 2004-era workaround. SRS rewrites the envelope MAIL FROM to the forwarder’s own domain, which makes SPF pass for the new Return-Path. It does not fix DMARC. Microsoft’s own reference is explicit: “SRS rewriting doesn’t resolve the issue of forwarded messages not passing DMARC checks.” (learn.microsoft.com, 2025-09-24). SPF now aligns with the forwarder’s domain — not the author’s — so DMARC’s alignment requirement fails even though the SPF check itself succeeded.

When DKIM survives — and when it doesn’t

DKIM is the only authentication signal that reliably survives real-world forwarding. It does not depend on the sending IP; it depends on the signature over headers and body. Fastmail’s engineering blog states the practical rule: “If your email is forwarded, SPF will break, but DKIM signatures should survive.” (fastmail.com/blog/spf-dkim-dmarc, 2025).

The qualifier matters. DKIM breaks whenever a forwarder modifies the signed content. Four classes of forwarder routinely do so:

• Mailing lists. Listservs that add [list-name] tags to Subject headers or append unsubscribe footers invalidate the DKIM body hash (docs.mailman3.org, 2025).
• Security gateways. Proofpoint, Mimecast, and Barracuda rewrite URLs for click-time protection, inject compliance banners, and sometimes normalize MIME structure.
• Consumer alias services. iCloud Hide My Email, Firefox Relay, and SimpleLogin rewrite the From header or the body; a 2023 EuroS&P paper showed iCloud’s relay breaks the ARC chain entirely in some configurations.
• Enterprise forwarders with body transforms. Any gateway that adds an “[EXTERNAL]” prefix or a legal disclaimer.

When nothing modifies the message, DKIM passes through untouched. DKIM alignment is the only DMARC pass path that survives a hop the sender does not control.

From-header rewriting and the alignment trap

Some forwarders take a third path and rewrite the From header itself. Mailman 3 activates this mitigation only when the author publishes p=reject or p=quarantine, changing the RFC5322.From domain to the list’s own address (alice via [email protected]). DMARC then evaluates against the list domain, which aligns cleanly. Deliverability is saved; authorship attribution is destroyed.

Consumer alias services go further. SimpleLogin and similar privacy aliases stop forwarding in the SMTP sense and re-send an entirely new message from their own domain (simplelogin.io/security, 2025). That is the 2026 tradeoff: forwarding-as-relay is what breaks DMARC; forwarding-as-resending works, but at the cost of the original sender’s identity.

How ARC Rescues DMARC for Forwarded Mail

ARC, specified in RFC 8617, is the chain-of-custody mechanism designed for this problem. Each hop that handles a forwarded message records what authentication looked like when it received the message and cryptographically seals that statement together with every prior hop’s statement. A downstream receiver that trusts the sealer can read the chain, see that the message passed DMARC at the first hop, and override a late-hop fail.

Does forwarding break DMARC? Yes — by default. SPF fails when the forwarding server’s IP is not in the original domain’s SPF record, and DKIM only survives if the forwarder does not modify the message. ARC is the mechanism designed to preserve the original authentication verdict across hops. That is the 60-word answer to the featured-snippet question.

The receiver logic is where ARC earns its keep. Google’s Workspace admin guidance spells it out: “DMARC alignment isn’t required for forwarded or mailing list messages… however we require that these types of messages have ARC headers.” (support.google.com/a/answer/14229414, 2025-11). When ARC validates with cv=pass and the first-hop AAR shows the message passed DMARC before modification, Gmail and Microsoft 365 can override the downstream failure. Proton is stricter: it overrides only when the chain validates and the first-hop AAR shows DMARC passed at the first hop.

For most sending domains, the debugging question is not whether ARC exists — it does, and the biggest receivers validate it — but whether the chain on a specific message is intact and whose seal it carries.

Paste your ARC headers — see what’s sealed and who verified. Our free ARC chain analyzer breaks down every hop’s AAR, AMS, and AS headers, reports cv= at each hop, and flags the exact hop where the chain falls apart — no signup, no API key. Basic DMARC checkers don’t tell you which receivers sealed your forwarded mail; for that level of detail, most operators end up hand-decoding headers or looking for an MXToolbox alternative that handles ARC natively.

The three ARC headers

An ARC set is three headers added at each hop. Each has a precise role.

• ARC-Authentication-Results (AAR). A snapshot of SPF, DKIM, and DMARC results as the hop saw them. Indexed with i=1 at the first sealer, i=2 at the second, and so on. The AAR is plain text — it is what a downstream receiver reads to learn the original verdict.
• ARC-Message-Signature (AMS). A DKIM-like signature over the message content at this hop. It is what lets a downstream receiver detect modification since this hop. The AMS binds the message body and headers to the sealer’s identity.
• ARC-Seal (AS). A signature covering the AAR and AMS at this hop plus every prior seal in the chain, with a cv= tag recording chain validity (cv=none at i=1, cv=pass at subsequent hops when the prior chain validated, cv=fail when it didn’t).

ARC-Seal: i=1; a=rsa-sha256; t=1745404800; cv=none;
    d=example.com; s=arc-2026; b=Qp7mN8x...truncated
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1745404800;
    d=example.com; s=arc-2026; h=from:to:subject:date:message-id;
    bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=Hk2...truncated
ARC-Authentication-Results: i=1; mx.example.com;
    spf=pass smtp.mailfrom=alice@example.com;
    dkim=pass header.i=@example.com;
    dmarc=pass header.from=example.com

A successful two-hop chain produces six headers: AAR/AMS/AS at i=1 from the first sealer and AAR/AMS/AS at i=2 from the second. The receiver validates the chain from i=2 backwards; a gap in i= numbering or a broken seal invalidates everything downstream.

Who Seals ARC, Who Honours It, Who Doesn’t

The ARC protocol is solved cryptographically. What remains messy is trust — which receivers trust which sealers, and how a new sealer earns reputation. RFC 8617 warns explicitly that ARC “authenticates the identity of some email-handling actors. It does not make any assessment of their trustworthiness.” Every receiver that uses ARC to override DMARC must maintain, implicitly or explicitly, a list of sealing domains it considers honest.

The 2026 landscape breaks down like this:

• Google / Gmail. Validates ARC on every inbound message. Since the February 2024 bulk-sender rules, any forwarder sending more than 5,000 messages per day to Gmail must ARC-seal. Trust is internal and non-configurable; Gmail still runs its own authentication alongside the ARC check.
• Microsoft 365 / Defender. The only major provider with a tenant-editable trusted-sealer list, via Set-ArcConfig -Identity Default -ArcTrustedSealers. The operational fingerprint of a successful override is arc=pass, oda=1, and compauth=pass reason=130 in the message headers — that specific combination is what tells you ARC from a trusted sealer rescued a DMARC fail.
• Fastmail. Seals all transiting mail and is an active contributor to the Trusted Domains Project’s community sealer list.
• Proton. Overrides only when the chain validates and the first-hop AAR shows DMARC passed at the first hop. It is the strictest widely-deployed policy.
• Yahoo and Apple iCloud. Require ARC on bulk forwarded mail; neither exposes a tenant trust list.
• Cloudflare Email Routing. ARC-seals outbound under d=email.cloudflare.net, and concedes in its own docs: “Due to the nature of email forwarding, restrictive DMARC policies might make forwarded emails fail to be delivered.” (developers.cloudflare.com, 2025-07-21).

The bootstrap problem is the structural gap: a new sealer has no reputation until someone trusts it, and nobody trusts it until it has reputation. The Trusted Domains Project’s ARC_Community_Sealers repository is the coordinated answer, but with a small contributor base it has not reached critical mass. Microsoft’s rollout blog observed roughly 4,000 domains stamping ARC headers at launch; the long tail of hobbyist mailing lists still gets treated as unauthenticated because no receiver has them on a trust list.

A practical consequence for operators: turning on ARC signing with a broken implementation is worse than not signing at all. A cv=fail actively suppresses the override Gmail would otherwise grant. Mailman 3 before 3.3.5 shipped buggy seals that Hotmail rejected with arc=fail (47); Debian 12’s Mailman 3.3.8 is the first widely-packaged version that produces clean chains.

Why This Matters More Every Month

The enforcement timeline has been ratcheting for two years, and every step adds domains whose forwarded mail will actually be rejected. The single most useful statistic is the count of enforcement-ready domains: 702,000 of 5,499,028 scanned domains (12.8%) publish p=quarantine or p=reject per our scan cited in the introduction. Each of those 702,000 domains will bounce or quarantine forwarded mail that cannot produce an aligned DKIM or a trusted ARC chain.

The provider-side ratchet tells the same story as a sequence of dates:

• 2024-02. Google and Yahoo announce bulk-sender rules. Any domain sending more than 5,000 messages per day must publish SPF, DKIM, and DMARC, and any forwarder at that volume must ARC-seal.
• 2025-05-05. Microsoft begins rejecting non-compliant bulk mail on consumer mailbox properties (outlook.com, hotmail.com, live.com) (proofpoint.com, 2025).
• 2025-07-03. Cloudflare Email Routing begins requiring SPF or DKIM pass before forwarding. Unauthenticated inbound mail is dropped at Cloudflare’s edge.
• 2025-10-31. Google retires the legacy Postmaster Tools dashboard in favour of a binary Compliance Status view that surfaces forwarding-related SMTP rejections directly to senders.
• 2025-11. Gmail escalates to SMTP-level rejections with 421 4.7.26 (“rate-limited because it is unauthenticated”) and 421 4.7.40 (“sending domain does not have a DMARC policy”) (support.google.com/a/answer/14229414, 2025-11).

The casualties are visible. Columbia discontinued lifetime alumni forwarding on 2025-02-04 (cuit.columbia.edu), Princeton cut alumni forwarding for the Class of 2026 and later (dailyprincetonian.com, 2026-02), and Reed and MIT retired their forwarding-only alumni services citing receiver authentication enforcement. A 30-year-old institution — the permanent .edu forwarding address — is a documented casualty of 2025 enforcement.

Practical Fixes for Senders

The fixes split along two axes: what a sending domain controls, and what a forwarder controls. Most operators run both hats.

Sign with aligned DKIM — always

DKIM with d=example.com aligned to the From header is the load-bearing signal for forwarded mail. It survives unmodified hops, it feeds ARC’s chain of custody when a hop modifies the message, and it is the only DMARC pass path that does not depend on the sending IP. Use 2048-bit RSA keys, rotated at least annually. Our DKIM alignment failure fix covers the specifics for the most common ESP misconfigurations.

Keep SPF lean and honest

Softfail (~all) is the safer default. -all (“hardfail”) triggers SMTP-level rejection before DMARC’s DKIM-inclusive evaluation can run, defeating the point of having two authentication methods. Publish SPF with minimal includes, audit for abandoned vendors annually, and avoid flattening unless you have automated monitoring of IP-range changes. See SPF softfail vs hardfail for the full tradeoff, and SPF PermError fix if your record has drifted over the 10-lookup limit.

ARC-seal if you operate a forwarder

If you run a mailing list, alias service, or any relay that modifies mail, seal ARC on outbound. The deployable options in 2026:

• Mailman 3.3.8+ (shipped in Debian 12) produces clean chains for Google and Microsoft.
• OpenARC milter for Postfix/Sendmail is the reference implementation.
• Halon and MailerQ have native ARC support in commercial MTAs.

Validate your chain end-to-end before turning signing on for real traffic. A cv=fail in the chain actively suppresses the override Gmail would otherwise grant, so a broken seal is worse than no seal. For enterprise delivery into Microsoft 365 tenants, request explicit trusted-sealer placement via the Exchange Online PowerShell cmdlet:

# Add a trusted ARC sealer to Microsoft 365 tenant
Set-ArcConfig -Identity Default -ArcTrustedSealers "listserv.example.org"

# Verify the current trusted-sealer list
Get-ArcConfig -Identity Default | Select-Object ArcTrustedSealers

# Expected success fingerprint in inbound message headers after override
# compauth=pass reason=130  arc=pass  oda=1

Staged rollout from p=none to p=reject

DMARCbis explicitly warns against p=reject for domains whose users appear on mailing lists. Stay at p=quarantine until DMARC aggregate reports confirm every legitimate sender aligns via DKIM, and only then consider reject. The pragmatic rule from 2026: if your mail genuinely matters to human recipients who forward it, quarantine is the ceiling unless you have audited every relay in your ecosystem. Our DMARC troubleshooting guide covers the reporting workflow end-to-end, and our DMARC checker audits your current policy in seconds.

Analyze the ARC headers on a real forwarded message

When a specific forwarded message fails DMARC in your aggregate reports, the fastest diagnostic is the raw ARC headers. Paste them into the analyzer linked above and you get each hop’s AAR, AMS, and AS broken out, with validation status per seal and the cv= outcome at each hop. That is the difference between “DMARC failed on a forwarded message” and “the seal at hop 2 by d=listserv.example.org failed because the body hash did not match after the list footer was added.” The second statement is actionable.

Frequently Asked Questions

Does forwarding break DMARC?

Yes, by default. SPF fails when the forwarding server’s IP is not in the original domain’s SPF record, and DKIM only survives if the forwarder does not modify the message. ARC is the mechanism designed to preserve the original authentication verdict across hops, and the major receivers (Gmail, Microsoft 365, Proton, Fastmail) honour it from trusted sealers.

What does “DMARC fail” mean on a forwarded email?

DMARC fail means neither SPF nor DKIM produced an aligned pass at the final receiver. On forwarded mail, SPF almost always fails because the forwarder’s IP is not in the author’s SPF record, and DKIM fails only if the message was modified. The receiver then applies the author domain’s policy — monitor (p=none), quarantine, or reject.

Is ARC the same as DMARC?

No. DMARC decides pass or fail based on whether SPF or DKIM aligns with the From-header domain. ARC preserves those authentication results across forwarding hops so a receiver can trust the first-hop verdict when later hops break SPF or DKIM. DMARC is the policy; ARC is the chain of custody that keeps the policy evaluable after modification.

How do I fix DMARC failures caused by forwarding?

Sign outbound mail with aligned DKIM so the signature survives unmodified forwarding — this is the load-bearing fix for sending domains. If you run a forwarder, ARC-seal outbound mail with a working implementation (Mailman 3.3.8+ or OpenARC). If you are a sender, stay at p=quarantine until DMARC aggregate reports confirm all legitimate traffic aligns via DKIM, and only then consider p=reject.

Can SPF and DKIM both pass but DMARC still fail on a forwarded message?

Yes, when neither is aligned with the From header. A forwarder can re-sign with its own DKIM (d=forwarder.example) and rewrite the Return-Path so SPF passes for that new domain. Both authentication checks return pass, but neither aligns with the original author’s From domain, so DMARC fails on the alignment requirement rather than the authentication requirement.

Conclusion

Three operational truths sit underneath every forwarded-mail failure. SPF breaks at the first hop, because the forwarder’s IP is not in the author’s record. DKIM survives unmodified hops, and is the only reliable DMARC pass path through forwarders. ARC carries the first-hop authentication verdict forward, so receivers that trust the sealer can honour the original pass even after the chain has been modified.

The stakes are concrete: 12.8% of the internet — 702,000 domains — now rejects or quarantines what your forwarder breaks. The right fix is chain-of-custody, not SPF gymnastics. Sign with aligned DKIM, accept that SPF will not survive forwarding, ARC-seal if you relay other people’s mail, and reach p=reject only after your aggregate reports have been clean for long enough to trust them.

When a specific forwarded message fails and you need to know exactly why, the analyzer above gives you a per-hop breakdown. And if the failure is not actually a forwarding problem, our DMARC troubleshooting guide covers the six other common causes.