---
title: "DMARC Fails on Forwarded Emails: Why ARC Is the Fix"
description: "Forwarded emails fail DMARC because SPF breaks in transit. See why, when DKIM survives, and how ARC seals the chain across every forwarding hop."
publishedAt: 2026-04-23
tags: ["dmarc", "arc", "forwarding", "email-authentication", "troubleshooting"]
faq:
  - question: "Does forwarding break DMARC?"
    answer: "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 (RFC 8617) is the mechanism designed to preserve the original authentication verdict across hops."
  - question: "What does DMARC fail mean on a forwarded email?"
    answer: "DMARC fail means neither SPF nor DKIM produced an aligned pass at the final receiver. On forwarded mail, SPF almost always fails and DKIM fails only if the message was modified. The receiver then applies the author domain's policy: monitor (p=none), quarantine, or reject."
  - question: "Is ARC the same as DMARC?"
    answer: "No. DMARC decides pass or fail based on SPF and DKIM alignment. ARC preserves those authentication results across forwarding hops so a receiver can trust the first-hop verdict when later hops break SPF or DKIM."
  - question: "How do I fix DMARC failures caused by forwarding?"
    answer: "Sign outbound mail with aligned DKIM so the signature survives unmodified forwarding. If you run a forwarder, ARC-seal outbound mail with Mailman 3.3.8+ or OpenARC. If you are the sender, stay at p=quarantine until DMARC reports confirm all legitimate traffic aligns via DKIM."
  - question: "Can SPF and DKIM both pass but DMARC still fail on a forwarded message?"
    answer: "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 the new domain. Both auth checks pass but neither aligns with the original author's From domain."
---
# 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.

<CodeBlock
  lang="plaintext"
  filename="Gmail bulk-sender rejection (November 2025)"
  code={gmailRejection}
/>

The stakes are no longer theoretical. Our
[State of Email Authentication 2026](/research/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](/learn/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](/learn/dmarc/), 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.

<CodeBlock
  lang="email"
  filename="Authentication-Results on a forwarded message — SPF fail, DKIM pass, ARC pass"
  code={authResultsForwarded}
/>

## 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](https://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](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-about),
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](https://learn.microsoft.com/en-us/exchange/reference/sender-rewriting-scheme),
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](https://www.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](https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/docs/dmarc-mitigations.html),
  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 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 and similar privacy aliases stop
forwarding in the SMTP sense and re-send an entirely new message from their own
domain ([simplelogin.io/security](https://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.

<Figure
  src="/images/blog/dmarc-forwarding-arc-fix/dmarc-forwarding-arc-fix_forwarding-break_flowchart.svg"
  alt="Two-lane flowchart — without ARC, SPF and DKIM fail at the forwarder and DMARC fails. With ARC, the forwarder seals the first-hop verdict and the receiver reads cv=pass to honour the original DMARC pass."
  caption="Without ARC, SPF fails at hop 2 and DMARC rejects. With ARC, the first-hop verdict carries forward via cv=pass and the receiver honours the original pass."
/>

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](https://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](/tools/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](/blog/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).

<CodeBlock
  lang="email"
  filename="An i=1 ARC set added by the first sealer"
  code={arcHeaderSet}
/>

<Figure
  src="/images/blog/dmarc-forwarding-arc-fix/dmarc-forwarding-arc-fix_arc-headers_diagram.svg"
  alt="Three stacked cards labeled AAR, AMS, and AS — each with its role. AS covers both AAR and AMS at this hop plus every prior seal in the chain."
  caption="AAR snapshots the verdict, AMS signs message content at this hop, AS chains every prior seal together with cv= status."
/>

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.

<Figure
  src="/images/blog/dmarc-forwarding-arc-fix/dmarc-forwarding-arc-fix_receiver-support_table.svg"
  alt="Provider-by-provider table — Google, Microsoft 365, Fastmail, Proton, Yahoo, Apple iCloud, Cloudflare Email Routing — showing whether each seals outbound, honours inbound as a DMARC override, and exposes a tenant-editable trust list."
  caption="Provider-by-provider ARC behaviour — who seals outbound mail, who honours ARC as a DMARC override, and who exposes a tenant-editable trust list."
/>

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](https://developers.cloudflare.com/email-routing/postmaster/),
  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](https://www.proofpoint.com/us/blog/email-and-cloud-threats/clock-ticking-stricter-email-authentication-enforcements-google-start),
  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](https://support.google.com/a/answer/14229414),
  2025-11).

The casualties are visible. Columbia discontinued lifetime alumni forwarding on
2025-02-04 ([cuit.columbia.edu](https://www.cuit.columbia.edu/email-forwarding)),
Princeton cut alumni forwarding for the Class of 2026 and later
([dailyprincetonian.com](https://www.dailyprincetonian.com/article/2026/02/princeton-news-stlife-office-of-information-technology-email-forwarding-alumni-accounts),
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](/blog/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](/blog/spf-softfail-vs-hardfail/) for the full
tradeoff, and [SPF PermError fix](/blog/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:

<CodeBlock
  lang="powershell"
  filename="Microsoft 365 — add a trusted ARC sealer and verify"
  code={m365ArcSealer}
/>

### 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](/blog/dmarc-failed-how-to-fix/) covers the
reporting workflow end-to-end, and our
[DMARC checker](/tools/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.

<Callout type="info" title="Future — What comes after ARC: DKIM2">
  In March 2026 the IETF DKIM Working Group adopted
  [`draft-ietf-dkim-dkim2-spec-00`](https://datatracker.ietf.org/doc/draft-ietf-dkim-dkim2-spec/)
  as the consolidated specification for a successor to RFC 6376 DKIM. Authored
  by Richard Clayton (Yahoo), Wei Chuang (Google), and Bron Gondwana (Fastmail),
  it intends Standards Track and expires 2026-07-24. DKIM2 makes every hop sign
  sequentially; intermediaries record modifications in structured "recipes" so
  downstream verifiers can roll back to a known-good state, delivery status
  notifications travel back up the chain, and timestamps plus a 14-day replay
  window are mandatory. Status: working-group adoption, not deployed. Proposed
  Standard is plausibly 18–24 months out. ARC remains the present-day fix for
  every domain reading this today.
</Callout>

## 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.

<CTA
  title="Analyze an ARC chain free — no signup required"
  description="Paste your forwarded-message headers. See each hop's AAR, AMS, and AS validate or fail, with cv= status per seal."
  href="/tools/arc-chain-analyzer/"
  label="Open the ARC chain analyzer"
/>

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](/blog/dmarc-failed-how-to-fix/) covers the six
other common causes.