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

That 421 is almost never a DNS problem. It 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 This email has been rate limited because it is unauthenticated.
Gmail requires all senders to authenticate with either SPF or DKIM.
Authentication results: DKIM = did not pass SPF domain-name with ip: ip-address = did not pass.
To resolve this issue, go to Email sender guidelines: https://support.google.com/mail/answer/81126

The stakes are no longer theoretical. Our State of Email Authentication 2026 scan of 5,499,028 domains in February 2026 found 702,000 (12.8%) publishing p=quarantine or p=reject — every one of those domains asks receivers to 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. If the raw dump is unfamiliar, read the headers in trust order first: everything below the first Received line your own infrastructure wrote came from the sender.

Authentication-Results: mx.google.com;
       spf=fail (google.com: domain of alice@example.com does not designate
            192.0.2.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=192.0.2.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 alice@example.com 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). Microsoft uses almost identical language: “SPF breaks after messages encounter server-based email forwarding that redirects or relays messages.” (learn.microsoft.com, updated 2026-07-03).

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, December 2016).

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).
• 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. Wang and Wang’s WWW 2022 study found that Firefox Relay strips authentication headers and iCloud Hide My Email rewrites From without re-sealing, so both break the ARC chain (gangw.cs.illinois.edu), and the EuroS&P 2023 “Forward Pass” study of 20 forwarding services showed forwarding behavior can be combined “to reliably evade existing anti-spoofing controls” (arxiv.org).
• 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’s munge_from mitigation fires by default only when the author publishes p=reject or p=quarantine (dmarc_mitigate_unconditionally extends it to every post), changing the RFC5322.From domain to the list’s own address (alice via list@example.org). DMARC then evaluates against the list domain, which aligns cleanly. Deliverability is saved; authorship attribution is destroyed.

Consumer alias services go further. SimpleLogin forwards “from a special address called reverse-alias” — a per-sender address on its own domain — rather than relaying the original envelope (simplelogin.io). 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.

The receiver logic is where ARC earns its keep. Google’s sender-guidelines FAQ exempts indirect mail from alignment: “DMARC alignment isn’t required for forwarded or mailing list messages, which are sometimes referred to as indirect messages” (support.google.com/a/answer/14229414). The February 2024 guidelines went further and told forwarders to “add ARC headers to outgoing email” (archived 2024-03-10 copy); the live text no longer mentions ARC. 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 accepts DMARC-failing mail only from “a limited set of parties that we trust to implement ARC correctly,” and only when the chain passes and the first-hop AAR shows a DMARC pass (proton.me, 2023).

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 ARC set (AAR, AMS, and AS) 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. Real ARC headers from a production chain walks a Microsoft 365 → Mimecast trace seal by seal, including Microsoft’s oda=1 and reason=130 override fingerprint.

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 IETF’s effort to reclassify RFC 8617 as Historic stalled at the consensus stage in July 2026 against a 16 October 2026 charter deadline (mailarchive.ietf.org); the ARC status breakdown has the details.

The 2026 landscape breaks down like this:

• Google / Gmail. Has sealed inbound mail with its arc-20160816 selector since at least 2017 — the seal appears even on direct deliveries (postmarkapp.com) and validates ARC on inbound mail. The February 2024 sender guidelines told forwarders to add ARC headers; the live guidelines no longer mention ARC. 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. Has implemented ARC since 2017 and interop-tested it with other providers in October 2018 (fastmail.com), but its CEO, Bron Gondwana, told the IETF on 1 February 2026 that Fastmail “(still) doesn’t treat it as having any spam prediction value” (mailarchive.ietf.org).
• Proton. Overrides only when the chain validates and the first-hop AAR shows DMARC passed — the tightest published condition among the providers here; whether Proton seals its own outbound is undocumented (proton.me, 30 June 2023).
• Yahoo. Its sender best practices say “If you forward emails, implement ARC,” but its 30 July 2026 statement to the IETF says it does not apply ARC headers, that accepting other senders’ ARC “has DECREASED our ability to identify email that our users do not wish to receive,” and that its trusted list is “now extremely short” (mailarchive.ietf.org). No tenant trust list.
• Apple iCloud. Lists “Add ARC headers to forwarded emails” among the requirements bulk senders must meet or be rejected (since 2025-02-25); whether iCloud seals or honours ARC itself is undocumented. No tenant trust list.
• Cloudflare Email Routing. Says it “supports Authenticated Received Chain (ARC)” and DKIM-signs its sender rewriting as 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, updated 2026-06-09).

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 Domain Project’s ARC_Community_Sealers repository is the coordinated answer, but with four contributors on GitHub it has not reached critical mass. Microsoft’s June 2022 trusted-sealer announcement counted “approximately 4000 ARC sealers stamping ARC headers” (techcommunity.microsoft.com), and Yahoo’s July 2026 count was “about 12,000 users of ARC — which may sound a lot but it is rather less than half of one percent of the domains sending us email each day.” 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.6 sealed ARC over the body before adding footers, so the body hash never verified downstream (issue 896, fixed in 3.3.6 on 2022-10-26); every currently supported Debian release ships a version past the fix (Debian 13: 3.3.10, Debian 12: 3.3.8).

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 from the scan cited in the introduction. Every one of those domains asks receivers to 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. Google’s threshold is 5,000 messages a day to personal Gmail accounts; Yahoo publishes no number. Both require SPF, DKIM, and DMARC, and Google’s guidelines told forwarders to “add ARC headers to outgoing email” (text since removed from the live page).
• 2025-05-05. Microsoft begins routing non-compliant bulk mail to Junk on consumer mailbox properties (outlook.com, hotmail.com, live.com); the documented rejection is 550 5.7.515 and a blanket rejection date is unannounced (techcommunity.microsoft.com, updated 2025-04-29).
• 2025-07-03. Cloudflare Email Routing begins requiring SPF or DKIM pass before forwarding: “if a message doesn’t pass SPF or isn’t signed with DKIM, it’s not getting forwarded” (spamresource.com, 2025-07-08).
• 2025-10-31. The retirement date Google’s Postmaster Tools banner gave for the v1 dashboard. Google then postponed it — its Help Center still says “we’re postponing the deprecation” with no new date (support.google.com) — and per Spam Resource the pause was lifted in August 2026, with v2’s Compliance dashboard as the replacement (spamresource.com).
• 2025-11. Gmail escalates to SMTP-level deferrals with 421 4.7.26 (“rate limited because it is unauthenticated”) and 421 4.7.40 (“the sending domain doesn’t have a DMARC record, or the DMARC record doesn’t specify a DMARC policy”), and to their permanent counterparts 550 5.7.26 and 550 5.7.40 (knowledge.workspace.google.com, 2026-08). Google’s Email sender guidelines FAQ lists the missing-DMARC deferral as 4.7.31.
• 2026-07-30. Yahoo tells the IETF it does not apply ARC headers and that its trusted-sealer list is “now extremely short” (mailarchive.ietf.org).

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 College phased out its alumni forwarding after the February 2024 provider changes, noting that “email service providers routinely flag forwarded mail as spam” (alumni.reed.edu). A 30-year-old institution — the permanent .edu forwarding address — is a documented casualty of authentication 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 — RFC 8301 §3.2 says signers SHOULD — and rotate them at least every six months, M3AAWG’s 2019 recommendation (m3aawg.org). 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 for domains that rely on DKIM through forwarders: RFC 9989 §7.1 warns that some receivers run SPF before DMARC, so an SPF -all (“hardfail”) “could cause a message to be rejected early in the SMTP transaction” before DMARC’s DKIM-inclusive evaluation runs. Publish SPF with minimal includes, audit for abandoned vendors whenever a sending vendor is added or dropped, 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.6+ (Debian 13 ships 3.3.10, Debian 12 ships 3.3.8) signs after personalization, the fix for the body-hash failures Gmail and Outlook.com reported.
• rspamd’s ARC module, or OpenARC, the Trusted Domain Project’s milter for Postfix and Sendmail — test either against Gmail first; OpenARC issue #128’s missing mandatory fields verdict was never diagnosed.
• Halon (halon-extras/arc) and MailerQ (mailerq.com) ship 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

# 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; Gmail, Microsoft 365, and Proton honour it from trusted sealers, while Fastmail seals and verifies ARC but says it carries no spam-prediction value.

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.6+, rspamd, or OpenARC after end-to-end testing). 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 domains we scanned publish a policy that asks receivers to reject or quarantine 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.