DMARC Analyzer

TL;DR

• ARC (Authenticated Received Chain) is the email-authentication standard that preserves the original SPF / DKIM / DMARC results across forwarding hops. Defined in RFC 8617.
• The problem ARC solves: forwarding (mailing lists, .forward redirects, security gateways) typically rewrites the envelope MAIL FROM and may modify headers — both of which break SPF and DKIM at the downstream receiver. Without ARC, DMARC enforcement would reject legitimate forwarded mail.
• ARC is the only email-authentication standard with NO DNS record — the protocol consists entirely of three per- message header fields plus a chain-validation algorithm at the receiver. The signing key IS published in DNS (DKIM-style at <selector>._domainkey.<domain>), but no _arc.<domain> record exists.
• The three ARC headers: AAR (ARC-Authentication-Results) — snapshot of the receiving hop's verdict, AMS (ARC-Message-Signature) — DKIM-style signature over the message as it leaves this hop, AS (ARC-Seal) — DKIM-style signature over AAR + AMS + every prior ARC-Seal, cryptographically chaining the hops.
• The chain-validation state lives in the cv= tag of the most recent ARC-Seal: cv=pass (every hop validated cleanly), cv=fail (at least one hop broke), or cv=none (this is the first hop). Only cv=pass chains are usable for local-policy override.
• ARC is added by forwarders, not by sending domains. As a domain owner publishing SPF + DKIM + DMARC, you do NOT configure ARC on your domain. You only configure ARC when you OPERATE a forwarder (mailing list, security gateway, transactional relay).
• Receiver support is broad: Google (Gmail / Workspace) since 2017, Microsoft (Outlook / Office 365) since 2021, Yahoo, Fastmail, and many smaller providers. ARC has reached the deployment threshold where DMARC at p=reject is operationally feasible without silently dropping legitimate mailing-list mail.
• DMARC Analyzer's includes/EmailHeaderParser.php recognises every Authentication-Results family header (including ARC-Authentication-Results) so operators can inspect a forwarded message's chain via the Email Header Analyzer.

1. What is ARC?

ARC (Authenticated Received Chain) is an email-authentication protocol defined in RFC 8617 that preserves the original SPF / DKIM / DMARC authentication results across forwarding hops. When a message is forwarded — by a mailing list, a .forward redirect, a security gateway, or any other intermediate handler — the forwarder adds three header fields that cryptographically attest to the authentication state the forwarder observed at its hop. A downstream receiver validates the chain and may grant local-policy override based on a trusted upstream pass, even when SPF and DKIM break at the current hop.

ARC is unique in the email-authentication ecosystem in three ways:

• No DNS record at the protected domain. Every other standard (SPF / DKIM / DMARC / BIMI / MTA-STS / TLS-RPT / CAA) requires a DNS record at a well-known location. ARC requires only per-message headers; the signing key is published as a DKIM-style record under the forwarder's own domain, not the protected sender's.
• Added by intermediaries, not senders. The original sender never adds ARC headers. ARC is the responsibility of every party in the FORWARDING path. The sender's job ends with SPF + DKIM + DMARC; the forwarder's job begins with adding ARC.
• Cumulative across hops. Unlike DKIM (one signature, anchored to the sender) or SPF (one evaluation per hop with no history), ARC builds a CHAIN — every hop appends a new ARC-Seal that cryptographically commits to every prior hop's verdict, so the chain itself cannot be silently rewritten by a malicious intermediate.

ARC's place in the email-authentication ecosystem is auxiliary but operationally critical: without ARC, DMARC enforcement at p=quarantine or p=reject would silently break every mailing list, every .forward redirect, and every security-gateway pipeline. ARC is the standard that makes DMARC enforcement coexistent with the realities of how email actually flows.

2. Why ARC exists: the forwarding problem

A message that traverses a forwarder typically breaks two of the three core authentication-trio results:

• SPF breaks because the forwarder typically rewrites the envelope MAIL FROM. A message originally sent from alice@university.example via MAIL FROM alice@university.example arriving at list@mailman.example gets forwarded out with MAIL FROM bounces@mailman.example. The downstream receiver's SPF check evaluates the new envelope (mailman.example) — the original university.example SPF record is no longer relevant.
• DKIM may break if the forwarder modifies headers or body. A mailing list adding a List-Id header, prepending [list-name] to the Subject, or appending an unsubscribe footer all invalidate the original DKIM signature. Strict canonicalization (c=simple/simple) breaks on any whitespace change; relaxed (c=relaxed/relaxed) tolerates more but still breaks on body modification.
• DMARC fails because DMARC requires at least one of SPF or DKIM to pass AND align with the From: header. With SPF on the new envelope and DKIM broken, DMARC at the receiver returns fail — triggering the policy (p=quarantine → spam folder, p=reject → SMTP bounce).

Pre-ARC, three workarounds existed:

• From: rewriting. The forwarder replaces the From: header with its own domain (From: alice via list <list@mailman.example>). DMARC now evaluates against mailman.example which the forwarder controls. But From: rewriting breaks user trust signals (the recipient sees the forwarder, not the original sender) and breaks reply-by-name in many mail clients.
• DMARC at p=none forever. The domain owner never advances past reporting-only, leaving spoofing wide open in exchange for forwarding survival. Operationally unacceptable for security-conscious senders.
• Special-case allowlisting. Downstream receivers maintain manual lists of trusted forwarders and skip DMARC evaluation for those entities. Doesn't scale and is brittle.

ARC is the standardised fourth option: the forwarder cryptographically attests to the authentication state IT observed, the downstream receiver validates the chain, and legitimate forwarded mail flows even under strict DMARC enforcement at the original sender.

3. How ARC works: the chain mechanism

1. The original sender publishes SPF + DKIM + DMARC and sends the message normally. The sender does NOT add any ARC headers.
2. The first forwarder receives the message and validates SPF / DKIM / DMARC normally. The forwarder then adds three new headers stamped with i=1:
   • ARC-Authentication-Results: i=1; ... — captures the forwarder's verdict (the same content the forwarder would put in its Authentication-Results header per RFC 8601).
   • ARC-Message-Signature: i=1; ... — DKIM-style signature over the message headers and body as the forwarder passes them on, anchored to the forwarder's DKIM key.
   • ARC-Seal: i=1; cv=none; ... — DKIM-style signature over the AAR + AMS at this hop. The cv=none indicates this is the first hop and no prior chain exists.
3. The second forwarder (if any) receives the message including the first hop's ARC headers. It validates the existing chain (the prior ARC-Seal + ARC-Message-Signature), adds its own three headers stamped with i=2, and the cv= tag in its ARC-Seal becomes cv=pass if the prior chain validated cleanly, or cv=fail if it did not. The ARC-Seal at i=2 signs over ALL prior ARC headers (i=1 AAR + i=1 AMS + i=1 AS) PLUS the new AAR + AMS at i=2.
4. Each subsequent forwarder (i=3, i=4, ...) repeats step 3, building an ever-longer chain. RFC 8617 §4.2.1 caps the chain at 50 hops; practical chains rarely exceed 3.
5. The final receiver validates the entire chain by starting at the highest i= value and walking backwards. Each ARC-Seal must validate against its signer's DKIM key; the most recent ARC-Message-Signature must validate against the message as received (older ones usually stop matching after a later modification, and that does not invalidate the chain). If every link in the chain validates AND every prior cv= was pass or none, the chain has integrity. The receiver may then apply a local policy granting delivery override based on the trusted upstream DMARC pass.

The crucial property: an intermediate forwarder that wanted to lie about an earlier hop's verdict cannot — the prior ARC-Seal is cryptographically bound to its own AAR + AMS content. Any tampering with prior hops breaks the chain at validation time. The chain is only as trustworthy as its signers, but the chain itself cannot be silently rewritten.

4. The three ARC headers

The keystone reference for this page. Every ARC-aware forwarder adds exactly three header fields per hop.

The three headers together form one ARC-Set per hop. RFC 8617 §4 defines the exact serialisation. A 3-hop chain has 9 ARC headers (3 sets × 3 fields).

5. ARC chain validation — the cv= states

The chain-validation state lives in the cv= tag of each ARC-Seal. Three values are defined by RFC 8617 §4.4:

• cv=none — This is the first hop in the chain (i=1). No prior chain exists, nothing to validate. cv=none only appears at i=1; any non-first ARC-Seal with cv=none is malformed and treated as cv=fail.
• cv=pass — The sealer validated the chain it found on the message: the structure is correct, the most recent ARC-Message-Signature matches the message, every ARC-Seal validated cleanly against its signer's DKIM key, AND the prior chain's own cv= was either pass (intermediate hops) or none (first hop). The chain has integrity from i=1 through the current hop.
• cv=fail — Validation of the chain found on the message failed. Once cv=fail appears in the chain, it cannot be continued or repaired (RFC 8617 §5.1.3): a sealer that finds the most recent seal at cv=fail adds no further ARC Set. Receivers MUST treat a message with such a chain like a message with no ARC at all, so cv=fail never supports a local policy override.

The validation algorithm at the final receiver (RFC 8617 §5.2):

1. Locate the most recent ARC-Seal (highest i= value).
2. If cv=fail, abort. The chain is unusable.
3. Check the structure: every ARC Set holds exactly one AAR, one AMS and one AS, and the i= values run from i=1 upwards without gaps or repeats. Then validate the most recent ARC-Message-Signature against the message as received; older AMS signatures are optional and their failure does not invalidate the chain. Any failure → mark chain as fail.
4. For each ARC-Seal from highest i= down to i=1: validate the AS signature against the signer's DKIM key. Any failure → mark chain as fail.
5. If every link validated, the chain has integrity. The receiver MAY apply a local policy that grants delivery override based on the trusted upstream DMARC pass recorded in the AAR at the appropriate hop.

Note: ARC chain validation alone does NOT deliver the message. It produces a verdict that the receiver MAY use, weighted against the trust the receiver places in the signers of the chain. A cryptographically-clean chain signed only by untrusted intermediaries is not a delivery green light.

6. A worked multi-hop chain example

Scenario: alice@university.example posts to list@discuss.mailman.example, which fans out to subscribers including bob@gmail.com. The path is sender → mailman forwarder → Gmail receiver.

At the Gmail receiver, the message headers relevant to ARC look approximately like this (whitespace folding omitted for clarity):

Authentication-Results: mx.google.com;
   dkim=fail header.d=university.example
   spf=fail (sender IP is 198.51.100.5) smtp.mailfrom=bounces@mailman.example
   dmarc=fail header.from=university.example;
   arc=pass (i=1 spf=pass dkim=pass dmarc=pass)
ARC-Seal: i=2; a=rsa-sha256; cv=pass; d=google.com; s=arc-20160816;
   t=1715900000; b=<base64-signature-2>
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed;
   d=google.com; s=arc-20160816; t=1715900000;
   h=From:To:Subject:Date:Message-ID:List-Id;
   bh=<body-hash-as-gmail-received-it>;
   b=<base64-signature-2>
ARC-Authentication-Results: i=2; mx.google.com;
   dkim=fail header.d=university.example
   spf=fail smtp.mailfrom=bounces@mailman.example
   dmarc=fail header.from=university.example
ARC-Seal: i=1; a=rsa-sha256; cv=none; d=mailman.example; s=arc1;
   t=1715899000; b=<base64-signature-1>
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
   d=mailman.example; s=arc1; t=1715899000;
   h=From:To:Subject:Date:Message-ID;
   bh=<body-hash-as-mailman-sent-it>;
   b=<base64-signature-1>
ARC-Authentication-Results: i=1; mailman.example;
   dkim=pass header.d=university.example
   spf=pass smtp.mailfrom=alice@university.example
   dmarc=pass header.from=university.example
DKIM-Signature: ... d=university.example ... (BROKEN — body modified by mailman)
From: Alice <alice@university.example>
List-Id: <discuss.mailman.example>
Subject: [discuss] Re: meeting notes

Walking through the chain at Gmail:

• Current-hop verdict (top Authentication-Results): dkim=fail, spf=fail, dmarc=fail. Without ARC, Gmail would reject under DMARC p=reject.
• Chain walk from highest i= downward:
  • ARC-Seal i=2 (Gmail's own seal): cv=pass — Gmail asserts the prior chain validated. Gmail's signature on the i=2 Seal + AMS validates against Gmail's own DKIM key.
  • ARC-Seal i=1 (mailman's seal): cv=none — first hop, no prior chain. Mailman's signature validates against arc1._domainkey.mailman.example.
  • ARC-Message-Signature i=1 (mailman): covers the message as mailman sent it out, with the List-Id header and the Subject prefix already added, which is why Gmail can validate it although the original DKIM signature is broken.
  • ARC-Authentication-Results i=1 (mailman): records spf=pass, dkim=pass, dmarc=pass at university.example.
• Chain verdict: arc=pass. The university's original DMARC pass is cryptographically attested by mailman, attested in turn by the chain integrity through Gmail's own validation.
• Local policy at Gmail: because mailman.example is a trusted ARC signer and the chain validated, Gmail's policy may override the current-hop DMARC fail and deliver the message to bob's inbox.

7. ARC trust model: who you trust to sign and why

ARC chain validation produces a cryptographically- sound chain, but cryptographic soundness alone is not sufficient for local policy override. The receiver must also trust the signers of the chain. A bad-actor forwarder that signs an ARC chain claiming spf=pass dmarc=pass for a message they fabricated would produce a valid chain — but the receiver should not trust that chain.

The trust model rests on three pillars:

• Signer reputation. Receivers maintain implicit or explicit reputation signals for ARC signers. Established mailbox providers (Google, Microsoft, Yahoo, Fastmail) carry high reputation; unknown one-off signers carry low. A chain signed only by low-reputation signers is rarely sufficient for local-policy override.
• Chain coverage. The receiver evaluates which hop in the chain originally observed the DMARC pass. A chain where the FIRST hop is a high- reputation signer that observed dmarc=pass against the original sender's record is the strongest signal. A chain where the first hop is unknown and only later hops are trusted is weaker — the trusted signers have no first-hand observation of the original DMARC state.
• Consistency with declared forwarder identity. The d= in the ARC-Seal should match the receiving entity's identity at that hop (e.g. d=mailman.example for a message that traversed mailman.example). Mismatched d= values are a chain-integrity signal worth flagging.

Practical implication for receivers: ARC is one input to a local policy, not a delivery decision on its own. Most operators implement ARC override only when the chain is signed by a known high-reputation forwarder AND the upstream verdict in the AAR shows a DMARC pass.

8. Receiver support and the local-policy-override expectation

• Google (Gmail / Workspace) — implemented ARC validation on inbound mail in 2017 and outbound signing on every forwarded message. Gmail's Authentication-Results header includes an arc= field summarising the chain. Operators inspecting forwarded mailing-list mail in their Gmail account see the chain state in the message's "Show original" view.
• Microsoft (Outlook.com / Office 365) — implemented ARC validation on inbound mail in 2021 and outbound signing on Office 365 transport- rules forwarding. Microsoft's Authentication-Results header similarly carries an arc= field. The "Trusted ARC sealers" feature in Defender for Office 365 lets administrators explicitly allowlist ARC signers whose chains should be honoured for local- policy override.
• Yahoo (Verizon Media) — ARC signing on outbound forwarded mail since shortly after the RFC was finalised.
• Fastmail, Zoho, ProtonMail — ARC support has been added to most major IMAP-based providers in the years since RFC 8617 was published.
• Mailing-list software — Mailman 3 supports ARC natively; Mailman 2.x deployments typically lack ARC and rely on From: rewriting for DMARC survival instead. Sympa, GNU Mailman 3, mlmmj, and most commercial mailing-list platforms added ARC over 2019-2023.
• Security gateways (Proofpoint, Mimecast, Barracuda) — most added ARC support over 2020-2023 so gateway-relayed mail can survive downstream DMARC enforcement.

Deployment threshold: receiver support is now broad enough that DMARC at p=reject on a sending domain is operationally feasible without ARC-aware forwarders silently dropping legitimate mailing-list mail. Specific exceptions remain (legacy Mailman 2.x deployments, smaller corporate gateways) but they no longer block enforcement strategy at scale.

9. Ten best practices

1. If you SEND mail, do not configure ARC on your domain. ARC is added by forwarders, not senders. Your job ends with SPF + DKIM + DMARC properly configured. RFC 8617 §5.1.4 lets any mail handler seal, but a seal from the original sender tells receivers nothing.
2. If you FORWARD mail (mailing list, security gateway, relay), implement ARC signing. Without it, your forwarded mail will be rejected by downstream receivers enforcing DMARC on the original sender's domain.
3. Use a dedicated ARC selector separate from your DKIM selector. Convention: arc1._domainkey.<domain> for the ARC signing key. This keeps key rotation independent and lets you publish an explicit "ARC signer" identity.
4. Use RSA-2048 minimum for ARC keys (the same RFC 8301 guidance as for DKIM: signers MUST use at least 1024 bits and SHOULD use 2048). RSA-1024 ARC keys produce chains that receivers progressively downgrade.
5. Always sign with c=relaxed/relaxed canonicalization. Simple canonicalization on body content breaks on any whitespace change downstream.
6. Cover the full standard header set in the AMS h= tag: From, To, Subject, Date, Message-ID, Reply-To, Cc, and any List-* headers. Missing headers leave attack surface for downstream modification.
7. Validate inbound ARC before you forward. If you forward a message with an existing ARC chain that fails validation, your outgoing ARC-Seal MUST carry cv=fail. Don't paper over upstream chain breakage.
8. Monitor your outbound ARC chains for receiver acceptance. Google Postmaster and similar feedback channels surface receiver-side ARC validation outcomes — anomalies indicate a signing misconfiguration.
9. Rotate ARC keys on the same schedule as DKIM — at least annually for high-value forwarding infrastructure. Use dual-key publication during rotation.
10. Document your ARC trust decisions. If you operate a receiver applying ARC-based local-policy override, keep an auditable list of which signers are trusted and why. Trust decisions accumulate silently and become invisible legacy without explicit documentation.

10. Nine common mistakes

1. Configuring ARC on a SENDING domain. ARC is added by forwarders. Senders do not need ARC; senders need SPF + DKIM + DMARC. A seal added by the sender does not violate RFC 8617 (§5.1.4 lets any mail handler seal), but it fixes nothing and replaces none of the three.
2. Using c=simple/simple canonicalization on AMS. Simple body canonicalization breaks on any whitespace change. Use c=relaxed/relaxed.
3. Missing the AS Seal entirely. A forwarder that adds AAR + AMS but no AS produces an incomplete ARC-Set. Receivers discard incomplete sets.
4. Out-of-order i= numbering. Hops must be numbered consecutively starting from i=1. Gaps (i=1, i=3) or duplicates (i=1, i=1) break chain validation.
5. Including a bh= tag in the ARC-Seal. AS signs only the header chain, not the body — there is no body hash on AS. Some early implementations got this wrong.
6. Forwarding a cv=fail chain with a cv=pass seal. If the chain you received fails validation, your seal MUST carry cv=fail and cover only your own ARC Set (RFC 8617 §5.1.2). Lying about chain integrity is the canonical ARC violation; receivers detect it immediately on validation.
7. Sharing the ARC selector with DKIM. Same key works cryptographically but mixes operational concerns. Use arc1._domainkey.<domain> for ARC, <dkim-selector>._domainkey.<domain> for DKIM.
8. Relying on ARC to fix a broken DMARC deployment. ARC handles the forwarding edge case; it does NOT fix misaligned SaaS senders or missing DKIM. The sending domain must still publish working SPF + DKIM + DMARC; ARC is the chain-preservation layer on top.
9. Assuming every receiver honours ARC. Receiver support is broad but not universal. Smaller corporate gateways may still ignore ARC entirely and apply DMARC at p=reject to forwarded mail. From: rewriting remains an option for mailing lists that cannot rely on universal ARC support.

11. Troubleshooting

• "My mailing-list mail is being rejected by Gmail / Microsoft". Inspect the rejection bounce — if it mentions DMARC, the cause is almost certainly that the forwarder is not ARC-signing AND the sending domain is at p=reject. Fix: upgrade the forwarder (Mailman 3+, Sympa with ARC plugin) or enable From: rewriting as a fallback.
• "My ARC chain shows cv=fail at receivers". Run your forwarder's outbound mail through the email header analyzer and inspect the AS validation. Common causes: key mismatch (the published DKIM-style record at the ARC selector does not match the private key used to sign), missing prior-Seal coverage in the AS header list, body modification between AMS computation and message dispatch.
• "The receiver reports arc=none on my forwarded mail". The forwarder is not adding ARC headers at all. Check your forwarding software's ARC configuration — some platforms require explicit per-domain enablement (Mailman 3, Postfix with milter, OpenARC).
• "My ARC signature validates but the receiver still rejects". Cryptographic chain validation is one input; signer reputation is the other. Receivers may decline local-policy override for low-reputation signers even on a clean chain. Build delivery reputation via Google Postmaster / Microsoft SNDS / Outlook smart-network.
• "Where do I publish the ARC public key?" Same place as a DKIM key: as a TXT record at <arc-selector>._domainkey.<your-forwarder-domain>. ARC reuses the DKIM key-publication mechanism — there is no separate ARC DNS record format.
• "My Authentication-Results shows arc=pass but DMARC still fails — what now?" ARC pass does not auto-override DMARC fail; it is an INPUT to the receiver's local policy. Whether the receiver applies override is their decision. Most do for trusted forwarders.
• "Where can I debug a multi-hop chain end-to-end?" Use the Email Header Analyzer in DMARC Analyzer and paste the full message headers. The analyser surfaces every Authentication-Results-family header including the ARC chain so you can walk each hop.

12. Frequently asked questions

What is ARC in email authentication?

ARC (Authenticated Received Chain, RFC 8617) is an email-authentication standard that preserves the original SPF / DKIM / DMARC results across forwarding hops. The forwarder cryptographically attests to the original results in three per-message headers (ARC-Authentication-Results, ARC-Message-Signature, ARC-Seal), letting a downstream receiver grant local-policy override based on the trusted chain.

Why does email forwarding break SPF and DMARC?

Forwarding typically rewrites the envelope MAIL FROM (breaking SPF) and may modify headers or body (breaking DKIM). With both SPF and DKIM failing, DMARC at p=quarantine or p=reject rejects the forwarded message — even though it is legitimate. ARC solves this by letting the forwarder vouch for the original authentication state.

What are the three ARC headers?

ARC-Authentication-Results (AAR) captures the receiving party's SPF / DKIM / DMARC verdict at this hop. ARC-Message-Signature (AMS) is a DKIM-style signature over the message headers and body as they leave this hop. ARC-Seal (AS) is a DKIM-style signature over the AAR + AMS + every prior ARC-Seal, cryptographically chaining the hops.

How does ARC chain validation work?

A receiver checks the structure of the chain and validates the most recent ARC-Message-Signature (highest i=) against the message as received, then every ARC-Seal, from the most recent back to the first, against its signer's key. The cv= tag of a seal records the result: pass (chain has integrity), fail (at least one link broke), or none (this is the first hop).

Does ARC replace DMARC?

No — ARC complements DMARC by handling the forwarding edge case. DMARC remains the policy + alignment standard the original domain owner publishes; ARC is the chain-preservation mechanism that lets DMARC enforcement coexist with legitimate forwarding.

Which mailbox providers support ARC?

Google (Gmail, Workspace) since 2017, Microsoft (Outlook, Office 365) since 2021, Yahoo, Fastmail, Zoho, and most commercial mailing-list platforms (Mailman 3, Sympa) and security gateways (Proofpoint, Mimecast, Barracuda) added ARC support between 2019 and 2023.

Do I need to configure ARC on my domain?

No — only if you OPERATE a forwarder. As a sending domain owner publishing SPF + DKIM + DMARC, you do not configure ARC. ARC is added by the entities that FORWARD your mail (mailing lists, security gateways, transactional relays).

What is the difference between ARC and DKIM?

Both use DKIM-style signatures, but DKIM signs ONCE at the original sender, while ARC signs at EVERY forwarding hop. DKIM does not survive header / body modification; ARC explicitly tracks modifications across the chain. They use the same cryptographic primitives (RSA-2048 or Ed25519 with relaxed canonicalization) but solve different problems.

13. Related guides

• Email security glossary — the ARC-AAR-AMS-AS-CHAIN-OF-CUSTODY- PER-HOP-INSTANCE-NUMBERING-TRUSTED-SEALER- VOCABULARY-CONSUMER companion to this ARC pillar. Where THIS page documents the ARC protocol at the byte level (the RFC 8617 three-header chain ARC-Authentication-Results / ARC-Message-Signature / ARC-Seal, the per-hop instance numbering i=<N> grammar, the chain-validation algorithm receivers run to recover the ORIGINAL authentication outcome through forwarder hops, the cv (chain validation) tag values none / pass / fail per RFC 8617 §5.1.1, the trusted-sealer-list receiver-side operational discipline, the per-forwarder-class deployment cookbook for mailing-list-manager and Sieve/.forward forwarders), the email-security-glossary spoke is the VOCABULARY-DEFINITION-REFERENCE companion documenting the canonical definitions for every term-of-art this ARC pillar uses in the body text without inline glossing — readers arriving from a Google search for "what is ARC chain-of-custody" or "what is AAR header" or "what is trusted-sealer list" or "what is MLM hop preservation" need the glossary spoke to establish the ARC-cluster vocabulary baseline before they can productively read THIS page's protocol-level deep dive. The ARC-vs-glossary relationship is pillar-and- vocabulary-reference: THIS page is the canonical RFC 8617 ARC protocol pillar; the glossary spoke is the cross-cluster vocabulary hub the ARC pillar shares with every other message-authentication / forwarder-topology / receiver- side / threat-catalogue pillar in the help cluster. Read the glossary spoke when the reader has not yet established the baseline vocabulary for ARC-cluster terms — ARC (Authenticated Received Chain), AAR (ARC-Authentication-Results) header, AMS (ARC-Message-Signature) header, AS (ARC-Seal) header, chain-of-custody, per-hop instance numbering, trusted-sealer list, chain-validation algorithm, forwarder-hop integrity, cv (chain validation) tag, i (instance) tag, mailing-list expander, .forward / Sieve forwarder, MLM (Mailing List Manager) — each defined in the glossary with the canonical RFC 8617 anchor, the cross-pillar links to the DKIM cryptographic- primitive deep dive (which ARC reuses for AMS / AS signatures) and the DMARC enforcement / alignment deep dives (which ARC was designed to preserve through forwarder hops) and the SPF forwarding-issues spoke (which is the canonical motivating scenario for ARC's RFC 8617 existence), and the operator-side context for when each ARC term- of-art appears in an aggregate- report row's auth_results/arc sub-field, in an inbound message's Authentication-Results / ARC-Authentication-Results header pair, or in the per- forwarder-class trusted-sealer- onboarding incident-response triage when an ARC chain- validation failure surfaces in the operator's inbound-trust monitoring pipeline.
• Email authentication explained — the cluster-intro pillar covering all eight standards (SPF + DKIM + DMARC + BIMI + MTA-STS + TLS-RPT + CAA + ARC) and how they interlock.
• DKIM DNS TXT-record byte syntax — the ARC-SEALER-KEY-PUBLICATION-SHARED- DNS-TXT-RECORD-SYNTAX companion to this ARC protocol pillar. Where THIS page documents the ARC protocol at the byte level (the three-header chain AAR / AMS / AS, the per-hop instance numbering i=<N> grammar, the chain-validation algorithm, the cv tag values, the trusted-sealer-list operational discipline), the DKIM-DNS-syntax spoke is the SHARED-KEY-PUBLICATION-MECHANISM companion documenting the byte-syntax of the public-key TXT record EVERY ARC sealer publishes at <selector>._domainkey.<sealer-domain> to allow downstream receivers to verify the AMS (ARC-Message-Signature) and AS (ARC-Seal) signatures produced at each forwarder hop. RFC 8617 §4.2 EXPLICITLY reuses RFC 6376 (DKIM)'s key-publication mechanism rather than defining a new ARC-specific publication contract — every ARC sealer publishes its AMS/AS signing keys using the same DKIM TXT-record syntax this DKIM-DNS-syntax spoke documents. The four-axis ARC-SEALER-VS- DKIM-KEY-PUBLICATION comparison exposes the structurally-distinct PROTOCOL-LAYER- REUSE roles: (i) every ARC sealer (mailing-list-manager, .forward / Sieve forwarder, automatic forwarding intermediary, security gateway) MUST publish a DKIM-format TXT record at a sealer-domain selector before producing its first AMS/AS signature — the spoke documents the byte-syntax of the publication step the ARC-sealer deployment checklist demands; (ii) the sealer's d= tag in the AMS and AS headers — which names the sealer's signing domain — MUST resolve via the DKIM-format <selector>._domainkey.<d> lookup at every downstream receiver validating the ARC chain; the spoke documents the byte-syntax the sealer's key-publication MUST satisfy to make the chain validatable; (iii) the trusted-sealer-list discipline documented on THIS page — receivers maintain a curated list of sealer-domains whose AMS/AS signatures are admissible for cv=pass — is operationally a list of d= values whose DKIM-format TXT records the receiver retrieves repeatedly to verify the AMS and AS signatures of every forwarded message claiming that sealer's d=; the spoke documents the per-sealer-domain publication contract whose correctness determines whether the sealer can ever enter a downstream receiver's trusted- sealer list; (iv) multi-hop ARC chains (where multiple forwarders each add their own AMS/AS pair at sequential i= instance numbers) require EACH sealer's DKIM-format key- publication to be independently retrievable — a single sealer publishing a malformed p= base64 chunk breaks chain-validation for the entire chain from that hop forward; the spoke documents the byte-syntax that ALL sealers in the chain must satisfy for downstream receivers' chain- validation to recover the original authentication outcome through every hop. Read the DKIM-DNS-syntax spoke when commissioning a new ARC sealer — the sealer's key-publication BYTE- SYNTAX is the precondition the sealer's first AMS/AS signature depends on, and the spoke is the canonical byte-layer publication- correctness reference shared with every other DKIM-publishing sender.
• DMARC explained — the DMARC primer. DMARC enforcement is the reason ARC exists; ARC is what makes DMARC enforcement coexist with legitimate forwarding.
• DMARC record tags explained — every tag in the DMARC DNS record. The original sender's DMARC record is what ARC chains preserve evidence of.
• DMARC alignment explained — identifier alignment is what fails at a forwarder; ARC is the standard that preserves the upstream alignment verdict despite the current-hop break.
• DKIM alignment with DMARC — the DKIM-side alignment procedural deep dive (the ARC-RESIDUAL-ALIGNMENT-REPAIR companion to this ARC chain reference) — the ARC-RESIDUAL-ALIGNMENT-REPAIR companion documenting the DKIM-side alignment rules that ARC was specifically designed to repair when forwarder hops break them. Where THIS page documents the ARC chain protocol (the three-header AAR / AMS / AS chain, the per-hop instance numbering, the cv=pass/cv=fail/cv=none chain-validation status, the seal-signing algorithm receivers run to recover the upstream pre-forwarder authentication outcome), the DKIM-alignment-with-DMARC spoke is the UPSTREAM-IDENTIFIER-ALIGNMENT REFERENCE whose verdict the ARC chain captures and preserves through the intermediate forwarder hops. The ARC-DKIM-alignment interaction has FIVE structurally-distinct repair patterns the cross-reference exposes: (i) mailing-list footer-injection breaks DKIM signature, ARC captures the pre-footer DKIM-aligned-with-From verdict — list-managers like Mailman or GNU Mailman inject footers that break the bh= body hash; ARC seals the pre-injection authentication results so the final-MTA can recover the original-DKIM-d=aligned-with-From-org-domain result; (ii) From-header rewrite at list expansion breaks DKIM-aligned identifier comparison, ARC preserves the upstream DKIM-aligned verdict — when a list rewrites From: user@member.com to From: list@list.org, the downstream DKIM-aligned-with-From check now compares list.org's signing domain against list.org's From — which passes — but ARC also preserves the upstream member.com-aligned verdict for receivers; (iii) academic listserv chains traverse multiple ARC hops — each hop adds an instance-numbered AAR/AMS/AS triple, the final receiver re-runs the seal chain validation and uses the i=1-instance AAR to recover the original-sender's DKIM-aligned-with-DMARC verdict; (iv) broken ARC chains (cv=fail) cannot rescue DKIM-aligned posture — if any seal in the chain fails the AS signature check, the final-receiver MUST NOT trust the captured upstream DKIM-aligned verdict; the message reverts to current-hop DKIM-aligned validation (typically a fail at p=reject); (v) ARC implementations re-sign the AAR with the forwarder's OWN DKIM-aligned identifier — a misconfigured forwarder that does not have its own DKIM-aligned-with-DMARC posture cannot produce trustworthy ARC seals; the DKIM-alignment deep dive documents the signing-side identifier-alignment requirements every ARC sealer must meet.
• Phishing protection — defense-in-depth stack (the ARC-RESIDUAL-PHISHING-EXPOSURE companion to this ARC chain reference) — the ARC-RESIDUAL-PHISHING-EXPOSURE companion documenting the BROADER PHISHING- DEFENSE-IN-DEPTH STACK that surrounds the narrow forwarding-gap repair ARC provides. Where THIS page documents ARC's CRYPTOGRAPHIC CHAIN MECHANISM (the three- header AAR / AMS / AS chain, the per-hop instance numbering, the cv=pass/cv=fail/cv=none chain-validation status, the seal-signing algorithm receivers run to recover the upstream pre-forwarder authentication outcome), the phishing-protection umbrella documents the RESIDUAL PHISHING SURFACE that ARC explicitly DOES NOT close — critical because operators newly familiar with ARC often over-estimate its phishing-defense scope. ARC closes exactly ONE phishing-related gap: the FORWARDER-MEDIATED ALIGNMENT FAILURE where a legitimate forwarder breaks the upstream DMARC verdict by changing the connecting IP and/or modifying the message body. ARC does NOT close: (i) DIRECT-DOMAIN SPOOFING (alignment was never produced in the first place because the attacker forged the From: at message origin — there is no upstream verdict for ARC to preserve, this is the cv=fail/cv=none case the receiver MUST evaluate as fresh DMARC), (ii) DISPLAY-NAME SPOOFING (the attack vector that exploits the "Acme Bank Billing" <billing@unrelated.example> From-header structure — alignment evaluates against the ADDRESS domain not the DISPLAY-NAME phrase, ARC preserves an already-aligned-but-misleading verdict), (iii) LOOKALIKE-DOMAIN REGISTRATION (attacker authors valid DMARC + DKIM + SPF for acmebank.co or acme‐bank.com Unicode- hyphen — the LOOKALIKE'S alignment passes and ARC dutifully preserves the passing verdict downstream), (iv) DKIM- REPLAY-FROM-COOPERATING-SPAMMER (replay produces fresh-aligned messages that ARC treats as legitimate-forwarded mail), (v) REPLY-TO INJECTION (Reply-To is not DMARC-evaluated, ARC has no concept of Reply-To — the user-visible reply target remains a phishing-surface ARC cannot affect). The phishing-protection umbrella documents the complementary defense layers that close THIS RESIDUAL SURFACE: secure- email-gateway anti-impersonation rules, BIMI visual-indicator post-DMARC trust signals, MTA-STS / DANE transport-layer integrity, and user-awareness training for the last-mile attack-vector residual no protocol-layer control can close. Read THIS ARC page WITH the phishing-protection umbrella when scoping an ARC deployment's phishing-defense contribution: the answer is NARROW — ARC repairs forwarding-gap alignment failures, the phishing-defense stack at large requires the multi-layer controls the umbrella enumerates.
• Email spoofing explained — the ARC-EXPLICITLY-DOES-NOT-CLOSE-DIRECT- DOMAIN-SPOOFING parent-threat-class reference documenting the seven canonical email-spoofing techniques ARC chains have ZERO defensive contribution against — critical because operators newly deploying ARC routinely over-estimate its anti-spoofing scope. Where THIS page documents the ARC cryptographic chain mechanism (the three-header AAR / AMS / AS chain, the per-hop instance numbering, the cv=pass/cv=fail/cv=none chain-validation status, the seal-signing algorithm receivers run to recover the upstream pre-forwarder authentication outcome) and ARC's NARROW SCOPE (closing exactly ONE phishing-related gap: the forwarder-mediated alignment failure where a legitimate forwarder breaks the upstream DMARC verdict by changing the connecting IP and/or modifying the message body), the email-spoofing pillar is the PARENT-CLASS DEEP DIVE on the seven canonical spoofing techniques whose alignment was either NEVER produced in the first place OR produced for a lookalike/cousin/IDN-homograph domain — i.e. the entire spoofing-class surface area ARC's chain-preservation mechanism has NO defensive contribution against. The four-axis comparison exposes the structurally-distinct ARC-RESIDUAL-SPOOFING-EXPOSURE roles: (i) Direct domain spoofing (RFC 5322 From: forgery) — the attacker forges the From: header outright at message origin BEFORE any forwarder chain exists; there is no upstream verdict for ARC to preserve, this is the cv=none case receivers MUST evaluate as fresh DMARC; ARC closes ZERO of this attack class; (ii) Envelope MAIL FROM spoofing (RFC 5321 SPF forgery) — the attacker forges the envelope sender at message origin; ARC was engineered specifically to backstop SPF's second-hop break, but ARC cannot detect origination-time envelope-MAIL-FROM forgery because that forgery happens UPSTREAM of every ARC sealer; (iii) Display-name spoofing — the attacker injects "Acme Bank Billing" <billing@unrelated.example> to exploit the From-header structure where alignment evaluates the ADDRESS domain not the DISPLAY-NAME phrase; ARC preserves an already-aligned-but-misleading verdict — i.e. ARC's chain-preservation mechanism is ANTAGONISTIC to display-name-spoofing defense because preserved-alignment is precisely what the attacker wants; (iv) Lookalike-domain registration + IDN homograph + cousin-domain — the attacker authors valid DMARC + DKIM + SPF for acmebank.co or acme‐bank.com Unicode- hyphen; the lookalike's alignment passes, and ARC dutifully preserves the passing verdict downstream — same antagonistic chain-preservation role; (v) Subdomain takeover via abandoned DNS — the attacker registers an expired CNAME target, gains DKIM signing authority for the abandoned subdomain, and sends DKIM-aligned messages from it; ARC preserves the legitimate-signed alignment verdict — same antagonistic role. Read THIS ARC page WITH the email-spoofing pillar when scoping ARC's defensive posture: this page documents the NARROW forwarder-gap repair ARC was engineered to provide, the spoofing pillar documents the SEVEN spoofing classes the broader phishing-defense stack must close through DMARC at p=reject + BIMI visual indicators + secure-email- gateway anti-impersonation + user-awareness training — none of which ARC contributes to.
• DMARC policy rollout — advancing to p=reject is only operationally safe because ARC-aware forwarders preserve the chain. Without ARC, p=reject would silently drop every mailing-list message.
• DMARC policy modes (p=none / p=quarantine / p=reject) — the ARC-AS-POLICY-MODE-FALSE-POSITIVE- RESCUE-MECHANISM companion to this ARC protocol pillar. Where THIS page documents the RFC 8617 chain-of-custody protocol (AAR / AMS / AS headers, per-hop instance numbering, cv chain- validation tag, trusted-sealer list, forwarder-hop integrity preservation), the DMARC policy-modes spoke documents the publisher-side p=none / p=quarantine / p=reject tag whose enforcement ARC chain-validation RESCUES legitimate forwarded mail from — an enforcement-rescue dimension structurally PARALLEL to every chain- validation operation this page documents because (i) under p=reject WITHOUT ARC-awareness at the receiver, every SPF-broken-by-forwarder message gets rejected at the receiver — ARC is the protocol that allows the receiver to retrieve the PRE-FORWARDER SPF-pass verdict from the AAR header and apply a chain-of-custody override that rescues the legitimate forwarded message from the p=reject false-positive trap, (ii) the p=quarantine mode is the operationally-correct staging mode for any publisher whose receiver population is NOT yet uniformly ARC-aware — quarantine isolates the false-positive risk for the legacy- receiver subpopulation while the publisher works through the ARC-deployment-and-trusted-sealer-list audit this page documents, (iii) the p=reject mode is OPERATIONALLY-SAFE only after the publisher has verified that the receiving-MTA population on which their protected domain depends is uniformly ARC-aware — this is the canonical pre-flight check before any p=reject advancement that this page documents in the ARC-aware- receiver-deployment-status section. Read the DMARC policy-modes spoke when scoping the publisher-side policy-mode decision the ARC-chain-validation rescue mechanism this page documents is structurally engineered to support — particularly when the publisher has a material mailing-list-relay footprint and is evaluating whether the receiver population's ARC-aware deployment is uniform enough to sustain a p=reject advancement without false-positive rejections of legitimate mail.
• DMARC aggregate (RUA) reports — the daily XML stream documenting every authentication outcome including the ARC-related disposition overrides receivers applied.
• SPF explained — Sender Policy Framework (RFC 7208). The IP-authorisation layer that ARC exists to backstop when forwarding rewrites the envelope.
• SPF mechanisms explained (RFC 7208 §5 mechanism grammar) — the PER-MECHANISM-CLASS-AS-FORWARDER- BREAK-FAILURE-MODE-AS-INPUT-TO-ARC-CHAIN- RECOVERY companion. Where THIS page is the ARC chain-of-custody protocol pillar (RFC 8617: AAR / AMS / AS header trio, per-hop instance numbering, chain- validation cv= tag, trusted- sealer-list inbound posture), the spf_mechanisms_explained spoke is the PER-MECHANISM-CLASS PUBLICATION REFERENCE documenting the canonical RFC 7208 §5 mechanism grammar whose per-mechanism first-hop verdict is the INPUT ARC chain-of-custody preserves through every forwarder hop. FOUR structurally-distinct per-mechanism forwarder-break dimensions the spoke documents that ARC's chain mechanism recovers: (i) per- include:-cascade publisher mechanism choice as INHERENT forwarder- break failure mode — when the publisher uses include:_spf.<esp> cascades (the canonical M365 + Workspace + transactional-ESP topology), the SECOND-hop forwarder is NEVER part of any cascade-included CIDR pool, so the receiver-side SPF result rewrites to spf=fail at every forwarder boundary — ARC's AAR preserves the ORIGINAL first-hop spf=pass verdict; (ii) per- ip4:/ip6: literal-CIDR mechanism choice as INHERENT forwarder-break failure mode — same forwarder-break topology but a different per-mechanism publication discipline (the publisher enumerates outbound CIDRs literally); ARC's AAR cryptographically commits the original literal-CIDR-derived spf=pass verdict; (iii) per-a:/mx: host-based mechanism choice as INHERENT forwarder-break failure mode — the publisher's outbound A/MX hosts are the first-hop client, the forwarder is NOT, so the second-hop SPF verdict rewrites to spf=fail; ARC's AAR preserves the original host-based-derived spf=pass verdict; (iv) per-all- qualifier publisher discipline as SECOND-HOP-VERDICT-DETERMINING input to ARC chain recovery — the publisher's ~all vs -all choice determines whether the second-hop verdict is spf=softfail or spf=fail; ARC's AAR preserves whichever the original first- hop verdict was. Read the spf_mechanisms_explained spoke alongside this ARC pillar when designing an inbound ARC trust posture against a specific publisher's known SPF mechanism topology — the per-mechanism first-hop verdict the spoke catalogues IS the per-hop AAR payload ARC validates.
• Why SPF alone is insufficient — the FORWARDING-GAP-INPUT raison-d'être companion documenting WHY ARC was needed in the first place — the FORWARDING-GAP-INPUT raison-d'être companion documenting the SPF-only-deployment gaps that motivated ARC's RFC 8617 existence. Where THIS page documents the WHAT and HOW of the ARC cryptographic chain mechanism (the three-header chain, the per-hop instance numbering, the cv= chain-validation status, the seal-signing algorithm receivers run to recover the original pre-forwarder authentication outcome), the why-SPF-alone- is-insufficient spoke documents the WHY — the specific SPF-only-deployment gap that ARC was designed to repair (the forwarding gap: SPF breaks on the second SMTP hop because SPF authenticates the connecting client's IP not the message itself, and forwarders inevitably substitute their own connecting IP at the next hop) plus the four OTHER SPF-only- deployment gaps ARC does NOT repair and which therefore continue to require DMARC's DKIM-aligned-OR-SPF-aligned coverage: (i) the From:-header spoofing gap (SPF authenticates envelope MAIL FROM, not the visible From: header — operators see spf=pass + aligned=false on spoofed messages, ARC cannot detect this because the spoof originates BEFORE the forwarder chain), (ii) the third-party-sender gap (CRM platforms send From: customer-domain.com via vendor infrastructure with vendor-authorised envelope domain — ARC cannot detect this because the original authentication is ALREADY-misaligned), (iii) the mailing-list From:-rewrite gap (mailing lists rewrite the From: to list-name@list.example — ARC preserves the original verdict but the receiver still sees the rewritten From:), (iv) the DKIM-replay-from-cooperating- spammer gap (cooperating spammers can replay legitimately-signed messages with body modifications that DKIM-strict canonicalisation doesn't cover). Read the why-SPF-alone-is- insufficient spoke alongside this ARC page when designing an inbound ARC-trust posture — ARC repairs ONE of the five SPF-only gaps and the broader DMARC-plus-ARC defence is what closes the rest.
• SPF forwarding issues (the second-hop break) — the canonical SPF-failure scenario ARC was designed to backstop — the SPF-FORWARDER-BREAK-MOTIVATING-SCENARIO companion to this ARC protocol pillar. Where THIS page documents the ARC cryptographic chain mechanism (RFC 8617: ARC-Authentication-Results header, ARC-Message-Signature header, ARC-Seal header, the per-hop instance numbering, the chain- validation algorithm receivers run to recover the ORIGINAL authentication outcome through forwarder hops), the forwarding-issues spoke documents the canonical SPF-second-hop-break scenario that motivated ARC's RFC 8617 existence: when an aliased recipient forwards a message through a corporate mailing list / vacation .forward / MLM expander / alumni-alias service / .edu redirect, the connecting client IP at the FINAL receiver is the FORWARDER's IP — not the ORIGINAL sender's IP — so the receiver's SPF check (which is a per- hop IP-match, not a per-message primitive) fails at the second hop. ARC's chain-of-custody mechanism is what allows the final receiver to RE- RECOVER the ORIGINAL pre-forwarder spf=pass verdict via the forwarder's ARC-Authentication-Results seal. Read the forwarding-issues spoke alongside this ARC page when designing an inbound ARC-trust posture (which forwarders' ARC seals to honour as authoritative for re-instating the pre-forwarder SPF outcome) and you need the per-forwarder-class catalogue of legitimate forwarder topologies the ARC trust list must cover.
• DMARC troubleshooting — the ARC-AS-PATTERN-2-FORWARDER-HOP- ALIGNMENT-LOSS-DIAGNOSTIC-LADDER-REMEDY companion to this ARC protocol pillar. Where THIS page documents the ARC cryptographic chain mechanism (RFC 8617: ARC-Authentication-Results header, ARC-Message-Signature header, ARC-Seal header, the per-hop instance numbering, the chain- validation algorithm, the cv tag values none / pass / fail, the trusted-sealer-list operational discipline), the dmarc- troubleshooting spoke documents the four canonical OPERATOR-FACING DIAGNOSTIC LADDERS that surface when a per-publisher per-domain DMARC-aligned-pass-rate regression emerges in the per-receiver per-source-IP rua aggregate-XML stream, and how ARC chain-of-custody is the load-bearing remedy mechanism for Pattern 2 (forwarder-hop-alignment-loss) at four per-pattern ARC-remedy dimensions: (i) Pattern 2 forwarder-hop- alignment-loss diagnostic ladder bottoms out on ARC-chain-validation — when the rua aggregate-XML stream surfaces a per-forwarder-source-IP cohort with policy_evaluated.dkim=fail / policy_evaluated.spf=fail but spf=pass in the Authentication-Results header chain, the Pattern-2 diagnostic ladder walks the operator to the forwarder-hop SPF break + DKIM-body-modification root cause; the ARC chain-of-custody mechanism THIS page documents is the receiver-side REMEDY that lets the FINAL receiver recover the ORIGINAL pre-forwarder spf=pass verdict from the forwarder's ARC-Authentication-Results seal — Pattern-2's diagnostic ladder bottoms out on "deploy ARC trust at the receive boundary"; (ii) Pattern 3 DKIM-alignment-pass-failure diagnostic ladder cross-references ARC-AMS-body- hash validation — when the Pattern-3 ladder walks the operator through the per-forwarder per-class body-modification catalogue (footer- injection, subject-rewrite, MIME- boundary-resynth, MLM-banner-prepend), the ARC-Message-Signature mechanism THIS page documents is the receiver- side primitive that re-anchors the ORIGINAL body-hash verdict THROUGH the forwarder-hop modification surface; (iii) Pattern 4 per-source-IP- cohort-attribution diagnostic ladder consumes ARC-instance-numbering for per-forwarder evidence-row attribution — when the Pattern-4 ladder walks the operator through the per-source-IP-cohort rua-row distribution, the i=<N> per-hop instance- numbering grammar THIS page documents is the attribution-disambiguator that lets the operator separate ORIGINAL- sender per-source-IP cohorts from FORWARDER-hop per-source-IP cohorts at the per-rua-row per-forwarder-hop evidence boundary; (iv) ARC trust-list operational discipline as per-publisher per-domain DMARC- troubleshooting precondition — the operator-side trusted-sealer-list discipline THIS page documents is the load-bearing precondition for any DMARC-troubleshooting investigation that leans on ARC-chain-recovery as the Pattern-2 remedy; if the receiver hasn't deployed an ARC trust list (or the trust list excludes the forwarder), the Pattern-2 diagnostic ladder bottoms out on an operational gap rather than an ARC-recoverable verdict. Read the troubleshooting spoke ALONGSIDE this ARC pillar when scoping the per-publisher per-domain DMARC investigation playbook: ARC is the FORWARDER-HOP-REMEDY at the receive boundary, troubleshooting is the OPERATOR-FACING-LADDER at the publisher boundary, and the two together close the per-publisher per-domain Pattern-2 forwarder-hop-alignment-loss closure loop end-to-end.
• include: vs ip4:/ip6: vs a: vs mx: SPF mechanism choice — the ARC-CHAIN-PRESERVATION-OF-ORIGINAL- PUBLISHER-SPF-MECHANISM-CHOICE companion to this ARC protocol pillar. Where THIS page documents the ARC cryptographic chain mechanism that preserves the original pre-forwarder SPF verdict in the ARC-Authentication-Results header at each forwarder hop, the include-vs-ip4-vs-a-vs-mx spoke is the UPSTREAM-PUBLISHER-MECHANISM-CHOICE- DECISION-MATRIX companion documenting WHICH SPF mechanism the publisher AUTHORED to produce the ORIGINAL first- hop spf=pass verdict that ARC's chain-of-custody mechanism then preserves. The ARC-CHAIN-PRESERVATION- OF-MECHANISM-CHOICE cross-reference establishes FOUR structurally-distinct dimensions where the spoke's per- mechanism reference determines what the ARC-Authentication-Results header commits at each forwarder hop: (i) include: cascade producing first-hop SPF pass — ARC AAR preserves the include-cascade- resolved verdict, NOT the include- target-domain identity — the spoke documents that include-cascade- produced SPF pass verdicts surface in the receiver's auth_results/spf/result=pass + spf.domain = envelope MAIL FROM domain (NOT the include- cascade-target-vendor domain) — ARC sealers commit the spf=pass smtp.mailfrom=<publisher-envelope-domain> evidence into AAR[i] header at each hop preserving the publisher's envelope-MAIL-FROM identity through forwarders, regardless of how many levels of include-cascade recursion produced the original SPF pass — for publishers authoring SaaS-ESP-include- cascade SPF records, the spoke's per- mechanism reference clarifies why ARC sealers reliably preserve the include-cascade verdict identity through hops; (ii) ip4: + ip6: literal CIDR producing first-hop SPF pass — ARC AAR preserves the per-CIDR-match verdict without per-include-cascade recomputation — the spoke documents the ip4:/ip6: literal CIDR semantics where the receiver matches the message's envelope-source IP against the published CIDR list, consuming 0 DNS lookups; ARC sealers commit the same spf=pass smtp.mailfrom=<publisher-envelope-domain> evidence into AAR[i] at each hop — for publishers authoring ip4:/ip6: literal SPF records for budget- conservation, the spoke's per- mechanism reference clarifies that the ip4: choice produces ARC-AAR-preserved verdicts INDISTINGUISHABLE from include-cascade verdicts at downstream receivers (same AAR header byte layout) — the budget-conservation benefit of ip4: literal does NOT require downstream-receiver-side recomputation visibility; (iii) a: mechanism producing first-hop SPF pass — ARC AAR preserves the per-A- record-resolved verdict, requiring original-publisher's A-record stability across forwarder hops — the spoke documents the a: mechanism semantics where the receiver resolves a:<mail-host> to the publisher's A-record IP and matches against envelope-source IP, consuming 1 DNS lookup; for ARC's chain-validation at downstream receivers, the AAR- preserved spf=pass verdict is the historical commitment that the publisher's a:-target hostname's A record DID resolve to the envelope- source IP AT FIRST-HOP TIME — the spoke's per-mechanism reference clarifies the publisher's per-mail- host A-record-stability discipline that backs the ARC-AAR commitment; (iv) mx: mechanism producing first-hop SPF pass — ARC AAR preserves the per-MX- list-resolved verdict, requiring original-publisher's MX-list stability across forwarder hops — the spoke documents the mx: mechanism semantics where the receiver resolves mx:<domain> to the MX-record-host-list and matches each MX host's resolved IP against the envelope-source IP; for ARC's chain- validation at downstream receivers, the AAR-preserved spf=pass verdict is the historical commitment that one of the publisher's MX record-hosts' A records DID resolve to the envelope-source IP AT FIRST- HOP TIME — the spoke's per-mechanism reference clarifies the publisher's per-receiver MX-rotation-cache staleness edge cases where downstream receivers verifying the ARC chain may see spf=permerror or spf=temperror from residual MX state, requiring the publisher's mx: vs ip4: literal choice to inform the ARC-validation reliability calculus. Read the include-vs-ip4-vs-a-vs-mx spoke alongside this ARC protocol pillar when designing both the publisher's ORIGINAL SPF record authoring (which mechanism produces the first-hop verdict ARC commits to preserve) AND the downstream-receiver's ARC-trust posture (which first-hop SPF-mechanism verdicts are reliably preservable through forwarder topology) — the spoke is the canonical per-mechanism- choice decision-matrix reference whose four mechanism-type dimensions each propagate structurally- distinctly through the ARC chain-of- custody mechanism THIS page is the receiver-side validation reference for.
• DMARC myths and misconceptions — the ARC-CHAIN-OF-CUSTODY-AS-RECEIVER- SIDE-REFUTATION-OF-MAILING-LIST-AND-AUTO- FORWARDER-BREAKAGE-MYTH companion to this ARC protocol pillar. Where THIS page documents the ARC cryptographic chain mechanism (RFC 8617: the three-header ARC-Authentication-Results / ARC-Message-Signature / ARC-Seal chain, the per-hop instance numbering i=<N> grammar, the chain-validation algorithm receivers run to recover the ORIGINAL authentication outcome through forwarder hops, the trusted-sealer-list operational discipline, the per-forwarder-class deployment cookbook), the DMARC-myths-and-misconceptions spoke is the OPERATOR-MENTAL-MODEL-CORRECTION catalogue cataloguing the 18 distinct misconceptions about DMARC that recur in operator-side rollout-blocker decision-making, FOUR of which directly engage with the forwarder-chain-of- custody mechanic THIS page documents and which the ARC pillar is the canonical refutation-source for: (i) Myth 11 ("Deploying DMARC will break my mailing lists") — the canonical forwarder-topology myth, refuted at the protocol level by ARC's RFC-8617 chain-of-custody mechanism: the FINAL receiver re-recovers the ORIGINAL pre-forwarder spf=pass / dkim=pass verdicts via the mailing-list-manager's ARC-Authentication-Results seal, so the canonical legitimate-MLM forwarder hop NO LONGER causes a dmarc=fail at the final receiver provided the receiver's trusted-sealer list onboards the MLM — the myth is FACTUALLY-incorrect under post-2019 ARC-deployed forwarder topology; (ii) the implicit forwarder-second-hop-break myth (operators assume ALL forwarder hops cause DMARC failure) — refuted by ARC's chain-of-custody mechanism preserving verdicts across any forwarder hop the receiver has onboarded into its trusted-sealer list, including Outlook.com auto-forwarders, Gmail auto-forwarders, .edu alumni-alias services, and corporate .forward chains; (iii) "ARC just papers over fundamental DMARC brokenness" cynicism — refuted at the protocol-level by ARC's cryptographically-bound per-hop seal chain producing a STRONGER evidence substrate than the bare DMARC verdict the forwarder receives (the AAR cryptographically commits each hop's authentication-results-evaluation in a tamper-evident chain that no other message-authentication standard provides); (iv) "trusted- sealer list is too operationally fragile to deploy" objection — refuted by the per-forwarder-class deployment cookbook this ARC pillar documents (the trusted-sealer list is a finite, well-bounded, slow-changing list of major MLM platforms / major-receiver auto-forwarders / .edu alumni services / corporate forwarders, each with documented sealing domains, public sealing keys, and operational stability sufficient to justify long-lived trust-list entries). Read the myths catalogue alongside this ARC pillar when designing operator-facing rollout documentation that must overcome the forwarder-chain-breakage objections operators raise when blocking DMARC movement from p=none to p=quarantine to p=reject — the myths catalogue is the canonical misconception-correction substrate; this ARC pillar is the canonical protocol-level refutation source.
• SPF DNS record syntax (byte-level TXT-record reference) — the SPF-TXT-RECORD-BYTE-LEVEL- PUBLICATION-PREREQUISITE companion to this ARC pillar. Where THIS page documents the ARC cryptographic chain mechanism (RFC 8617: ARC-Authentication-Results header, ARC-Message-Signature header, ARC-Seal header, the per-hop instance numbering, the chain- validation algorithm receivers run to recover the ORIGINAL authentication outcome through forwarder hops), the SPF-dns-syntax spoke is the BYTE-LEVEL-TXT-RECORD-PUBLICATION upstream prerequisite documenting the canonical v=spf1 … TXT-record byte layout that determines whether the ORIGINAL pre-forwarder spf=pass verdict ARC's chain-of-custody mechanism recovers is itself a CORRECTLY-COMPUTED verdict the operator can trust the AAR cryptographic seal to commit. ARC's value-add evaporates entirely if the ORIGINAL SPF verdict was a permerror (duplicate v=spf1 records, multi-string concatenation breakage, ordering precedence faults, redirect-vs-include semantic confusion, byte-budget overrun) — the forwarder seals a permerror AAR which the downstream receiver propagates as an authoritative permerror verdict through the chain, producing a DOWNSTREAM-AMPLIFICATION of the SPF-publication fault rather than the forwarder-hop-RECOVERY ARC was designed to provide. Read the SPF-dns-syntax spoke alongside this ARC pillar when designing the inbound ARC-trust posture — the operator must verify that EVERY candidate signing-domain SPF record in the org-wide signer inventory passes the SPF-dns-syntax byte-level publication contract (single-record- per-domain, multi-string concatenation correctness, ordering precedence, redirect-vs-include semantic correctness, byte-budget within the EDNS0 4096-byte ceiling) BEFORE the ARC trust list onboards the forwarder topology that depends on those SPF records being correctly-published. The structural relationship is upstream-and- downstream: SPF-dns-syntax controls the byte-level publication of the SPF record at the ORIGINAL signer; ARC controls the cryptographic chain-of-custody of the per-hop-evaluated SPF VERDICT at each forwarder; without correct SPF-dns-syntax publication at the original signer the ARC chain has no valid SPF verdict to preserve in the first place.
• SPF for Microsoft 365 — the M365-TENANT-SPF-PUBLICATION-AS- ARC-CHAIN-PREREQUISITE companion to this ARC pillar. Where THIS page documents the ARC cryptographic chain-of-custody mechanism (RFC 8617: AAR + AMS + AS per-hop sealing, instance numbering, cv tag, chain- validation algorithm), the SPF-for- Microsoft-365 spoke documents FIVE M365-tenant-specific surfaces where the ARC chain composes with M365- tenant SPF authoring at Exchange- Online and EOP forwarder boundaries: (i) the canonical baseline as first-hop SPF-pass producer — M365 tenants publishing the canonical v=spf1 include:spf.protection.outlook.com -all record produce a receiver-side spf=pass verdict at the first hop when the originating envelope is authorised within EOP's outbound netblock — that pass verdict is what ARC subsequently cryptographically commits into the AAR at every downstream forwarder hop, preserving it through Exchange-Online auto- forwarders, Outlook.com mailbox-rule forwarders, and external recipient- side forwarders that ARC-sign their own seal; (ii) the EOP-receive- side ARC sealing of inbound mail — when mail arrives at an M365-tenant's EOP inbound MX (*.mail.protection.outlook.com), EOP itself frequently ARC-seals the message after receiver-side authentication, allowing the M365 tenant's inbound Outlook/Exchange- Online routing through the organisation's own forwarding rules (mailbox-rule auto-forwards, transport- rule forwards, group-distribution-list expansion) to preserve the original SPF verdict through subsequent forwarder hops; (iii) the hybrid Exchange topology dual-egress ARC composition — M365 tenants running a hybrid topology (on-prem Edge Transport + Exchange Online) have TWO outbound egress paths whose SPF verdicts ARC may need to preserve — the EOP-egress path is covered by the canonical include:spf.protection.outlook.com token, but the on-prem Edge-Transport- egress path's SPF authorisation requires the tenant to enumerate the on-prem outbound IPs via ip4:<CIDR> literals or a secondary include token before either path produces a first-hop spf=pass verdict ARC can preserve at downstream hops; (iv) the ARC trust-list inclusion of EOP as a sealer — most major receivers (Gmail, Outlook.com, Yahoo, AOL) include EOP's protection.outlook.com signing identity in their ARC trust list, so M365-tenant-originated mail forwarded through Exchange-Online- intermediary infrastructure has its ARC chain honoured at downstream receivers — extending the M365 tenant's SPF-pass verdict's reach through the full forwarding population, and (v) the permerror-induced ARC chain degradation — when an M365 operator adds excess third- party include: tokens past the 10-lookup ceiling and produces SPF=permerror at the first hop, ARC's chain-of-custody preserves the permerror verdict (not pass), so the M365-tenant SPF-record lookup- budget discipline directly determines whether the ARC chain at downstream forwarders carries a positive or negative SPF verdict. Pair this ARC chain reference with the SPF-for- Microsoft-365 spoke when designing the M365-tenant outbound SPF posture — ARC controls the cryptographic preservation of the per-hop-evaluated SPF VERDICT but the M365 SPF authoring choices documented at the spoke determine what verdict ARC preserves in the first place.
• DKIM explained — DomainKeys Identified Mail (RFC 6376). ARC reuses DKIM's cryptographic primitives and key-publication mechanism.
• DKIM selectors explained — the ARC-CHAIN-CARRIES-SELECTOR-IDENTITY- FOR-CROSS-HOP-VALIDATION companion to this ARC protocol pillar. Where THIS page documents the ARC chain-of-custody protocol (RFC 8617: the AAR / ARC-Authentication-Results + AMS / ARC-Message-Signature + AS / ARC-Seal triplet emitted by each ARC-aware MTA hop, the instance-counter i= tag sequence, the chain-validation algorithm per §5.2), the DKIM-selectors spoke is the SELECTOR-IDENTITY-PUBLICATION-DISCIPLINE companion documenting the per-selector DNS-publication mechanics whose s=-tag identity ARC structurally REUSES at each hop. The four-axis ARC-VS- SELECTOR-IDENTITY comparison exposes the structurally-distinct CHAIN-VALIDATION- SELECTOR-DEPENDENCY roles: (i) the ARC-Message-Signature (AMS) header at each hop embeds a s=<selector> + d=<domain> tag pair identifying the hop's ARC-signing selector in DNS at <selector>._domainkey.<domain> — receiver-side AMS verification fetches the public key from this DNS-published selector and validates the AMS signature the hop produced; the selectors spoke documents the canonical per-vendor selector naming catalogue (Workspace google._domainkey, M365 selector1._domainkey + selector2._domainkey, cPanel default._domainkey, SendGrid s1._domainkey + s2._domainkey, etc.) that every ARC-emitting MTA also follows; (ii) the ARC-Seal (AS) header at each hop ALSO uses a s=<selector> + d=<domain> tag pair — possibly the same selector as the AMS, possibly a separate AS-only selector — whose DNS-published public key the chain- validator fetches to verify the AS sealing the chain-instance count; the selectors spoke documents the per-hop selector-isolation discipline operators use when deploying ARC across multiple forwarding boundaries; (iii) the chain-validation algorithm per RFC 8617 §5.2 walks the ARC instances in i=<n> order and fetches EACH hop's selector-published public key independently — every selector in the chain must remain published for the entire validation window or the chain breaks at the missing-selector hop; the selectors spoke documents the selector-publication-stability discipline and the per-hop rotation cadence operators must coordinate to prevent chain-breakage on previously-validated forwarded mail; (iv) ARC-chain forwarder compromise produces a per-hop selector- replay attack class structurally distinct from the standalone DKIM-replay scenario the selectors spoke catalogues — the per-selector isolation discipline the selectors spoke documents is the operator- side defense against the chain-replay variant where a compromised ARC-emitting intermediary's selector-key is replayed across unrelated chains. Read the selectors spoke alongside this ARC pillar when scoping the selector-publication discipline an ARC deployment depends on — the per-hop selector identity ARC reuses at each chain instance is the load-bearing DNS-publication primitive whose discipline the selectors spoke specifies.
• DKIM failures explained — the canonical DKIM verification-failure taxonomy ARC is specifically designed to prevent on the receiver side. Forwarding- induced DKIM failure is THE motivating scenario for ARC's existence per RFC 8617 §1: a mailing-list expander or Sieve/.forward forwarder modifies the body (adding a list footer, applying a Reply-To header rewrite, or transcoding the Content- Transfer-Encoding) which invalidates the original DKIM body hash on every downstream receiver evaluating against the From:- header domain's published selector — the canonical bodyhash-mismatch failure mode documented on the failures-explained spoke. Where THIS page documents the ARC protocol that PRESERVES the original DKIM result across the forwarding hop via the AAR / AMS / AS triplet, failures-explained documents the underlying DKIM failure class that would have applied at the downstream receiver had the forwarder not sealed the message with ARC. The cross- link is bidirectional: read failures- explained to understand WHICH DKIM-failure classes ARC closes (forwarding-induced bodyhash, signature-over-modified-headers) vs WHICH it does NOT close (selector-key- mismatch on the original signer, expired selector, oversized signature — all of which fail before ARC even runs).
• DKIM troubleshooting — the symptom-driven debugging reference for the DKIM-fail leg ARC is engineered to preserve — the SYMPTOM-DRIVEN diagnostic companion to ARC's preservation contract. Where this ARC pillar documents WHAT ARC preserves across forwarding hops (the original SPF / DKIM / DMARC verdict via the three ARC headers: AAR / ARC-Authentication-Results, AMS / ARC-Message-Signature, AS / ARC-Seal), the DKIM troubleshooting spoke is the OPERATIONAL debugging reference for the DKIM-fail leg that motivated ARC's existence in the first place. Concretely: when ARC is deployed and STILL fails to preserve the original DKIM verdict, the operator's next investigation step is narrowing down to one of the 12+ canonical DKIM-failure symptoms the troubleshooting spoke catalogues — was the failure (1) selector NXDOMAIN at the original signer (ARC cannot recover an absent DKIM signature), (2) public-key truncation past the 255-byte boundary at the signer's selector record (ARC's AMS still works, but the original DKIM=fail propagates), (3) relaxed/relaxed canonicalization mismatch between signer and the receiver verifier (ARC's body canonicalization rules are independent), (4) signature algorithm rejection at modern receivers (RSA-1024 rejected at Microsoft / Google — affects original signature regardless of ARC), or (5) key-rotation overlap-window misconfiguration at the original signer (the ARC chain captures the verdict at the time of sealing, so a stale-key verdict propagates). Pair this ARC pillar (the verdict-preservation protocol) with the DKIM troubleshooting spoke (the symptom-driven debugging companion) when diagnosing the "ARC is deployed but DKIM still fails downstream" investigation path — almost always resolved at the original-signer side, not the ARC layer.
• DKIM replay attacks explained — the DKIM-replay threat class also applies to ARC: ARC-Message-Signature (AMS) and ARC-Seal (AS) headers are DKIM-style signatures over the message and the ARC chain respectively, so an attacker who captures a legitimately-ARC-sealed message can in principle replay it. The mitigation is the same trust-model boundary ARC introduces: the receiver chooses which upstream ARC Sealers it trusts (the Trusted ARC Sealers list, configured in Microsoft Defender for Office 365 via Set-ArcConfig and in Google Workspace via the Admin Console). A captured-and-replayed message arriving from an untrusted sealer is not honoured for DMARC override regardless of the chain's cryptographic validity. Read the replay-attacks deep dive once you understand the ARC protocol on this page and need the threat-model rationale for the trusted-sealer-list discipline.
• DKIM key rotation — the ARC-CHAIN-PRESERVATION-OF-ORIGINAL- SIGNER-DKIM-SELECTOR-IDENTITY-ACROSS- PUBLISHER-SIDE-KEY-ROTATION-CUTOVER-WINDOW companion to this RFC 8617 ARC protocol reference. Where THIS page documents the ARC chain's AAR[i] / AMS[i] / AS[i] triplet as the cross-hop preservation mechanism for the original DKIM signature identity, the key-rotation spoke documents FOUR rotation- vs-ARC-chain interaction dimensions: (i) dual-selector overlap window coordination with in-flight ARC-sealed messages — the publisher MUST retain s1's TXT record for the FULL ARC-chain- max-latency window after the cutover, NOT just the per-hop validation grace period — the rotation spoke documents the canonical operator failure pattern where the publisher rotates from s1 to s2, immediately deletes s1's TXT record after the per-hop validation grace period expires, but ARC-sealed messages captured during the overlap window continue to be forwarded for HOURS-TO- DAYS afterward and downstream ARC-chain verifiers can no longer resolve s1's public key, producing ARC chain validation failures on previously-sealed messages; (ii) rotation cadence vs the canonical ARC-chain-residency window (mailing list digest reposts, in-box- bulk-relay reforwarding, archive- forwarder re-sending old captured messages) — the rotation spoke documents the operator-side discipline of extending s1's TXT-record retention to cover the longest expected ARC-chain residency window (mailing list digests can repost messages weeks after the original send; archive forwarders can re-forward messages months after capture); (iii) per-message-stream rotation coordination across ARC-aware vs ARC- unaware forwarder paths — the rotation spoke documents the per-stream coordination operators must execute when transactional / corporate / marketing streams flow through DIFFERENT ARC-sealing infrastructures (M365 Defender ARC-sealing path vs Workspace ARC-sealing path vs ESP-managed ARC-sealing path), each with its own observed-ARC-chain- residency-window distribution; (iv) compromised-key scenarios where immediate selector retirement is required BUT ARC-chain integrity requires retention — the conflict between security-incident- response (retire compromised selector NOW) and operator-side ARC-chain integrity (retain selector for the residency window) — the rotation spoke documents the canonical operator-side incident-response decision framework: retire the compromised selector immediately at the DNS layer; flag the impacted ARC-chain window as known-unverifiable for the residency-window duration; coordinate with downstream ARC-aware receivers (M365 Defender, Google Workspace) to suppress ARC-chain-fail-related deliverability impact during the incident-response window. Read the key-rotation spoke when planning a rotation event on a domain whose outbound mail flows through ARC-sealing intermediaries — the spoke is the authoritative per-rotation operational reference for the DKIM-rotation-meets- ARC-chain-residency-window cross-cluster boundary.
• How attackers bypass DMARC — the ARC-TRUST-CHAIN-FORWARDER-RESIGNING- AS-LEGITIMATE-BYPASS-VECTOR companion to this RFC 8617 Authenticated Received Chain protocol reference. Where THIS page documents the ARC trust-model (AAR[i] / ARC-Authentication-Results carrying the per-hop verification verdicts; AMS[i] / ARC-Message-Signature cryptographically committing the message bytes at the ARC sealing hop; AS[i] / ARC-Seal cryptographically committing the AAR/AMS chain at each hop; the Trusted ARC Sealers list bounding which upstream sealers a receiver honours for DMARC override), the attacker-bypass spoke documents the STRUCTURED 22-TECHNIQUE BYPASS CATALOGUE in which the §6.1 ARC-TRUST-CHAIN- FORWARDER-RESIGNING class is the canonical ATTACK SURFACE this RFC 8617 protocol structurally creates BY DESIGN — ARC's entire design premise is that a forwarder may legitimately modify the message in ways that break the original DKIM signature, so ANY mailbox-provider on the receiver's Trusted ARC Sealers list can emit an arc=pass verdict that overrides the broken DKIM/SPF signal AND therefore DOWNSTREAM DMARC enforcement. The attacker-bypass catalogue documents the FIVE structurally-distinct exploit paths operators need to triage: (i) FORGED AAR-i CARRYING FABRICATED spf=pass / dkim=pass RESULTS at a compromised intermediate sealer hop the receiver's trusted-sealer-list still honours (the mitigation: receiver-side Trusted ARC Sealers list MUST be tightly curated to the upstream forwarders the downstream receiver actually trusts; Microsoft EOP defaults to a strict first-party list ignoring third-party sealers); (ii) ARC-CHAIN-REPLAY against a previously-legitimately-sealed message (the mitigation: AS[i] header binds the chain to a specific message instance via the body-hash, but a captured-and-replayed message from the same upstream sealer still cryptographically validates, forcing the receiver to fall back to DKIM-replay-attack-class mitigations documented in the replay-attacks spoke above); (iii) COMPROMISED SEALER PRIVATE KEY at a previously-trusted forwarder (the mitigation: receiver-side trusted- sealer-list deprovisioning + AS-key rotation per the upstream's DKIM key- rotation cadence + retroactive arc=pass audit-log scrub for the compromise window); (iv) SELECTOR-SQUATTING against a deprovisioned upstream sealer's previously-published AS selector (the mitigation: trusted-sealer-list bound to a SPECIFIC d=/s= selector pair, not just the d= domain); (v) CROSS-TENANT-SEALER- SUBSTITUTION at a shared multi-tenant platform where a tenant on the receiver's Trusted ARC Sealers list emits arc=pass for a different tenant's message via the same platform infrastructure (the mitigation: trusted-sealer-list bound to a SPECIFIC tenant identifier in the AAR-i / AMS-i header rather than just the platform-shared d=). Read the attacker- bypass spoke when your receiver-side Trusted ARC Sealers list is non-trivially large or contains third-party forwarders that may themselves be compromised — the spoke's §6.1 ARC-trust-chain-forwarder- resigning class maps EVERY ARC-chain exploitation vector onto a concrete threat-actor TTP (T1078 valid-accounts compromise of an upstream sealer mailbox- provider tenant, T1556.006 multi-factor- authentication-bypass at the sealer admin console, T1556 modify-authentication- process via Set-ArcConfig poisoning) so the on-call first-responder can pivot from an observed arc=pass-but-still- suspicious downstream verdict into the right incident-response runbook rather than clearing the message as ARC-validated-and-therefore-trusted.
• DKIM best practices — the ARC-CHAIN-PROTOCOL-LAYER-INHERITS- DKIM-KEY-CRYPTOGRAPHY-AND-SIGNING-HYGIENE companion reference. Where THIS page documents the ARC protocol (Authenticated Received Chain, RFC 8617) — the per-hop cryptographic-seal chain trusted-forwarders emit (AAR + AMS + AS triplet per hop) to preserve the original-signer's authentication verdict across intermediary modifications (mailing-list footer insertion, Subject prefix mutation, header rewriting), the dkim_best_practices spoke is the CROSS-PROVIDER OPERATOR- HYGIENE canonical reference defining the key-cryptography + signing-hygiene invariants every ARC-deployed intermediary's per-sealer cryptographic identity inherits BYTE-FOR-BYTE per RFC 8617 §4 (the AMS and AS headers reuse the DKIM signing-algorithm + canonicalization + selector-namespace protocol primitives wholesale). FOUR structurally-distinct ARC-INHERITS-DKIM- HYGIENE dimensions the operator-hygiene spoke defines that this ARC protocol-layer page structurally consumes: (i) RFC 8301 2048-bit RSA key-size discipline AS THE PER-SEALER PUBLICATION INVARIANT every ARC-deployed intermediary inherits at the AS-seal cryptographic- identity layer — the dkim_best_practices spoke documents the 2048-bit-RSA floor as the cross- receiver weak-key-deprecation invariant; every ARC sealer (Google Workspace as ARC sealer on Gmail-forwarded mail, Microsoft 365 as ARC sealer on Exchange Online forwarded mail, mailing-list MTAs like Mailman 3 + Sympa as ARC sealers on list-forwarded mail) MUST publish per-sealer ≥2048-bit RSA SubjectPublicKey Info at the AS-seal selector (arc-<date>._domainkey.<sealer-domain> or equivalent per RFC 8617 §5); the ARC chain-verification at the downstream receiver explicitly applies the cross-receiver weak-key-deprecation invariant the operator-hygiene spoke catalogues at the AS-seal layer (Gmail's October-2024 1024-bit-rejection policy applies to AS-seal selectors AS WELL AS original-signer DKIM selectors); a sealer publishing <2048-bit RSA AS-seal keys produces ARC chain-verification failures at downstream Gmail/Yahoo receivers; (ii) RFC 6376 §3.6.1 k=rsa + h=sha256 signing-algorithm discipline AS THE PER-AMS / PER-AS algorithm-tag publication invariant every ARC sealer inherits — the dkim_best_practices spoke documents the RSA-SHA-256 receiver-canonical default; the ARC AMS and AS headers per RFC 8617 §4.1 reuse the DKIM a=rsa-sha256 signing-algorithm tag (with a=ed25519-sha256 per RFC 8463 as the next-generation alternative); every ARC sealer's per- hop AMS + AS publication MUST inherit the algorithm-tag discipline the operator-hygiene spoke defines (when ED25519 becomes the receiver-canonical AS-seal default in the future, every ARC-deployed intermediary's per-sealer cryptographic-identity rotation becomes an observability concern); (iii) per-selector custody- isolation discipline AS THE AS-SEAL SELECTOR-NAMESPACE INVARIANT forbidding selector-reuse across operator-distinct ARC sealers — the dkim_best_practices spoke documents the cross-signer custody- isolation discipline (one selector per signer-infrastructure instance; no selector-reuse across operator-distinct signers); the ARC sealer-side AS-seal selector inherits this custody- isolation invariant at the chain- verification level — every ARC chain a downstream receiver verifies traverses per-hop AS-seal selectors that MUST remain custody-distinct across operator- distinct intermediaries (Google's ARC-sealing selector ≠ Microsoft's ARC-sealing selector ≠ Mailman's ARC- sealing selector); custody-isolation is the chain-verification prerequisite for per-hop trust-attribution at the downstream receiver's ARC-evaluation boundary; (iv) RFC 6376 §3.6.1 overlap-window rotation discipline AS THE PER-SEALER ROTATION OPERATIONAL- INVARIANT every ARC-deployed intermediary inherits to preserve chain-verification continuity across per-sealer key-rotation cutover windows — the dkim_best_practices spoke documents the per-rotation overlap-window discipline (publish new selector ≥7 days before retiring the old; per- rotation per-receiver pass-rate monitoring); for the ARC sealer-side, this discipline translates to per- sealer overlap-window rotation (publish new AS-seal selector ≥7 days before retiring the old; per-rotation per-receiver ARC-chain-verification pass-rate monitoring), failure of which produces ARC chain-verification breaks at downstream receivers verifying messages sealed during the cutover window with the now-retired AS-seal selector. Read the dkim_best_practices spoke alongside this ARC-protocol page when authoring the per-sealer cryptographic-identity operational discipline an ARC-deployed organisation maintains — the operator- hygiene spoke is the load-bearing cross-sealer cryptographic-identity invariant reference every ARC AS-seal publication inherits BYTE-FOR-BYTE per RFC 8617 §4.
• BIMI Verified Mark Certificates (VMC and CMC) — the ARC-CHAIN-OF-CUSTODY-AS- DOWNSTREAM-RECEIVER-DMARC-PASS- RESCUE-PRIMITIVE-WHOSE-RESCUED-DMARC- PASS-VERDICT-UNLOCKS-BIMI-VMC- RENDERING-AT-RECEIVER-INBOX companion to this ARC RFC 8617 chain-of-custody reference. Where THIS page documents the receiver-side ARC-chain-validation algorithm whose cv=pass outcome rescues a legitimate forwarded message's pre-forwarder DMARC-pass verdict from receiver-side p=quarantine / p=reject enforcement when the second-hop SPF break or forwarder-mutation DKIM break would otherwise trigger false-positive enforcement, the BIMI-VMC/CMC spoke documents the DOWNSTREAM CONSUMER of the ARC-rescued DMARC-pass verdict at the receiver-side inbox-rendering layer. Concretely, the spoke documents FOUR ARC-vs-BIMI-VMC-interaction dimensions: (i) BIMI VMC rendering structurally requires DMARC-pass-with-enforcement-policy at the receiver — per BIMI Working Group Baseline Requirements §2.3 receiver-side rendering prerequisite, BIMI VMC rendering only fires when the receiver observes DMARC alignment-pass on the From:-aligned domain AND the publisher's policy is p=quarantine minimum (Yahoo / Apple Mail) or p=reject (Gmail) — a forwarded message whose first-hop DMARC verdict would otherwise be re-evaluated as fail at the receiver loses BIMI VMC rendering eligibility UNLESS the ARC chain-of-custody this page documents rescues the original DMARC-pass verdict; (ii) ARC-rescued DMARC-pass directly unlocks BIMI VMC rendering at receiver- side — the receiver-side ARC-chain-validation algorithm whose cv=pass outcome THIS page documents at the receiver-side acceptance boundary IS THE LOAD-BEARING primitive that preserves BIMI VMC rendering eligibility through the forwarder hop — without ARC, legitimate forwarded mail loses BIMI VMC rendering at the receiver inbox even though the publisher's VMC chain remains cryptographically valid; (iii) BIMI VMC chain verification is STRUCTURALLY SEPARATE from ARC chain verification but BOTH must succeed for BIMI rendering — the receiver-side verification stack performs (a) ARC-chain validation per RFC 8617 §5 (chain-validation algorithm, trusted-sealer list lookup, per-hop AAR / AMS / AS verification), then (b) BIMI VMC chain validation per BIMI WG BR §6.3 (X.509 chain-of-trust to BIMI-WG-approved CA root, certificate-validity-period check, trademark-binding-extension verification) — two STRUCTURALLY DISTINCT cryptographic-chain verification procedures the receiver MUST EXECUTE sequentially with both producing a pass outcome for BIMI VMC rendering to fire; and (iv) BIMI-WG-approved CA allow-list publication topology is STRUCTURALLY DISTINCT from ARC trusted-sealer list publication topology — the trusted-sealer list THIS page documents at the receiver-side ARC-chain- validation boundary is receiver- operator-curated and per- receiver-domain custom, while the BIMI-WG-approved CA allow-list the BIMI VMC chain verifies against is industry-standardised and centrally-published by the BIMI Working Group — a STRUCTURALLY DIFFERENT trust- anchor-rooting topology that nonetheless layers on the same receiver-side per-message verification stack the ARC chain-of-custody primitive feeds into. Read the BIMI-VMC/CMC spoke alongside THIS ARC reference when the publisher is SCALING the chain-of-custody protection infrastructure from ARC-only (forwarder-rescue primitive at the DMARC-verdict layer) to ARC + BIMI (forwarder- rescue primitive at DMARC-verdict layer PLUS trademark-attestation primitive at the receiver-inbox- rendering layer) — the spoke documents the downstream consumer of the ARC-rescued DMARC-pass verdict that materialises the publisher's brand-attestation rendering outcome at the receiver inbox.
• DKIM canonicalization explained (simple vs relaxed) — the byte-level header-and-body normalisation layer that ARC inherits verbatim from DKIM per RFC 8617 §4. Every ARC-Message-Signature (AMS) carries a c= tag pair (header-canon / body-canon) following the same RFC 6376 §3.4.1–§3.4.4 algorithm definitions: simple header canonicalization (verbatim bytes, fragile against any whitespace mangling) versus relaxed header canonicalization (collapses internal whitespace, strips trailing whitespace, lowercases field names per §3.4.2); simple body canonicalization (hashes the body verbatim, rejects ANY trailing-byte modification) versus relaxed body canonicalization (collapses internal whitespace, strips trailing whitespace, ignores trailing empty lines per §3.4.4). Canonicalization choice is the single most important variable for ARC-chain survival through mailing-list footer injection, Mailman MUNGE / non-MUNGE behaviour, Google-Groups footer rewriting, Discourse notification footer rewriting, and the whitespace-mangling MTAs that quietly invalidate body hashes — exactly the forwarding-induced breakage that motivated ARC's specification in the first place. Read the canonicalization page when designing your ARC-Sealer configuration: the c= tag defaults (recommended: relaxed/relaxed for forwarder-tolerance) are the difference between an ARC chain that survives the forwarder hop and one that breaks because the body hash mismatches after the forwarder's whitespace-mangling footer injection.
• DKIM cryptography basics — the cryptographic-foundation deep dive on the primitives ARC reuses. ARC-Message- Signature (AMS) and ARC-Seal (AS) are DKIM-style signatures with the same algorithm identifiers, the same hash functions (SHA-256 only — SHA-1 is deprecated by RFC 8301), the same key- publication mechanism (public key in DNS TXT under a selector subdomain), and the same canonicalization rules (header + body, simple or relaxed). RFC 8617 §4 explicitly inherits the DKIM signing pipeline. Understanding ARC's cryptographic posture therefore reduces to understanding DKIM's cryptographic posture — the same 2048-bit RSA minimum, the same Ed25519 (RFC 8463) migration path, the same SHA-256 hash requirement, the same 255-byte TXT-record limit, and the same body-hash-versus-header-signature separation that lets ARC detect body modifications by an in-path forwarder. Read once you understand the protocol on this page and need the cryptographic rationale for the algorithm and key-size choices ARC and DKIM share.
• BIMI explained — Brand Indicators. BIMI requires DMARC enforcement; ARC keeps that enforcement compatible with forwarding.
• BIMI SVG Tiny PS logo requirements — the ARC-FORWARDER-CHAIN-PRESERVATION- FOR-BIMI-LOGO-DISPLAY-ON-FORWARDED-MAIL companion reference. Where THIS page documents the ARC chain (AAR + AMS + AS triplet) the forwarder seals over the original SPF + DKIM + DMARC verdicts so the final receiver can recover the pre-forwarder authentication outcome via the arc=pass verdict, the BIMI-SVG-requirements spoke documents the OPERATIONAL-DOWNSTREAM-CONSUMER of that ARC chain-preservation work: the forwarder-preserved DMARC-pass verdict the ARC chain reconstructs at the final receiver is what UNLOCKS the BIMI display gate at the receiving MUA — and the SVG-byte-compliance gate documented on the requirements spoke is what determines whether unlocking the BIMI display gate actually produces a rendered brand logo or produces a silent no-render-because-SVG-invalid outcome. The implication: every ARC sealing operation a forwarder performs to preserve the original sender's DMARC-pass verdict through the forwarder hop is INVESTING in a downstream BIMI display outcome — and that investment evaporates if the SVG-byte-compliance gate this requirements spoke documents is not independently satisfied. Mail forwarded by an ARC-aware MLM expander / alumni-alias forwarder / vacation forward / corporate distribution list / .edu redirect arrives at the final receiver with the arc=pass verdict the receiver trusts, the original DMARC-pass verdict is reconstructed via the AAR header, and the BIMI display gate opens — but the brand logo only RENDERS if the SVG bytes served at the BIMI l= URL conform to the Tiny PS profile (no <script>, no <foreignObject>, no external refs, no animations, no embedded raster images, square viewBox, baseProfile attribute, title element, 32KB ceiling). Read the BIMI-SVG-requirements spoke alongside this page when scoping an ARC-forwarder-aware sending posture that also invests in BIMI display — every ARC-preserved DMARC-pass on a forwarded path is a BIMI display opportunity that the SVG-byte- compliance gate either capitalises on or wastes silently at the MUA rendering surface.
• MTA-STS explained — SMTP MTA Strict Transport Security (RFC 8461). Transport-encryption hardening sibling.
• MTA-STS policy-file byte syntax — the ARC-CHAIN-TRANSPORT-LAYER- AUTHENTICITY-AT-EACH-HOP-BOUNDED-BY-MTA- STS-POLICY-FILE-MX-ALLOW-LIST-BYTE- FORMAT companion to this ARC (RFC 8617) pillar. Where THIS page documents the ARC cryptographic-chain mechanism (per-hop AAR-AMS-AS triplet sealing the cumulative authentication-results trail at each forwarder boundary), the MTA- STS-policy-syntax spoke is the STRUCTURALLY-ORTHOGONAL TRANSPORT-LAYER POLICY-FILE BYTE-GRAMMAR REFERENCE documenting the per-hop transport- encryption-enforcement bytes that receiver-side MTAs consume at every ARC-chain hop. The ARC-PER-HOP-TRANSPORT- LAYER-AUTHENTICITY-VS-MTA-STS-POLICY- FILE-BYTE-GRAMMAR cross-reference establishes FIVE structurally-distinct per-byte-grammar-tag relevant ARC-chain interactions: (i) mode: enforce tag at each ARC-chain hop's receiver — the MTA-STS- policy-syntax spoke documents the mode: enforce bytes as the receiver-side STRICT STARTTLS commitment; when an ARC-chain hop's receiver has adopted the publisher's policy in mode: enforce, the STARTTLS-failing delivery from the upstream ARC-sealing forwarder will be REJECTED at the receiver — the AAR/AMS/ AS chain extension is NEVER created for that failed delivery, structurally bounding the ARC-chain growth to transport-authenticated hops only; (ii) mx: <hostname- glob> repeated lines at each receiver — the spoke documents the MX-host allow-list bytes whose per-glob enumeration structurally bounds the set of intermediary sealers a forwarder hop can deliver the AAR/AMS/AS extension through; an ARC-chain forwarder attempting delivery to an MX outside the allow-list cannot extend the chain at that hop; (iii) max_age: <seconds > policy-file freshness budget across long-running ARC chains — long ARC chains (4+ hops) traverse multiple receivers whose max_age: bytes determine per-receiver policy-cache lifetime; the spoke documents the byte-format whose tight maintenance ensures long-running ARC chains continuously encounter the most-current per-hop transport-encryption policy at each receiver; (iv) version: STSv1 protocol-version sentinel at each ARC-chain hop's receiver — the spoke documents the version- sentinel as the FIRST byte of the policy file; every ARC-chain hop's receiver is structurally a separate MTA-STS policy consumer that independently verifies the sentinel before applying the mx: allow-list; (v) cross-protocol complementarity with TLS-RPT reporting of intra-ARC- chain STARTTLS failures — when an ARC-chain hop's delivery fails due to STARTTLS rejection at an unauthorised MX, the receiver generates a TLS-RPT JSON report the publisher SOC consumes; the MTA-STS-policy-syntax spoke documents the publisher-side mx: allow-list discipline whose tight maintenance ensures the TLS-RPT stream surfaces every intra- ARC-chain transport-layer anomaly the ARC chain itself cannot observe. Pair this page (the ARC application-layer cryptographic-chain reference) with the MTA-STS-policy-syntax spoke (the transport-layer per-hop policy-file byte-grammar reference) when authoring a comprehensive per-hop authentication- and-transport-security posture review — the spoke documents the transport-layer policy-file bytes whose receiver-side enforcement structurally bounds the ARC-chain growth this page documents to transport-authenticated hops only.
• MTA-STS for Microsoft 365 — the M365-EXCHANGE-ONLINE-OUTBOUND- CONNECTOR-AND-HYBRID-EXCHANGE-RELAY-AND- CROSS-TENANT-CONNECTOR-AS-MULTI-HOP-ARC- CHAIN-INTERMEDIARY-SEALER-WHOSE-PER-HOP- STARTTLS-NEGOTIATION-OUTCOME-AT-MTA-STS- MX-ALLOW-LIST-BOUNDARY-DETERMINES- DOWNSTREAM-AS-SEAL-CHAIN-TRUSTWORTHINESS companion to this ARC (RFC 8617) pillar. Where THIS page documents the canonical ARC cryptographic-chain mechanism (the three-header AAR/AMS/AS chain, the per-hop instance numbering i=1, i=2, i=3 ..., the cv=pass/cv=fail /cv=none chain-validation status, the seal-signing algorithm receivers run to recover the upstream pre-forwarder authentication outcome at the application layer) — i.e. the APPLICATION-LAYER ARC-SEAL-CHAIN side of the multi-hop forwarding-survival infrastructure — the MTA-STS-for-Microsoft- 365 spoke is the M365-TENANT-SPECIFIC TRANSPORT-LAYER STARTTLS-ENFORCEMENT companion documenting the STRUCTURALLY- DISTINCT transport-layer surface a multi- hop ARC chain whose intermediary sealer is the M365 Exchange-Online infrastructure operates against: (i) the M365 outbound connector at the Exchange-Online- managed sender-side becomes an ARC sealer when re-emitting forwarded mail through the customer-vanity-domain.mail. protection.outlook.com outbound MX — at that ARC-chain hop, the M365 Exchange-Online infrastructure performs the per-hop STARTTLS negotiation against the receiver-side MX policy; if the receiver-side MX publishes mode:enforce MTA-STS with a public-PKI-signed cert chain, the Exchange-Online sealer respects the receiver's MTA-STS policy and constrains the STARTTLS handshake to MX hostnames in the receiver's allow-list; (ii) the M365 hybrid-Exchange relay topology (Exchange-Online routing through an on-premises Exchange Server back to the Internet) creates a TWO-HOP ARC chain where the on-premises Exchange Server is the i=1 sealer and the Exchange-Online connector is the i=2 sealer — at each hop the STARTTLS posture against the next-hop MX-allow-list determines whether the AS-seal chain remains downstream- trustworthy; an MTA-STS-enforced next-hop MX whose cert chain validates against the customer-vanity-domain CAA- authorized public-PKI roots produces an in-flight transport-layer auth chain that complements the application-layer AS-seal chain; (iii) the M365 cross-tenant connector (multi-tenant Exchange-Online deployments routing mail between two M365 tenants) creates an ARC sealing event at the tenant-to-tenant boundary — the spoke documents the per-tenant MTA-STS publication discipline (each tenant's mta-sts.<customer-vanity- domain> policy file controls the STARTTLS-enforcement posture at that tenant's MX boundary) — operationally relevant when the cv= chain- validation status this page documents surfaces multi-hop downgrade attempts at cross-tenant boundaries; (iv) the M365 Exchange-Online inbound MX (the customer-vanity-domain.mail .protection.outlook.com A-record- terminating host) is the LAST-HOP receiver for many ARC chains terminating at an M365 mailbox — at that terminal hop, the M365 tenant's own MTA-STS publication discipline determines whether external senders' final-hop STARTTLS negotiation respects the M365-tenant operator's transport-encryption floor; the spoke documents this terminal-hop posture, providing the operator with the M365-tenant-specific transport-layer-AS-seal-chain-terminating infrastructure picture this ARC pillar's application-layer chain-validation algorithm operates over. Read the MTA-STS- for-Microsoft-365 spoke alongside this ARC pillar when investigating ARC-chain validation outcomes for M365-Exchange- Online-mediated multi-hop forwarding paths — the M365-tenant-specific mta-sts.<customer-vanity- domain> publication topology the spoke documents is the load-bearing transport-layer companion to the application-layer AS-seal chain this page's cv= validation algorithm consumes.
• MTA-STS vs DANE — the ARC-CHAIN-PER-HOP-TRANSPORT-LAYER- INTEGRITY-AS-CROSS-LAYER-COMPANION reference. Where THIS page documents the APPLICATION-LAYER chain-of-custody primitive RFC 8617 ARC defines (the per-hop AAR / AMS / AS triple, the i= instance numbering, the cv= chain-validation tag, the trusted-sealer list semantics, the forwarder-hop integrity contract that rescues legitimate forwarded mail from the receiver-side p=reject enforcement decision), the MTA-STS-vs-DANE spoke documents the TRANSPORT-LAYER protocol-choice the operator MUST resolve at EACH forwarder hop the ARC chain crosses — the two protocols operate at orthogonal layers BUT compose in the per-hop defense-in-depth posture across FOUR cross-layer composition patterns: (i) per-hop coverage matrix — the ARC application-layer authentication-result chain-of-custody is COMPLEMENTED by the transport-layer MTA-STS or DANE enforcement at each hop's STARTTLS negotiation boundary; an attacker who STRIPS STARTTLS at a forwarder hop without transport-layer enforcement compromises BOTH the AS-seal trust AND the per-hop authenticity guarantee the ARC chain claims to preserve; (ii) DNSSEC vs PKIX trust-anchor composition — every forwarder hop on the ARC chain operates a transport- layer trust-anchor that is EITHER DNSSEC-backed (DANE TLSA-record fingerprint) OR PKIX-backed (MTA-STS certificate-validation); the ARC chain's trusted-sealer list composition must account for the per-hop trust-anchor variation when evaluating downstream-trustworthiness; (iii) per-receiver-population coverage symmetry — both ARC and MTA-STS / DANE have non-uniform receiver-side enforcement (Gmail, Microsoft 365, Yahoo, German / Dutch ISPs each implement ARC and transport-security enforcement at structurally-different depths); the operator's per-protocol coverage matrix for transport-security must be reconciled with the per-protocol coverage matrix for ARC application-layer trust to produce a complete per-hop defense-in-depth posture; (iv) TLS-RPT failure-type cross-layer correlation — the TLS-RPT JSON failure-types (sts-policy-fetch-error, sts-webpki-invalid, tlsa-invalid, certificate-host-mismatch, starttls-not-supported) surface transport-layer failures at the SAME forwarder-hop boundary the ARC chain's per-hop AAR / AMS / AS triple attests authentication-result preservation across — the two failure streams must be reconciled at the same hop-boundary when a forwarder's downstream chain produces ARC cv=fail events whose upstream root cause is a transport- layer STARTTLS handshake failure. Read the MTA-STS-vs-DANE spoke alongside this ARC pillar when scoping the per-hop defense-in-depth posture across an ARC-chained forwarder topology — the transport-security protocol choice is the CROSS-LAYER companion to the ARC application-layer chain-of-custody at every forwarder hop the chain crosses, and the operator must reconcile BOTH layers' per-protocol coverage matrices for a complete per-hop authenticity-and- integrity guarantee.
• DANE for SMTP — the DANE-PER-HOP-TRANSPORT-LAYER- CHAIN-OF-CUSTODY-PARALLEL-TO-ARC- APPLICATION-LAYER-CHAIN-OF-CUSTODY companion documenting the DNSSEC- anchored TLSA-validation mechanism that operates AT EACH ARC-chain intermediary hop as the DNSSEC-trust-model alternative to the X.509-PKI-trust-model MTA-STS provides for the same per-hop transport- layer integrity boundary the ARC application-layer chain-of-custody crosses at every forwarder hop. Documents FOUR per-hop DANE-parallelism dimensions (the DANE TLSA record at _25._tcp.<intermediary-MX> owner-name in a DNSSEC-signed zone provides cryptographic identity-binding evidence the next-hop forwarder validates BEFORE STARTTLS handshake — the per-hop validation is parallel to the ARC AAR/ AMS/AS application-layer signature the next-hop forwarder validates BEFORE DKIM-pass attribution; the DANE TLSA- chain trust-root anchor is the per-zone DNSSEC signing-key chain rooted at the IANA root-zone trust anchor — STRUCTURALLY DISTINCT from the MTA-STS X.509-PKI Web-PKI trust-root anchor rooted at the operating-system root-CA store, providing an INDEPENDENT trust-anchor option for operators whose DNS-zone-signing infrastructure is mature but whose Web- PKI-CA dependency they prefer to avoid; DANE TLSA validation at each ARC-chain intermediary hop binds the per-hop STARTTLS-served X.509 cert to a DNSSEC- published TLSA hash — when an ARC-chain intermediary forwarder hop fails DANE validation, the receiver-side enforcement DROPS the message at the transport-layer BEFORE the next-hop forwarder can extend the AAR/AMS/AS chain, providing TRANSPORT- LAYER chain-of-custody termination at the failing-hop boundary parallel to the application-layer chain-of-custody the ARC cv=fail verdict provides; DANE TLSA per-hop validation outcomes are observable via the per-hop TLS-RPT JSON aggregate-report result-type enumeration (dane-required, tlsa-invalid, dnssec-invalid) providing per-hop DANE evidence stream the operator cross-references with per-hop ARC AAR/AMS/AS chain-validation outcomes for combined transport-layer plus application-layer per-hop authenticity- and-integrity observability). Read the DANE explainer spoke alongside the MTA-STS-vs-DANE decision-tree spoke when authoring multi-forwarder-hop topology operational documentation whose per-hop transport-layer integrity must combine with the per-hop ARC application-layer chain-of-custody THIS page documents — the DANE spoke documents the DNSSEC-trust-model half of the per-hop transport-layer integrity evidence the ARC-chain operator consumes.
• TLS-RPT explained — SMTP TLS Reporting (RFC 8460). Transport-layer reporting stream sibling.
• CAA records explained — Certification Authority Authorization (RFC 8659). The TLS-cert-issuance constraint sibling.
• Reverse DNS / PTR records for mail servers — the INTERMEDIARY-SEALER-IP-IDENTITY companion documenting the IN-ADDR.ARPA / IP6.ARPA reverse-zone PTR record discipline whose FCrDNS (Forward-Confirmed reverse DNS) verification operates as the IP-IDENTITY- LAYER prerequisite every ARC sealer's connecting-IP must satisfy for downstream receivers to trust the AS-seal chain. Where THIS page documents the ARC cryptographic chain mechanism (the three-header AAR / AMS / AS chain, the per-hop instance numbering, the cv=pass/cv=fail/cv=none chain-validation status, the seal-signing algorithm receivers run to recover the upstream pre-forwarder authentication outcome), the reverse-DNS-PTR spoke is the IP-IDENTITY-LAYER companion documenting the sealer's CONNECTING-IP discipline at the forwarder hop where the seal is generated. The four-axis ARC-SEALER-VS-FCrDNS-DISCIPLINE comparison exposes the structurally-distinct INTERMEDIARY-SEALER-IP-IDENTITY roles: (i) ARC sealers must have their own DKIM-aligned-with-DMARC posture, AND their own FCrDNS-aligned connecting-IP posture — both message-identity- layer (DKIM) AND IP-identity-layer (FCrDNS) identity layers are required; (ii) a misconfigured mailing-list / forwarder without FCrDNS-aligned IPs cannot produce trustworthy ARC seals because the downstream-receiver's spam-classifier scores the sealer's IP-identity as suspect and may DOWNWEIGHT the seal even when it cryptographically validates; (iii) operators receiving inbound mail through an ARC-aware spam filter (Proofpoint, Mimecast, Barracuda, in-house BCC-forwarder) MUST ensure the spam-filter's outbound IPs have PTR records pointing back to a forward-A-record that resolves to the same IP — without this, the chain's seal-IP-identity is unverified at the receiver-side; (iv) operators deploying ARC at the receiver MUST consume the seal's i= instance-numbered sealer-d= identity AND cross-reference the connecting-IP against the sealer's published FCrDNS for the chain to be operationally trustworthy beyond pure- cryptographic-validity. Read the reverse- DNS-PTR spoke when scoping the IP-identity- layer prerequisites that ARC-sealing infrastructure relies on but the ARC protocol spec does not document directly.
• MX records explained — the ARC-FORWARDER-MX-NEXT-HOP-DELEGATION- CHAIN-FOR-TRANSITIVE-RELAY-AUTHENTICATION companion documenting the receiver-side authoritative MX record (RFC 5321 §5.1 + RFC 7505 null-MX) every ARC-sealing forwarder hop must resolve to locate the next-hop SMTP receive endpoint at which the next AAR / AMS / AS instance in the chain will be sealed and delivered. Where THIS page documents the cryptographic ARC chain mechanism (the three- header AAR / AMS / AS chain, the per-hop instance numbering, the cv=pass/cv=fail/cv=none chain-validation status, the seal-signing algorithm receivers run to recover the upstream pre-forwarder authentication outcome), the MX-records spoke is the TRANSPORT-RESOLUTION-LAYER companion documenting the authoritative-DNS object every chain-hop step depends on for next-hop delivery. The four-axis ARC-CHAIN-VS-MX-RECORD comparison exposes the structurally-distinct FORWARDER-HOP-NEXT-RECEIVER-MX-DELEGATION roles: (i) every ARC-sealing forwarder hop performs an MX lookup on the recipient domain to discover the next-hop SMTP receiver before extending the chain — without a publishable MX record (or implicit-MX A/AAAA fallback), the chain cannot be extended because there is no next-hop receiver to deliver the sealed message to; (ii) null-MX publication (0 . per RFC 7505) signals "this domain accepts no mail" and TERMINATES the ARC chain at the upstream sealer because the forwarder cannot relay to a domain that explicitly refuses mail — the chain extension stops, the cv= chain-validity outcome cannot propagate further, and the receiver-side authentication recovery is bounded by the last successful hop's seal; (iii) multi-MX publication with priority-ordered preference produces a structurally-distinct ARC-chain topology because each MX priority value represents a different forwarder-next-hop candidate — when the highest-priority MX is unreachable and a lower-priority MX is used as fallback, the next-hop chain-extension is sealed against the actual delivery target's identity, not the originally-resolved highest-priority target — which can produce instance-numbered AAR entries from unexpected sealers in the eventual recipient's Authentication-Results header; (iv) MX-takeover or Punycode-confusable-MX-delegation attacks against the recipient domain redirect the ARC-sealing forwarder's next-hop to an attacker-controlled receiver — the sealer cannot detect this at the SMTP layer because the MX-resolved IP is treated as authoritative; the attack is only visible at the upstream-DNSSEC-aware resolver layer or through cross-resolver-comparison auditing. Read the MX-records spoke when scoping the DNS-publication prerequisites every ARC-sealing forwarder relies on but the ARC chain protocol spec does not document directly, and when investigating ARC chains that terminate unexpectedly at a hop or produce unexpected sealer-d= identities in the final-receiver's Authentication-Results header.
• Email deliverability — the cluster-spanning operational reference for the inbox-placement outcome ARC preserves across forwarding hops — the operational deep dive on the deliverability outcome ARC was engineered to preserve across forwarding hops. Where this page documents the ARC protocol itself (the three per-message ARC-Authentication-Results / ARC-Message-Signature / ARC-Seal headers, the i= instance counter, the cv=none/pass/fail chain validation algorithm, the Trusted ARC Sealers configured at receivers like Defender for Office 365 via Set-ArcConfig and Gmail's published-sealer-list mechanism), the deliverability spoke documents the OUTCOME the protocol exists to protect: inbox placement for legitimately- forwarded mail that would otherwise lose its original SPF / DKIM / DMARC pass verdicts at the forwarder boundary and get scored as unauthenticated mail by the downstream receiver. RFC 8617 §1 identifies forwarding-induced authentication-loss as THE motivating scenario for ARC's existence — the protocol's entire trust model exists because the deliverability outcome for forwarded mail (mailing lists, corporate distribution lists, shared mailbox forwarders, third-party forwarders like SaaS support-ticket relays) was unrecoverable under plain DMARC. Read the deliverability spoke when calibrating the forwarding- scenario portion of the deliverability framework ("which forwarder topologies require ARC-aware receiver configuration for deliverability preservation", "what is the deliverability impact of a forwarder that does NOT participate in ARC sealing", "how does ARC interact with the engagement-reputation reputation sub-score at Gmail and M365") — the spoke is the authoritative cluster-spanning operational reference for the deliverability business outcome the ARC protocol is engineered to preserve across forwarding hops. Where the protocol primer on this page documents the HOW (cryptographic chain construction, per-hop sealer behaviour, validation algorithm), the deliverability spoke documents the WHY (the receiver-side inbox- placement business outcome the chain preserves) — read both pages together when stakeholders ask "what is ARC for" or "which forwarding scenarios benefit from ARC sealing".
• DMARC for Hybrid Exchange (on-prem + M365) — the hybrid-topology deep dive where ARC becomes operationally critical. Defender for Office 365 Trusted ARC Sealers (configured via the Set-ArcConfig PowerShell cmdlet) is specifically a hybrid-Exchange feature: ARC sealing across the on-prem- to-cloud relay preserves the original SPF / DKIM / DMARC results when the message crosses the Edge Transport boundary between on-premises Exchange and Exchange Online. Read once you understand the protocol on this page and need the operational deployment pattern for hybrid topologies — the page documents the dual-signer DKIM problem, Send Connector relay loops, and the Centralized Mail Transport (CMT) migration that ARC sealing makes safe.
• DMARC for transactional email — the ARC-CHAIN-PRESERVATION-OF- TRANSACTIONAL-ESP-EGRESSED-MAIL-FORWARDED- THROUGH-RECIPIENT-MAILBOX-RULE-AUTO- FORWARDERS-AND-MAILING-LIST-INTERMEDIARIES companion documenting the per-ESP transactional-sender deployment whose egressed mail (password resets, receipts, shipping notifications, MFA codes, account-action confirmations from SendGrid / Mailgun / Amazon SES / Postmark / SparkPost / MailChimp Transactional) is the canonical highest-volume incidence cohort for ARC's recipient-side trust-restoration mechanic. Where THIS page documents the ARC protocol primitives (the AAR i=N ARC-Authentication-Results header capturing the first hop's Authentication-Results verdict, the AMS i=N ARC-Message-Signature cryptographically signing the message state at each forwarder, the AS i=N ARC-Seal binding the chain itself), the DMARC-for-transactional-email spoke is the OPERATOR-FACING per-ESP deployment companion documenting WHY ARC matters for transactional senders specifically. The four-axis ARC-VS-TRANSACTIONAL-ESP comparison exposes the structurally- distinct ARC-CHAIN-PRESERVATION roles: (i) transactional ESP-egressed mail is the dominant cohort that recipients configure auto-forwarding rules for — recipients configure Gmail "Forwarding and POP/ IMAP" / Outlook server-side rules / corporate-to-personal vacation forwarders / university-alumni permanent-forward aliases primarily FOR notifications and receipts (the canonical transactional-mail content), meaning SPF-aligned-fail rows in RUA from transactional-sender domains are most commonly attributable to recipient-side auto-forwarding loss rather than spoofing — ARC chain preservation lets receivers re-evaluate the original message-identity verdict and override the second-hop SPF-fail; (ii) transactional ESPs route through mailing-list intermediaries more often than promotional ESPs — distribution-list recipients receive transactional notifications via Mailman / Sympa / Google Groups intermediaries that modify Subject and body headers (breaking original DKIM signatures), making the AMS-signed-message-state-at-each-hop property documented on this ARC page the load-bearing rescue mechanism for the transactional-ESP-customer's DMARC-aligned-pass rate; (iii) transactional-ESP-egressed mail has the highest auto-forwarding-rate of any mail class — the receive-side mailbox-rule auto- forwarding scenario this ARC primer engineers around is the dominant deliverability-degradation mode for transactional ESP-egressed mail because transactional mail is precisely the mail class recipients aggressively configure forwarding rules for; (iv) transactional ESPs operate on shared egress IP pools where ARC chain integrity becomes a per-customer-domain reputation-isolation primitive — the DMARC-for-transactional-email spoke documents the per-customer- domain ARC-chain inspection patterns operators use to disambiguate forwarder-induced SPF-fail (legitimate mail, preserve via ARC-aware receivers) from actual-spoofing- attempts (block via DMARC reject), a triage discipline the ARC chain documented on this primer page makes operationally tractable.
• DMARC for shared hosting — the ARC-CHAIN-PRESERVATION-OF-SHARED- HOSTING-TENANT-CUSTOMER-DOMAIN-EGRESSED- MAIL-FORWARDED-THROUGH-CPANEL-FORWARDERS- PLESK-MAIL-ALIASES-DIRECTADMIN-FORWARDS- ISPCONFIG-FORWARDS-AND-CROSS-TENANT- INTERNAL-RELAY-CHAINS companion to this ARC protocol primer. Where THIS page documents the ARC chain construction (AAR[i] / AMS[i] / AS[i] triplet at each forwarder hop) and the recipient-side trust-restoration mechanic ARC-aware receivers (Gmail, Microsoft 365, FastMail, Yahoo, Comcast/Xfinity Mail) apply on the second hop after the first hop's SPF verdict has been broken by forwarding, the shared-hosting spoke is the SHARED-HOSTING-FORWARDER-LOSS-COHORT companion documenting the FOUR distinct shared-hosting-specific forwarder-chain- break patterns the ARC chain rescues: (i) cPanel "Forwarders" panel per-tenant aliasing — the canonical "info@tenant-domain.tld → operator@gmail.com" / "support@tenant- domain.tld → ticketing-system@helpdesk- provider.com" forwarder pattern cPanel tenants configure via the "Email → Forwarders" UI, breaking SPF at the cPanel-MX-egress boundary because the envelope-MAIL-FROM stays the original sender's domain while the egress IP becomes the cPanel-hoster's shared MX pool IP that is NOT authorized for the original sender's SPF record; (ii) Plesk "Mail Aliases" tenant forwarders — the same pattern applies to Plesk's per-domain Mail Aliases configured via "Mail → $domain.tld → Mail Settings" panel, with the Plesk-MX-egress-IP-pool acting as the second-hop egress that breaks the original sender's SPF authorization; (iii) DirectAdmin "Forwarders" and ISPConfig "Email Forwards" — DirectAdmin's per-user "Forwarders" wizard and ISPConfig's "Email Mailbox → Custom Rules → Forward To" panel produce identical structural SPF break at the respective hoster MX-egress; and (iv) cross-tenant internal relay chains — shared-hosting operators frequently configure WHM-level "Email Routing → Local Mail Exchanger" rules and Plesk-level "Mail Server Settings → Relay Settings" that internally route mail between tenants on the same physical host before final egress, producing a multi-hop forwarder chain the ARC sealer must transcribe at each WHM/Plesk-internal-relay-hop AAR[i] position to preserve the original tenant's identity verdict. The shared- hosting spoke documents the per-control- panel ARC sealing readiness audit (cPanel's Exim ARC plugin status, Plesk's Postfix ARC milter availability, DirectAdmin's Exim/Dovecot ARC config, ISPConfig's Amavisd ARC integration), the per-control-panel auto-forwarder inventory pipeline (the canonical "list all tenants' configured forwarders to external mailbox providers" audit operators must run before p=reject rollout), and the multi-tenant aggregate- report cross-correlation discipline operators use to disambiguate shared- hosting-tenant-forwarder-loss from actual-spoofing of the tenant's domain at the cPanel-MX-egress boundary - a triage discipline ARC chain inspection makes operationally tractable for the shared-hosting persona just as ARC rescues transactional-ESP-egressed mail documented in the adjacent transactional- email spoke.
• SPF permerror vs temperror — the ARC-CHAIN-PRESERVATION-OF-SPF- VERDICT-INCLUDING-PERMERROR companion to this ARC protocol primer. Where THIS page documents the ARC chain construction (the i=1..N ARC-Authentication-Results header capturing the first hop's verdict, the i=2..N ARC-Message-Signature signing the ORIGINAL message-state at each forwarder, the i=2..N ARC-Seal binding the chain itself), the permerror-vs-temperror spoke is the SPF-VERDICT-CATALOGUE companion documenting the FOUR distinct receiver-side SPF outcomes the ARC sealer must faithfully transcribe into AAR[i] at sealing time: (i) permerror — permanent over-budget or malformed-record failure that the first-hop receiver records and the ARC sealer at hop i=1 cryptographically commits to in arc=pass with spf=permerror inside AAR[1]; downstream receivers consulting the ARC chain see the permerror as a pre-forwarding condition, not a forwarder-introduced artifact; (ii) temperror — transient DNS failure at the first-hop receiver that the ARC sealer also commits; downstream receivers see spf=temperror in AAR[1] and may defer-vs-retry accordingly per their DMARC engine's temperror handling; (iii) pass — the canonical success outcome the ARC chain preserves so a downstream receiver after multiple forwarder hops can see the ORIGINAL first-hop-receiver's spf=pass verdict even when the connecting client IP at the FINAL receiver is the forwarder's IP not the original sender's; (iv) fail — the canonical failure outcome the ARC chain ALSO preserves, allowing downstream receivers to distinguish between an originally-failed SPF (legitimate fail at first hop preserved through ARC) vs a forwarder-introduced SPF break (would surface only at the downstream receiver, not in AAR[1]). Read the permerror-vs-temperror spoke alongside this page when debugging an ARC-chain validation scenario where the downstream receiver's arc=pass verdict surfaces a non-pass spf= outcome inside AAR[1] and the operator needs the receiver-side SPF outcome catalogue to interpret what the first-hop receiver actually saw before the forwarder chain began.
• DKIM-Signature header tag anatomy — the ARC-MESSAGE-SIGNATURE-AMS- MIRRORS-DKIM-SIGNATURE-TAG-STRUCTURE companion reference. Where THIS page documents the ARC PROTOCOL itself (the i=1..N ARC-Authentication-Results AAR header capturing each hop's verdict, the i=1..N ARC-Message- Signature AMS signing the original message-state at each forwarder, the i=1..N ARC-Seal AS binding the chain itself per RFC 8617, the cv= chain- validation outcome, the receiver-side chain-validation algorithm), the signatures-explained spoke is the FIELD-LEVEL CANONICAL REFERENCE for the DKIM-Signature header tag anatomy that AMS structurally INHERITS: the AMS header carries the same a= algorithm, b= signature bytes, bh= body hash, c= canonicalization, d= signing domain, h= signed-header-list, and s= selector tags as DKIM-Signature (RFC 8617 §4.1.1 explicitly defines AMS as adopting DKIM-Signature's tag syntax) plus the ARC-specific i= hop- instance qualifier marking which ARC hop produced this AMS. Understanding the DKIM-Signature tag anatomy is therefore PREREQUISITE to interpreting AMS headers across a multi-hop ARC chain — the signatures-explained spoke gives the per-tag canonical reference for the underlying DKIM-Signature anatomy, this page extends that anatomy to the per-hop ARC chain context (AMS[1], AMS[2], AMS[3] each re-emit the same tag structure with per-hop b= signature bytes computed against the per-hop modifications the forwarder applied). Read the signatures-explained spoke alongside this page when debugging an ARC chain validation scenario where the receiver's cv=pass verdict requires the operator to trace each AMS hop's tag values against the upstream DKIM-Signature original.
• DMARC forensic reports (RUF) — the ARC-CHAIN-PRESERVED-IN-RUF- FORENSIC-CAPTURE-ENABLING-FORWARDER- CHAIN-OF-CUSTODY-INVESTIGATION companion reference. Where THIS page documents the ARC PROTOCOL itself (the i=1..N AAR header capturing each hop's verdict, the i=1..N AMS header signing each hop's message state, the i=1..N AS header binding the chain itself, the cv= chain-validation outcome, the receiver-side validation algorithm), the forensic-reports spoke is the EVIDENCE-CAPTURE companion documenting how the ARC chain is PRESERVED in the per-message RUF forensic samples that ARF-format- emitting receivers send when ruf= mailbox is configured. Each RUF sample captures the FULL message headers (not just the From: / Authentication-Results headers RUA aggregate counts reference) — and the full message headers include the complete ARC chain stack: AAR[1], AMS[1], AS[1] at the first hop; AAR[2], AMS[2], AS[2] at the second hop; ... AAR[N], AMS[N], AS[N] at the final hop where the receiver detected DMARC failure and emitted the RUF sample. This forensic ARC-chain preservation enables the investigator to answer questions impossible to resolve from RUA alone: WHICH hop introduced the DMARC-failing modification (was it the original sender's malformation, a misbehaving forwarder that broke the DKIM body hash by appending a mailing-list footer, or an attacker re-injecting at hop N with a forged ARC seal)? WHAT was the AAR[i] verdict-chain trajectory across the hops (did spf=pass at hop 1 become spf=fail at hop N because the connecting IP changed)? WHO signed the AMS[i] headers (the chain of custody for each preserved-message- state signature)? Read the forensic-reports spoke alongside this page when investigating an ARC- chain validation incident — this page gives the protocol mechanics, the forensic-reports spoke gives the EVIDENCE-CAPTURE protocol surfacing the ARC chain at investigation time.
• DKIM for Microsoft 365 — the ARC-CHAIN-PRESERVATION-OF-M365- TENANT-DKIM-SIGNATURE-AT-EXCHANGE- ONLINE-PROTECTION-RECEIVE-RELAY- MODIFICATION-BOUNDARY companion reference. Where THIS page documents the ARC protocol mechanics (the AAR[i] Authentication-Results snapshot, the AMS[i] message-state signature, the AS[i] chain-binding signature applied at each forwarder hop, the cv=pass/fail/none chain- validation outcome, Set-ArcConfig trusted-sealer configuration), the DKIM-for-Microsoft-365 spoke documents the EXCHANGE-ONLINE-TENANT- SPECIFIC DKIM signature whose original integrity the ARC chain preserves through any EOP-receive- side modification — when a message signed at M365 egress with the tenant's selector1._domainkey signature is received by another M365 tenant whose EOP applies subject-line external-warning prefixes, footer injection, attachment-link rewrites, or transport-rule body modifications, the original M365-tenant DKIM signature would fail re-verification but the ARC chain at the EOP receive boundary preserves the AMS[i] signature over the original message state plus the AAR[i] documenting the original dkim=pass verdict. Read the M365-DKIM spoke alongside this page when investigating an ARC-chain incident involving M365 tenant-to-tenant or M365-to-Workspace forwarding — the M365 selector1/ selector2 CNAME publication mechanics are what produce the ORIGINAL DKIM signature whose preservation is the cv=pass-justifying load the ARC chain carries.
• DKIM for Google Workspace — the ARC-CHAIN-PRESERVATION-OF- WORKSPACE-TENANT-DKIM-SIGNATURE-AT- GMAIL-AND-WORKSPACE-RECEIVE-MODIFICATION- BOUNDARY companion reference. Where THIS page documents the ARC protocol mechanics (the AAR[i] Authentication- Results snapshot, the AMS[i] message-state signature, the AS[i] chain-binding signature applied at each forwarder hop, the cv=pass/fail/none chain-validation outcome, Set-ArcConfig trusted-sealer configuration), the DKIM-for-Google-Workspace spoke documents the WORKSPACE-TENANT-SPECIFIC DKIM signature whose original integrity the ARC chain preserves through any Gmail / Workspace receive-side modification — when a message signed at Workspace egress with the tenant's operator-published <selector>._domainkey TXT-record signature (typically google._domainkey or a rotation-aware selector) is received by a Gmail-hosted mailing list whose relay applies a subject-prefix modification or a List-Unsubscribe header rewrite, OR by another Workspace tenant whose content compliance rule applies a footer- injection / attachment-link rewrite / body-text DLP redaction modification, the original Workspace-tenant DKIM signature would fail re-verification — but the ARC chain applied at the receive boundary preserves the AMS[i] signature over the original message state plus the AAR[i] documenting the original dkim=pass verdict with d=<tenant-domain>. Read the Workspace-DKIM spoke alongside this page when investigating an ARC-chain incident involving Workspace tenant- to-tenant or Workspace-to-M365 forwarding — the Workspace operator-published TXT-record DKIM mechanics (manual single-selector rotation, 255-byte TXT-chunk concatenation, operator-controlled key custody) are what produce the ORIGINAL DKIM signature whose preservation is the cv=pass-justifying load the ARC chain carries — distinct from M365's CNAME-delegation tenant-managed key model in that the Workspace key custody rests with the operator, so original- signature provenance for ARC investigations traces to the operator's own key-rotation log rather than Microsoft's tenant-key-rotation log.
• DMARC for SaaS senders — the MULTI-TENANT-PLATFORM-AS-ARC-CHAIN-INTERMEDIARY-SEALER-PRESERVING-CUSTOMER-DOMAIN-DKIM-ALIGNMENT-THROUGH-PLATFORM-RELAY-HOP companion to this ARC-explained RFC 8617 sealing-and-verification reference. Where THIS page documents the ARC sealing algorithm at the cryptographic level (the per-hop ARC-Authentication-Results: / ARC-Message-Signature: / ARC-Seal: header triplet, the per-hop instance-number-bounded i=N chain-ordering tag, the cv=none/pass/fail chain- validity-summary tag-semantics, and the intermediate-handler-sealer cryptographic-signing-key publication at <selector>._domainkey.<sealer-domain>), the DMARC-for-SaaS-senders deployment spoke documents the canonical multi- tenant SaaS-platform topology where the SaaS platform is itself a STRUCTURALLY- DISTINCT ARC-chain intermediate-sealer. The SaaS-senders spoke documents the per-platform ARC-sealing-publication responsibility (the platform must publish its OWN <selector>._domainkey.<platform>.com ARC-sealing key in addition to any customer-delegated DKIM signing keys), the per-platform ARC-chain-hop-position consideration (the platform sits between the original customer-domain author and the downstream receiver, so its i=1 ARC instance must seal the original-customer-domain dkim=pass / spf=pass Authentication-Results that the original author produced, with the cv=none tag indicating the platform is the FIRST sealer in the chain), and the per-platform receiver- trust-anchor selection where major receivers maintain ALLOWLISTS of trusted ARC-sealing-platforms whose cv=pass verdicts are honoured to override SPF-broken-by- forwarding alignment failures. The SaaS-senders spoke is the canonical operational reference for the SaaS-platform-as-ARC-sealing-intermediary RUA-row pattern (a customer-domain outbound message traverses the SaaS- platform hop, ARC-sealed by the platform with cv=pass at the receiver, producing a DMARC-pass at the receiver despite SPF failing for the SaaS-platform-IP-not- authorised-in-customer-domain-SPF condition) and the per-platform ARC-trust-anchor-deployment cookbook the operator follows to verify the platform's ARC-sealing-key is honored by major receivers. Read the SaaS-senders spoke alongside this page when designing the ARC-deployment strategy for a multi- tenant platform that relays customer- domain mail — the ARC sealing-and- verification algorithm documented here is the same in customer-direct-author and SaaS-platform-relay contexts, but the SaaS-platform-as-intermediate-sealer topology is the load-bearing operational decision the SaaS-senders spoke documents.
• TLS-RPT record syntax deep dive — the FORWARDER-HOP-TRANSPORT- LAYER-FAILURE-OBSERVABILITY- COMPANION reference. Where THIS page documents the ARC (RFC 8617) per-hop message-authentication- result attestation chain (ARC-Authentication-Results, ARC-Message-Signature, ARC-Seal) that forwarders write to preserve the message-layer SPF/DKIM/DMARC outcomes a downstream receiver can evaluate as if the originating IP had connected directly, the TLS-RPT record-syntax spoke is the authoritative reference for the ORTHOGONAL TRANSPORT-LAYER OBSERVABILITY surface that watches what happens BELOW the message-authentication layer the ARC chain attests across. ARC and TLS-RPT operate on STRUCTURALLY-ORTHOGONAL layers of the email-forwarding stack — ARC on the MESSAGE-LAYER per-hop authentication-result attestation (preserving the SPF/DKIM/DMARC verdict the originating receiver would have computed before the forwarder rewrote envelopes), TLS-RPT on the SMTP-TRANSPORT- LAYER per-hop TLS-handshake-and- policy-compliance reporting (the receiver-side tls.connection-success, tls.certificate-expired, sts.policy.invalid, sts.webpki-invalid per-day rollups that arrive at the publisher's _smtp._tls.<domain> TXT-record-declared rua=mailto: / rua=https: endpoint). Forwarder-mediated mail flows depend on BOTH layers holding for a downstream receiver to deliver the message: ARC must preserve the message- authentication verdict successfully (otherwise downstream DMARC alignment fails and the receiver can bounce / quarantine), AND the forwarder-to-downstream- receiver SMTP hop must complete the TLS handshake successfully (otherwise the message never arrives — silent drop / STARTTLS- downgrade / certificate- validation-failure all manifest as TLS-RPT failure-details JSON records). The publisher-side TLS-RPT record-syntax spoke documents the v=TLSRPTv1 version-tag (mandatory first), the rua=mailto: and rua=https: report-recipient endpoint forms (multiple comma-separated), the trailing ; semicolon separator semantics (terminator not separator per RFC 8460 §3.2), the absence-of-p= policy-tag (TLS-RPT has no publisher-side enforcement policy, unlike DMARC's p=reject / SPF's -all — it is a pure observability mechanism), and the canonical record-publication-pre-MTA-STS- deployment ordering (publish TLS-RPT FIRST as a 1-week baseline observability tier BEFORE publishing the MTA-STS policy file with mode: testing → mode: enforce transition). Read the TLS-RPT record-syntax spoke alongside this ARC page when authoring the full forwarder-mediated mail-flow observability runbook for a publisher whose senders traverse mailing-list forwarders, account-alias forwarders, intermediate-relay forwarders, or third-party bulk-mail-forwarder gateways — ARC handles the message-authentication attestation layer, TLS-RPT handles the transport- encryption-and-policy- compliance layer, and joint-deployment is the defensible posture for any publisher whose mail traverses forwarder hops at non-trivial rate.
• DMARC deployment checklist — the FORWARDER-POPULATION-ENUMERATION- AS-CHECKLIST-PRECONDITION reference. Where THIS page documents the ARC (Authenticated Received Chain, RFC 8617) protocol that preserves SPF/DKIM/DMARC verdicts across forwarder rewriting via per-hop AAR / AMS / AS header attestation, the deployment-checklist spoke is the canonical staged-rollout runbook every publisher follows from monitoring-only p=none through p=quarantine with low pct= to enforcement p=reject. The deployment-checklist spoke's pre-flip steps INCLUDE the forwarder-population enumeration step at which ARC posture must be inventoried: (i) identify which downstream mailing-list / .edu / .gov / per-team alias forwarders the publisher's legitimate-recipient population uses; (ii) probe each forwarder for ARC-signing capability via test-message round-trips with controlled SPF-fail conditions (test-rig sends a message from a non-aligned sender, traverses the forwarder, lands at an ARC-aware recipient — the recipient's Authentication- Results header reveals whether the forwarder added ARC-Seal / ARC-Message- Signature / ARC-Authentication-Results headers); (iii) document the receiver- side ARC-trust-set the publisher relies on (Gmail / Microsoft / Yahoo / Fastmail — each operates a per-sealer trust decision); (iv) classify the forwarder population into ARC-friendly (ARC- sealing on traversal, DMARC-pass likely preserved at receiver) vs ARC- ignorant (no ARC headers added, original SPF-fail surfaces directly to DMARC evaluation, message likely rejected at the p=reject step). The ARC-ignorant forwarder bucket determines the false-positive volume the publisher will see at flip-time and motivates the deployment-checklist's staged pct= ramp pattern. Read THIS ARC-explained page WITH the deployment-checklist spoke when planning a p=none → p=reject rollout for a publisher whose recipient population uses forwarder-mediated mail flows at non-trivial rate.
• DMARC for Google Workspace — the WORKSPACE-TENANT-ARC- DEPLOYMENT-INSTANTIATION companion to this ARC-protocol-mechanics reference. Where THIS page documents the per- hop ARC seal-and-validate protocol mechanics (per-hop AAR + AMS + AS header emission, RFC 8617 §5 chain-validation outcome semantics, per-receiver Trusted-ARC-Sealers trust-anchor list, forwarder-mediated DMARC-pass-preservation rescue path), the Workspace-deployment spoke is the WORKSPACE-TENANT ARC-DEPLOYMENT- CONFIGURATION REFERENCE documenting how each ARC protocol primitive instantiates concretely on Google Workspace. Concretely the spoke documents FOUR per-Workspace-tenant- configuration-vs-ARC-protocol- primitive-instantiation dimensions: (i) per-Workspace-tenant Gmail ARC-sealing infrastructure on inbound forwarder hops is the Workspace-tenant ARC-sealer instantiation — the Workspace-deployment spoke documents how the per-tenant Gmail receiver- side ARC-sealing infrastructure on forwarder hops emits the per-hop AAR + AMS + AS header triple THIS page documents at the ARC-protocol per-hop emission tier, producing the per-receiver Trusted-ARC-Sealers chain receiver-side cv=pass evaluation depends on; (ii) per- Workspace-tenant Gmail Trusted-ARC- Sealers consumer list is the Workspace-tenant ARC-trust-anchor consumption instantiation — the Workspace-deployment spoke documents how the per-tenant Gmail Trusted-ARC-Sealers consumer list determines which upstream forwarder ARC-seals the per-Workspace-tenant per-message evaluation honours (Google publishes a curated list of Trusted-ARC-Sealers; non-trusted forwarder ARC-seals do NOT rescue DMARC verdicts at the per-tenant Gmail evaluation tier — the per- Trusted-ARC-Sealer trust-decision contract THIS page documents instantiates concretely on the Workspace tenant); (iii) per- Workspace-tenant Workspace mailing- list-via-Gmail-Groups ARC-sealing behaviour is the Workspace-tenant mailing-list-intermediary ARC- protocol instantiation — the Workspace-deployment spoke documents how per-tenant Gmail Groups mailing-list traffic emits per-hop ARC seals over Subject: [list-name]-prepend and From:-rewriting transformations that would otherwise break the per-message DKIM body-hash THIS page documents as the canonical mailing-list-intermediary DMARC-pass-preservation rescue path; and (iv) per- Workspace-tenant Gmail vacation- forwarder ARC-sealing emission characteristics is the Workspace- tenant vacation-forwarder ARC- protocol instantiation — the Workspace-deployment spoke documents how per-tenant Gmail vacation-forwarder + forward-to- external-address auto-forward rules emit per-hop ARC seals on the second-hop transit producing the per-message cv=pass ARC chain receiver-side DMARC-pass-preservation rescue path THIS page documents at the ARC- protocol forwarder-rescue tier. Read the Workspace-deployment spoke ALONGSIDE this ARC-protocol- mechanics reference when deploying ARC-aware DMARC monitoring on a Google Workspace tenant — the spoke documents how each ARC protocol primitive THIS page establishes instantiates concretely on the Google Workspace cloud-only deployment architecture.
• DMARC for cPanel hosts — the SHARED-HOSTING-CPANEL-PER-ACCOUNT- DKIM-SIGNER-AS-ORIGINATING-SENDER-OF- EVERY-OUTBOUND-MESSAGE-WHOSE-ARC-CHAIN- PRESERVES-DKIM-PASS-THROUGH-DOWNSTREAM- FORWARDING-HOPS companion to this ARC protocol pillar. Where THIS page documents the RFC 8617 ARC protocol primitives (the ARC-Authentication-Results / ARC-Message-Signature / ARC-Seal headers, the per-hop AAR/AMS/AS triplet, the cv= chain-validation state machine, the per-hop instance-counter discipline), the DMARC-for-cPanel spoke is the originating- hop deployment-reference documenting how cPanel-per-account DKIM signing produces the originating DKIM-Signature this ARC chain preserves across every downstream ARC sealer at FOUR per-cPanel-tenant-to- ARC-chain-instance-coupling dimensions: (i) cPanel-per-account default._domainkey.<tenant-d> DKIM-Signature is the originating-hop message-layer cryptographic anchor that the FIRST ARC sealer (typically the recipient mailbox provider) seals into instance i=1 of the ARC chain — the DMARC-for-cPanel spoke documents how the cPanel-tenant's per-account default._domainkey signature becomes the originating-hop input to the receiver-side AMS computation at instance i=1, anchoring the ARC chain's per-hop message-layer-integrity claim THIS page documents; (ii) cPanel-per-account SPF MAIL-FROM envelope-binding determines the originating-hop SPF result the FIRST ARC sealer records in the ARC-Authentication-Results header at instance i=1 — the DMARC-for- cPanel spoke documents how the cPanel- tenant's per-account v=spf1 a:cpanel-host include:_spf... publication discipline produces the envelope-MAIL-FROM SPF result the receiver- side AAR computation at instance i=1 records in the ARC chain THIS page documents; (iii) cPanel-shared- hosting per-tenant abuse-isolation topology determines whether the ARC chain's per-hop cv=pass state machine survives forwarding hops at intermediate receivers — the DMARC-for-cPanel spoke documents the per-tenant abuse- isolation discipline (per-tenant selector partitioning, per-tenant Return-Path subdomain, per-tenant rua endpoint) whose per-tenant signing discipline determines whether a downstream ARC sealer can produce cv=pass at instance i=2+ when the forwarding hop mutates the body or adds list-unsubscribe headers THIS page's ARC protocol primitives recover from; (iv) cPanel-host-operator's per-tenant ARC-sealer-deployment posture (does the cPanel host itself act as an ARC sealer when forwarding inbound mail to per- account inboxes?) determines whether the cPanel-host appears as instance i=1 in per-recipient ARC chains the per-account spam-filter consumes — the DMARC-for-cPanel spoke documents the cPanel-host-operator's per-tenant forwarding deployment patterns (per- account inbound forwarding via cPanel Forwarders, per-account SpamAssassin / ImunifyEmail filtering, per-account outbound rebroadcast via webmail or SMTP-AUTH) whose per-hop ARC sealing contribution determines the per-tenant ARC-chain-instance topology this ARC pillar establishes. Read the DMARC-for- cPanel spoke alongside this ARC protocol reference when designing the per-cPanel- tenant outbound-and-inbound ARC posture — the spoke documents the per-tenant DKIM-signing + SPF-publishing + abuse- isolation + ARC-sealer deployment whose every per-tenant posture choice instantiates concretely as a per-tenant ARC-chain- instance at every downstream sealer this ARC pillar documents.
• SPF for Google Workspace — the WORKSPACE-TENANT-SPF-PUBLICATION- AS-LOAD-BEARING-ORIGINATING-HOP-SPF- VERDICT-INPUT-TO-EVERY-ARC-CHAIN- INSTANCE-i-EQUALS-1-AAR-AUTHENTICATION- RESULTS-CAPTURE companion to this ARC protocol pillar. Where THIS page documents the RFC 8617 ARC protocol primitives (the per-hop AAR / AMS / AS triplet, the cv=pass / cv=fail / cv=none chain-validation state machine, the per-hop i=<N> instance-counter discipline, the receiver-side trusted- sealer list, the forwarder-mediated DMARC-pass-preservation rescue path), the SPF-for-Google-Workspace spoke is the ORIGINATING-HOP DEPLOYMENT- REFERENCE documenting how per-tenant Workspace SPF publication produces the originating-hop SPF verdict ARC preserves through every downstream ARC sealer at FOUR per-Workspace- tenant-SPF-publication-to-ARC-chain- instance-i-equals-1-coupling dimensions: (i) per-Workspace- tenant v=spf1 include:_spf.google.com publication is the originating-hop SPF mechanism the FIRST ARC sealer records in spf=<result> within the AAR at instance i=1 — the SPF-for-Workspace spoke documents how the Workspace-tenant's per-tenant SPF cascade publication (include:_spf.google.com nested-cascade + per-tenant third-party-sender include: chains) produces the envelope-MAIL-FROM SPF evaluation that the receiver-side AAR computation at i=1 records as the originating-hop SPF verdict every downstream ARC sealer reads; (ii) per-Workspace-tenant SPF- Pass / SPF-SoftFail / SPF-Fail outcome-class is the originating-hop SPF-result the AAR at i=1 captures and every downstream cv= state machine inherits — the SPF- for-Workspace spoke documents how the per-tenant publication-discipline choice (qualified -all vs ~all tail-mechanism, per-tenant smarthost IP-list coverage, per-third-party-sender cascade completeness) governs whether the originating-hop SPF result the i=1 AAR captures is Pass / SoftFail / Fail / TempError / PermError — directly determining the per-hop DMARC-alignment input every subsequent ARC sealer at i=2+ preserves; (iii) per- Workspace-tenant outbound smarthost / SMTP-relay / Workspace-from-GoDaddy gateway choice is the source-IP topology the FIRST ARC sealer evaluates SPF against at i=1 — the SPF-for-Workspace spoke documents how the per-tenant outbound-gateway choice (default Workspace SMTP relay vs custom outbound-smarthost via mail-flow connector vs per-tenant outbound IP delegation) determines the source- IP the AAR-at-i=1 SPF-evaluator authenticates against the published include:_spf.google.com cascade, anchoring the per-source-IP envelope-authentication evidence the ARC chain preserves; (iv) per-Workspace-tenant mailing-list / Workspace-Groups / Gmail-vacation-forwarder hop is the intermediate ARC sealer at i=2+ whose cv= verdict depends on the originating-hop SPF verdict captured at i=1 — the SPF-for-Workspace spoke documents how the per-tenant Workspace forwarding deployments (Gmail Groups mailing-list expansion, per-tenant vacation forwarders, per-account Gmail filter-based forwarding to external addresses) cause Workspace itself to act as an intermediate ARC sealer at i=2+, where the cv= chain- validation outcome cryptographically inherits the i=1 originating-hop SPF verdict the SPF-for-Workspace spoke's per-tenant publication discipline produces. Read the SPF-for-Workspace spoke alongside this ARC protocol reference when designing the per-Workspace-tenant outbound-and-inbound ARC posture — the spoke documents the per- tenant SPF-publishing + smarthost- configuring + forwarder-deployment discipline whose every per-tenant posture choice instantiates concretely as a per-tenant ARC- chain-instance at every downstream sealer this ARC pillar documents.
• DMARC monitoring — the ARC-AS-PER-FORWARDER-HOP- CRYPTOGRAPHIC-RESCUE-PATH-WHOSE-PRESENCE- OR-ABSENCE-DETERMINES-WHETHER-FORWARDED- MAIL-PRODUCES-SYSTEMIC-FALSE-FAILURE- NOISE-IN-DMARC-MONITORING-AGGREGATE-KPIS companion documenting how the per-hop ARC seal-vs-validate protocol mechanics this pillar establishes (per-hop ARC-Authentication-Results + ARC-Message-Signature + ARC-Seal header emission, RFC 8617 §5 cv=pass / cv=fail / cv=none chain-validation outcome, per-receiver per-sealer Trusted-ARC-Sealers trust- anchor list, forwarder-mediated DMARC- pass-preservation rescue path) determines whether forwarder-mediated mail produces spurious dmarc=fail rows in the per-domain aggregate-XML stream the DMARC monitoring spoke ingests, or whether the upstream-DKIM-aligned-pass verdict gets cryptographically PRESERVED through every forwarder-hop into the final- receiver's per-message DMARC outcome the monitoring KPI dashboards then aggregate. Where THIS ARC pillar documents the per- hop cryptographic-chain mechanics, the DMARC monitoring spoke is the per-domain AGGREGATE-VIEW reference whose KPI cohort is structurally SHAPED by whether each forwarder hop in the per-message routing chain seals an ARC chain or not — at four ARC-protocol-primitive-to-monitoring-KPI- aggregation coupling dimensions: (i) per-forwarder-hop ARC sealing presence → suppression of false- failure noise in the per-domain DMARC- pass-rate KPI — when a mailing-list relay, vacation-forwarder, ESP relay, or corporate-to-personal forwarder seals an ARC chain at instance i=1, the final-receiver's DMARC evaluator can consume the cv=pass ARC outcome to preserve the upstream dkim=aligned-pass verdict rather than emit a per-message dmarc=fail row to the per-domain aggregate-XML stream the monitoring spoke ingests; absent ARC sealing, the same forwarder-mediated message produces a per-source-IP dmarc=fail aggregate-XML row attributed to the forwarder's relaying IP that the monitoring spoke surfaces as systemic false-failure noise in the per-source-IP stratification dashboard; (ii) per-forwarder- class per-source-IP ARC-coverage gap → per-source-IP fail-rate spike in the per-day per-source-IP distribution view — the monitoring spoke's per-source-IP stratification dashboard surfaces the per-forwarder-class regression where a known forwarder (mailing-list MTA, ISP-side mail-rule rewriter, corporate gateway) stops sealing ARC chains; the per-source-IP fail-rate spike isolated to the forwarder's connecting IP is the canonical signal a forwarder-class ARC-coverage regression is in progress that the operator must escalate to the forwarder's operations team to restore; (iii) per-receiver Trusted-ARC- Sealers consumer-list inclusion vs exclusion → per-receiver per-domain DMARC-pass-rate divergence in the per- receiver per-day distribution view — when one receiver (Gmail, M365 EOP, Yahoo) includes a forwarder in its Trusted-ARC-Sealers list and another receiver excludes the same forwarder, the same per-domain outbound mail-stream produces a divergent per-receiver DMARC- pass-rate distribution the monitoring spoke surfaces as cross-receiver verdict-divergence in the per-receiver per-day distribution view; the per- receiver divergence pattern is the canonical signal an upstream forwarder is sealing ARC chains the per- receiver-consumer trusts asymmetrically; (iv) per-message ARC chain cv=fail event → per-day forwarder- chain-integrity-failure KPI as load- bearing ARC-deployment-quality regression detector — when a receiver emits per-message arc=fail / cv=fail verdicts at non- zero rates, the per-message DMARC outcome collapses to whatever the per-source-IP raw SPF+DKIM evaluation produces (typically dmarc=fail through the forwarder's relaying IP); the monitoring spoke's per-receiver per-day distribution view surfaces the per-forwarder-class ARC-deployment- quality regression (forwarder's ARC sealing key expired, forwarder's body- canonicalisation choice broke an upstream DKIM signature within the sealed AMS, forwarder added headers to the sealed-header list out-of-order) the operator must triage at the cryptographic-chain-quality boundary the ARC validate-vs-seal protocol defines. Read the DMARC monitoring spoke alongside this ARC pillar when scoping per-domain forwarder-mediated- mail observability, per-source-IP ARC-coverage-gap surveillance, per- receiver Trusted-ARC-Sealers consumer- list divergence detection, and per- forwarder-class ARC-deployment-quality regression triage at the operationally- observable boundary the monitoring KPI dashboards expose.
• SPF qualifiers explained — the PER-PUBLISHER-PER-DOMAIN-SPF- MECHANISM-QUALIFIER-CHOICE-AS-LOAD- BEARING-DETERMINANT-OF-PER-HOP-SPF- VERDICT-CLASS-PRESERVED-IN-AAR-CHAIN companion to this ARC pillar. Where THIS page documents the per-message per-hop ARC chain protocol primitives (the per-hop AAR Authentication- Results capture of the receiving- side per-hop spf= + dkim= + dmarc= verdict at sealer-side evaluation time, the per-hop AMS ARC-Message-Signature signing of the message-state-as-received, the per-hop AS ARC-Seal cryptographic- seal of the AAR + AMS + prior-hop AS chain, the per-hop cv=pass / cv=fail chain-validity verdict emission, the per-receiver Trusted- ARC-Sealers consumer-list selective ARC-rescue-consumption discipline), the SPF-qualifiers-explained spoke is the STRUCTURALLY-UPSTREAM per- publisher per-domain SPF mechanism- qualifier-choice-publication- discipline reference whose RFC 7208 §4.6.2 qualifier-prefix primitive determines the per-hop spf= verdict-class captured at each per- forwarder-hop boundary in the AAR chain. The SPF-qualifier-vs-ARC- chain coupling establishes four specific per-publisher qualifier- choice-to-AAR-chain-preservation dimensions: (i) per- publisher per-domain SPF qualifier choice produces per-hop spf= verdict-class preserved verbatim in per-hop AAR spf=fail / spf=softfail / spf=pass / spf=neutral / spf=permerror / spf=temperror / spf=none result capture — per-publisher per-domain v=spf1 publication discipline (terminal- mechanism + per-mechanism qualifier choices) determines the per-hop receiving-side SPF evaluation verdict-class; the per-hop ARC sealer captures this verdict-class verbatim in the per-hop AAR record per RFC 8617 §5 + RFC 8601 §2.7.2; downstream receivers evaluating the ARC chain consume the AAR-preserved per-hop spf= verdict as the load-bearing per- hop SPF-evaluation-evidence-row the per-publisher per-hop ARC- chain-rescue evaluation produces; (ii) per-publisher per-forwarder-class envelope-MAIL- FROM-rewrite (SRS) preserves per- publisher per-domain SPF qualifier evaluation context in per-hop AAR chain — per-publisher per-forwarder-class SRS (Sender- Rewriting-Scheme) envelope-MAIL- FROM-rewrite produces a forwarder- domain SPF-evaluation at the receiving hop; the per-hop AAR captures the forwarder-domain SPF verdict-class (typically spf=pass on the forwarder's per- domain SPF publication) while the per-publisher per-domain original SPF qualifier choice is preserved in upstream AAR record for downstream-receiver per- publisher per-hop SPF-evaluation- context reconstruction; per- publisher per-domain SPF qualifier discipline is load- bearing for per-receiver per-hop AAR-chain SPF-context interpretation; (iii) per-publisher per-domain SPF ~all → -all qualifier migration produces per-hop AAR chain spf=softfail-to-spf=fail verdict-class shift visible in per-receiver per-day per-source-IP per-forwarder-class chain-validity evaluation evidence — per-publisher SPF qualifier migration (typically as Phase 3 rollout step) shifts the per-hop AAR-preserved spf= verdict-class from softfail to fail; per- receiver per-hop ARC-chain- validity evaluation observes per-publisher per-source-IP per- forwarder-class spf=fail-rate lift; per-publisher per-forwarder- class ARC-rescue coverage gap widens for per-source-IP forwarder-hops without per- publisher per-domain DKIM-aligned- pass survival; (iv) per- publisher per-mechanism explicit- qualifier choice as load-bearing per-publisher per-hop AAR- preserved per-mechanism-match per-message SPF-evaluation evidence determinant — per-publisher per-mechanism explicit-qualifier publication (-ip4: per-rogue-host deny-list + -include: per-formerly-authorised-ESP deny- list) drives per-hop AAR-captured per-mechanism-match per-message spf=fail at receiving-side SPF evaluation; per-receiver per-hop ARC-chain-validity evaluation observes per-publisher per- mechanism enforcement-discipline at maximum per-source-IP per- mechanism granularity preserved through every per-forwarder-hop ARC-seal boundary. Read the SPF- qualifiers-explained spoke alongside this ARC pillar when investigating per-publisher per- source-IP per-forwarder-class AAR-preserved spf= verdict-class distribution attribution (per- publisher per-domain SPF qualifier- choice publication is the upstream determinant), and when planning per-publisher per-domain SPF qualifier migration whose downstream impact on per-publisher per-hop AAR-chain spf= verdict-class preservation pipeline THIS ARC pillar documents observes.
• DMARC reporting pipeline (RUA / RUF ingestion, parsing, delivery) — the canonical downstream-consumer reference documenting how the per- forwarder-hop ARC-chain-validation verdict THIS page architectures (the RFC 8617 §5.2 per-hop AS / AMS / AAR sealing-validation cascade producing the per-hop arc=pass / arc=fail verdict-class) flows DOWNSTREAM through the FIVE-STAGE receiver-to-operator pipeline that serialises every per- message ARC-chain validation outcome into operator-consumable per-row evidence: (1) receiver-side aggregate- XML generation cadence (Gmail / Microsoft 365 / Yahoo / Mail.ru) where the per-message ARC chain's terminal i=N AS-validation verdict becomes the row/auth_results/dkim/result= and row/policy_evaluated/dkim= attribute values for forwarded mail whose originating-hop DKIM survived ARC sealing but whose forwarder modified the body or headers in ways that broke the originating DKIM signature, (2) publisher-side rua= addressing (the mailbox list whose external-domain entries require a _report._dmarc.example.com delegation per RFC 7489 §7.1), (3) mailbox-side IMAP / Microsoft Graph ingestion (imap_fetch.php / ImapFetcher / GraphFetcher polling + attachment unwrap), (4) parser-side XML-to-row decomposition (DmarcParser walking the RFC 7489 §7.2.1 XSD-validated record blocks and minting dmarc_records rows with the per-message ARC-rescued policy_evaluated.dkim/spf verdict), and (5) dashboard delivery (the empirical evidence operators consume for the per-forwarder-class ARC-adoption-rate observability that determines whether the publisher's forwarded-mail-stream DMARC-aligned-pass rate is dominated by ARC-rescued verdicts or by raw originating-DKIM verdicts). Read the reporting-pipeline spoke ALONGSIDE this ARC pillar when the operator asks "how does ARC chain validation surface in the aggregate-report evidence stream" — the answer is FIVE-LAYERED: THIS page architectures the per-message ARC chain validation, the reporting-pipeline spoke documents the five-stage downstream infrastructure that serialises the per-hop ARC chain verdict into per-row evidence operators consume for forwarded-mail-class deliverability decisions.
• TLS-RPT report format (RFC 8460 §4 JSON-aggregate schema) — the PER-MESSAGE-ARC-AAR-PER- HOP-AUTHENTICATION-VERDICT- PRESERVATION-CHAIN-AS- STRUCTURAL-PARALLEL companion to this ARC-explained reference. Where THIS page documents the ARC per-message header-set (ARC-Seal, ARC-Message-Signature, ARC-Authentication-Results) + the per-hop chain-of-trust forwarder-instance attestation + the RFC 8617 §5 per-AAR- instance i=-tag chain integer-monotonicity invariant, the tls_rpt_report_ format spoke documents the structurally-parallel per- receiver per-publisher per-day RFC 8460 §4 JSON-aggregate report policies[].failure- details[] per-failure- class per-hop evidence-chain catalogue (per-row sending-mta-ip per-forwarder-IP attribution, receiving-mx-helo per-receiving-MX EHLO/HELO identity, receiving-mx- hostname per-receiving- MX hostname identity, additional-information per-hop-debug-evidence URL catalogue). FOUR structurally- distinct PER-HOP-EVIDENCE- PRESERVATION-DIMENSIONS the tls_rpt_report_format spoke operationally documents the ARC chain-of-trust forwarder- instance attestation structurally parallels: (i) per-ARC-instance AAR per-hop authentication-verdict preservation AS STRUCTURAL- TWIN-OF per-TLS-RPT-failure- details-row per-forwarder-IP TLS-handshake-evidence preservation — ARC preserves the per-hop SPF + DKIM + DMARC verdict via the AAR header at the application- layer; the TLS-RPT failure- details JSON-row preserves the per-forwarder-IP per-day TLS- handshake outcome at the transport-layer; both per-hop evidence preservation mechanisms emit per-forwarder- intermediary-identity- attributed per-message OR per- day verdict-evidence the receiver-side debugger consumes; (ii) per-ARC- instance ARC-Message-Signature per-hop message-body cryptographic-attestation chain AS STRUCTURAL-TWIN-OF per-TLS-RPT-policy-failure- details per-hop TLS-handshake cryptographic-trust-chain evidence — ARC- Message-Signature attests the per-hop forwarder-modification boundary at the application- layer; TLS-RPT failure-details per-hop result-type catalogue (certificate- host-mismatch / certificate-not-trusted / certificate-expired / validation-failure) attests the per-hop TLS- handshake-cryptographic-trust- chain integrity at the transport-layer; both per-hop cryptographic-attestation evidence streams catalogue per- intermediary-identity per- verdict-evidence the receiver- side forwarder-attribution debugger consumes; (iii) per-ARC-instance ARC- Seal cv= chain-validation-state (cv=none / cv=pass / cv=fail) AS STRUCTURAL-TWIN-OF per-TLS- RPT-summary total-successful- session-count / total-failure-session- count per-policy per-day verdict-aggregation — ARC-Seal cv= attests the per-message per-hop chain- validation state at the per- ARC-instance boundary; TLS-RPT per-policy summary attests the per-publisher per- receiver per-day per-policy session-count outcome at the per-aggregate-report boundary; both per-policy chain- validation-state attestation streams catalogue per-policy- validity-state per-verdict- evidence the receiver-side chain-validation-state debugger consumes; (iv) per- AAR-instance per-hop receiver- identity-attribution AS STRUCTURAL-TWIN-OF per-TLS- RPT-organization-name-and- contact-info per-emitter- identity-attribution — ARC AAR identifies each per- hop forwarder by the i=-tag instance- index + the receiver-emitted organization-identifier (e.g., gmail.com, list.example.org, arc-amx.amazonses.com); TLS-RPT JSON-aggregate identifies each per-emitter by the organization- name + contact-info report-envelope fields; both per-hop-emitter-identity- attribution evidence streams catalogue per-intermediary- identity per-verdict-evidence the receiver-side per- intermediary-attribution debugger consumes. Read the tls_rpt_report_format spoke ALONGSIDE this ARC-explained reference whenever the publisher scopes a per-publisher per-hop per-intermediary- identity attribution analysis plan — the RFC-8460-§4-JSON- aggregate-report-format byte- schema THIS comparison spoke documents IS the canonical load-bearing per-receiver- emitted transport-layer per- hop evidence chain structurally paralleling the ARC application-layer per-hop evidence chain THIS page documents at the per- application-vs-per-transport- layer per-hop-evidence- preservation boundary.
• Business Email Compromise (BEC) — the FINANCIAL-IMPACT THREAT-MODEL downstream consumer of the per-forwarder-hop ARC chain-of-custody primitive THIS page architectures. Where THIS page documents the RFC 8617 AAR + AMS + AS per-hop sealing contract that preserves the originating-hop DKIM verdict through forwarder boundaries (mailing-list relays, vacation forwarders, multi-tenant SaaS intermediaries), the BEC spoke documents the financial-fraud attack class whose forwarder- path-injected exact-domain From-header impersonation variants the per-hop ARC seal chain-of-custody helps downstream receivers cryptographically attribute and reject. Read THIS page when architecting the per-hop ARC sealing posture; read the BEC spoke when MOTIVATING that posture against the financial- fraud threat surface it closes.
• DMARC for Microsoft 365 — the M365-TENANT-ARC-DEPLOYMENT- INSTANTIATION companion to this ARC-protocol-mechanics reference. Where THIS page documents the per- hop ARC seal-and-validate protocol mechanics (per-hop AAR + AMS + AS header emission, RFC 8617 §5 chain-validation outcome semantics, per-receiver Trusted-ARC-Sealers trust-anchor list, forwarder-mediated DMARC-pass-preservation rescue path), the M365-deployment spoke is the M365-TENANT ARC-DEPLOYMENT- CONFIGURATION REFERENCE documenting how each ARC protocol primitive instantiates concretely on Microsoft 365 at FOUR per-M365-tenant-Exchange- Online-configuration-vs-ARC-protocol- primitive-instantiation dimensions: (i) per-M365-tenant Exchange Online ARC-sealing infrastructure on inbound forwarder hops is the per- M365-tenant ARC-sealer instantiation — the M365- deployment spoke documents how the per-tenant Exchange Online receiver- side ARC-sealing infrastructure on forwarder hops emits the per-hop AAR + AMS + AS header triple THIS page documents at the ARC-protocol per-hop emission tier, producing the per-receiver Trusted-ARC-Sealers chain receiver-side cv=pass evaluation depends on; (ii) per-M365- tenant Exchange Online Trusted-ARC- Sealers consumer list is the per- M365-tenant ARC-trust-anchor consumption instantiation — the M365-deployment spoke documents how the per-tenant Exchange Online Trusted-ARC-Sealers consumer list determines which upstream forwarder ARC-seals the per-M365-tenant per- message evaluation honours (Microsoft publishes a curated list of Trusted- ARC-Sealers; non-trusted forwarder ARC-seals do NOT rescue DMARC verdicts at the per-tenant Exchange Online evaluation tier — the per- Trusted-ARC-Sealer trust-decision contract THIS page documents instantiates concretely on the M365 tenant); (iii) per-M365- tenant Exchange Online distribution- list ARC-sealing behaviour is the per-M365-tenant mailing-list- intermediary ARC-protocol instantiation — the M365- deployment spoke documents how per- tenant Exchange Online distribution- list traffic emits per-hop ARC seals over Subject: [list-name]-prepend and From:-rewriting transformations that would otherwise break the per-message DKIM body-hash THIS page documents as the canonical mailing-list- intermediary DMARC-pass-preservation rescue path; and (iv) per- M365-tenant Exchange Online forwarding-rule ARC-sealing emission characteristics is the per-M365- tenant forwarding-rule ARC-protocol instantiation — the M365- deployment spoke documents how per- tenant Exchange Online forwarding rules (inbox-rule-mediated forwarding, transport-rule-mediated forwarding, SMTP forwarding) emit per-hop ARC seals whose chain-of-custody this page documents as the per-forwarder- hop rescue primitive against per- publisher per-domain DMARC enforcement.
• Email authentication glossary — the PER-ARC-PROTOCOL-PRIMITIVE- JARGON-CATALOGUE-AS-LOAD-BEARING-CROSS- PROTOCOL-REFERENCE-OF-STANDARDISED- TERMINOLOGY companion to this ARC protocol-mechanics pillar. Where THIS page documents the RFC 8617 per-hop ARC chain-of-custody seal-and-verify protocol mechanics — the per-message AAR (ARC-Authentication-Results), AMS (ARC-Message-Signature), and AS (ARC-Seal) header triplet emitted at instance i=N of every chain hop, the cv=pass / cv=fail / cv=none chain-validation outcome class, the per- sealer Trusted-ARC-Sealers receiver-side trust-anchor list, and the per-forwarder- hop DMARC-pass-preservation rescue path — the email-authentication glossary spoke is the LOAD-BEARING cross-protocol reference catalogue of standardised terminology that every per-ARC-protocol- primitive reader needs alongside this per-hop ARC chain-of-custody walk-through at FOUR per-ARC-header-triplet-tag-vs- glossary-definition coupling dimensions: (i) per-ARC-Seal-tag jargon (AS instance i=, cv= chain-validation, b= signature value, t= timestamp, a= algorithm, d= sealing domain, s= selector) is structurally- catalogued in the glossary's per-ARC-tag entry-set — the glossary spoke documents the canonical per-AS-tag definition for every byte-level ARC-Seal: field THIS page documents at the per-hop seal-emission boundary, so a reader stepping through the per-hop ARC chain-of-custody walk- through THIS page documents has a single cross-cluster definition catalogue to consult when the per-AS-tag jargon surfaces in the per-message ARC-Seal: byte-level reader without breaking flow back to the chain- of-custody mechanics; (ii) per- ARC-Message-Signature-tag jargon (AMS instance i=, b= signature value, bh= body hash, c= canonicalisation pair, h= signed-header list, d= signing domain, s= selector) is structurally- catalogued in the glossary's per-DKIM- and-AMS-tag entry-set — the glossary spoke documents the canonical per-AMS-tag-and-DKIM-tag definition for every byte-level ARC-Message-Signature: field whose tag-grammar is structurally inherited from the RFC 6376 §3.5 DKIM-Signature: tag-grammar, so a reader stepping through the per- hop AMS-emission boundary THIS page documents has a single catalogue to consult when the per-AMS-tag jargon surfaces at the per-hop AMS-vs-DKIM- Signature comparison boundary; (iii) per-ARC-Authentication-Results- tag jargon (AAR instance i=, per-method spf= / dkim= / dmarc= verdict-class strings, per-method- identifier header.from= / header.d= / smtp.mailfrom= sub-tag catalogue) is structurally-catalogued in the glossary's per-Authentication- Results entry-set — the glossary spoke documents the canonical per-AAR-tag-and-verdict-class definition for every byte-level ARC- Authentication-Results: field whose verdict-class set is structurally inherited from the RFC 8601 Authentication-Results: verdict-class set, so a reader stepping through the per-hop AAR-emission boundary THIS page documents has a single catalogue to consult when the per-AAR-tag jargon surfaces at the per- hop verdict-class-preservation boundary; and (iv) per-DMARC-policy-rollout- primitive jargon catalogued by the glossary IS the cross-cluster-reference- definition the ARC chain-of-custody protocol-mechanics primitive ultimately feeds the per-publisher per-domain DMARC enforcement-progression discipline through — the glossary spoke documents the canonical per-DMARC-policy- rollout-primitive definition catalogue (p=none / p=quarantine / p=reject ramp, pct= percent-ramp, sp= subdomain-policy, adkim= / aspf= alignment-mode, rua= / ruf= reporting-destination jargon) whose downstream-consumer discipline IS the ultimate destination of the per-hop ARC chain-of-custody verdict-preservation primitive THIS page documents — the per-publisher per-domain DMARC enforcement-progression discipline reads the per-message ARC-chain-validation verdict-stream THIS page documents as the per-forwarder-hop authentication-evidence cohort that gates every p=none → p=quarantine → p=reject ramp-step tightening commit on the per-forwarder- hop sub-cohort.
• DNS propagation — the per-forwarder-hop DNS-PROPAGATION-TIMING companion to this RFC 8617 ARC chain-of-custody protocol reference. Where THIS page documents the per-forwarder-hop ARC three-header chain protocol — the per-hop ARC-Authentication-Results (AAR) header recording the per-forwarder- hop received-authentication-verdict, the per-hop ARC-Message-Signature (AMS) header cryptographically sealing the per-forwarder-hop message-state, the per- hop ARC-Seal (AS) header sealing the per-hop AAR + AMS, the per- forwarder-hop instance-number i=<N> grammar sequencing the per-hop chain, the per- receiver chain-validation algorithm recovering the ORIGINAL per-publisher per-domain authentication-verdict through the per-forwarder-hop tunnel — the DNS- propagation spoke documents the per- resolver per-TTL operational-timing layer whose propagation-delay determinism gates every per-receiver per-message AMS / AS signature-verification cryptographic-key- lookup the ARC chain-validation algorithm performs. The composition operates through three per-forwarder-hop per-ARC-sealer DNS-propagation-timing dependencies the per-receiver chain-validation algorithm materially relies on: (i) per-forwarder- hop per-ARC-sealer <selector>._domainkey.<forwarder> DKIM public-key record TTL determines the per-receiver per-resolver propagation- delay between the per-forwarder-hop operator's per-ARC-sealer DKIM-key rotation and the per-receiver chain- validation algorithm observing the new per-forwarder-hop AMS / AS signature- verification key, which determines whether a per-forwarder-hop AMS / AS signature-verification regression is a per-forwarder-hop key-rotation propagation artefact vs a real per-forwarder-hop chain-integrity violation; (ii) per- forwarder-hop per-ARC-sealer DKIM-key- revocation TTL determines the per- receiver per-resolver propagation-delay between the per-forwarder-hop operator revoking a compromised per-ARC-sealer DKIM key (publishing p= empty-value per RFC 6376 §3.6.1) and the per-receiver chain-validation algorithm refusing per- forwarder-hop AMS / AS signatures over the revoked key; (iii) per-receiver per- ARC-trusted-sealer-list publication TTL — where the per-receiver chain-validation algorithm's per-forwarder-hop trusted- sealer-list discovery uses any DNS-published directory — determines the per-receiver per-resolver propagation-delay between the per-receiver per-trusted-sealer-list operator's per-forwarder-hop trust promotion and the per-receiver chain- validation algorithm observing the per- forwarder-hop sealer as trust-eligible. Read THIS page when ARCHITECTING the per-forwarder-hop ARC chain-of-custody protocol deployment discipline; read the DNS-propagation spoke when SEQUENCING the per-forwarder-hop per-ARC-sealer DKIM-key rotation cadence against per-receiver per- resolver per-DKIM-record TTL cache- lifetime windows whose propagation-delay determinism gates per-forwarder-hop AMS / AS signature-verification observability at the per-receiver chain-validation algorithm.
• Email Header Analyzer — paste any email's headers and inspect every Authentication-Results-family header including the ARC chain hop-by-hop.
• Domain Security Checker — live DNS lookups for SPF, DKIM, DMARC, BIMI, MTA-STS, TLS-RPT, CAA. ARC has no protected-domain DNS record so the checker focuses on the other seven.
• DMARC Analyzer Dashboard — ingests aggregate reports so you can see the production reality of how often forwarded mail with ARC headers reaches receivers vs being rejected.
• SPF 10-DNS-lookup limit — the SPF-10-DNS-LOOKUP-CEILING-AS-LOAD-BEARING- ORIGINAL-PUBLISHER-SPF-VERDICT-PRECONDITION-WHOSE- VIOLATION-PROPAGATES-THROUGH-THE-ENTIRE-ARC-CHAIN companion to this ARC chain protocol pillar. Where THIS page documents the ARC chain-of-custody mechanism at the byte level (the AAR / AMS / AS three-header chain, the per-hop instance numbering i=<N> grammar, the chain- validation algorithm whose cv tag values none / pass / fail determine whether the receiver can recover the ORIGINAL pre-forwarder verdict), the SPF-lookup-limit spoke is the FIRST-HOP- ORIGINAL-PUBLISHER-SPF-VERDICT-CORRECTNESS-PRECONDITION companion documenting the RFC 7208 §4.6.4 10-DNS- lookup budget that determines whether the very ORIGINAL spf=pass verdict ARC sealers carry through the chain is itself valid at the first hop. The ARC-vs-SPF-lookup-limit relationship is downstream-recovery-vs-upstream-correctness: THIS page documents how ARC recovers original verdicts through forwarder hops; the SPF-lookup-limit spoke documents the publisher-side discipline that determines whether the original SPF verdict is itself spf=pass / spf=neutral / spf=softfail / spf=permerror in the first place. Four ARC-vs-SPF-lookup-limit coupling dimensions matter at the chain-of-custody layer: (i) per-publisher cumulative SPF include-cascade lookup cost — if the original publisher's v=spf1 include:<esp1> include:<esp2> include:<esp3> -all cascade exceeds the 10-lookup ceiling, the original first-hop verdict is spf=permerror, and every downstream ARC sealer cryptographically commits that permerror verdict into its AAR header so receiver-side chain- validation cannot recover a pass verdict the original publisher never produced; (ii) per-forwarder ARC sealer's own SPF-aligned-pass gate at the receiving hop — when the forwarder re-evaluates the message with its own envelope rewrite, the forwarder's own SPF cascade must ALSO respect the 10-lookup budget so the per-hop AAR captures a valid forwarder-side spf=pass sub-verdict for the trusted-sealer-list operator to qualify the hop as trust-eligible; (iii) per- receiver cv=pass chain-validation outcome under original-publisher SPF-permerror — even when the ARC chain itself is cryptographically valid (every AMS / AS header verifies against its corresponding DKIM public key, the per-hop instance numbering is contiguous, and the trusted-sealer-list grants every hop trust status), if the AAR at i=1 commits an original spf=permerror verdict the rescued DMARC outcome remains conditioned on DKIM-aligned-pass being the load-bearing single DMARC leg; (iv) per-publisher 10-lookup-budget remediation discipline — RFC 7208 §11.1.1 permerror treatment, SPF flattening to ip4: / ip6: literals, per-ESP include: consolidation, and per-zone v=spf1 TXT-record splitting across _spf.<domain> sub-zones all preserve the ORIGINAL first-hop spf=pass verdict that ARC's chain-of-custody mechanism then recovers through forwarder hops. Read THIS page when DEPLOYING the ARC chain-of-custody protocol at the receiver-side trusted-sealer-list layer; read the SPF-lookup-limit spoke when AUDITING the publisher-side SPF include-cascade against the RFC 7208 §4.6.4 10-DNS-lookup budget so the ORIGINAL first-hop SPF verdict ARC's chain commits is itself spf=pass rather than spf=permerror.
• Multi-domain DMARC strategy — the PER-PUBLISHER-PER-PORTFOLIO-MULTI-DOMAIN- DMARC-PUBLICATION-COORDINATION-AS-LOAD-BEARING- ORGANISATIONAL-DOMAIN-IDENTIFICATION-PRECONDITION- FOR-ARC-CHAIN-RECEIVER-SIDE-DMARC-IDENTIFIER- ALIGNMENT-RECOVERY companion to this ARC chain protocol pillar. Where THIS page documents the RFC 8617 chain-of-custody mechanism at the byte level (the AAR / AMS / AS three-header chain, the per-hop instance numbering i=<N> grammar, the chain- validation algorithm whose cv tag values none / pass / fail determine whether the receiver can recover the ORIGINAL pre-forwarder DMARC verdict through forwarder hops, the trusted- sealer-list operational discipline), the multi- domain-DMARC-strategy spoke is the PER-PUBLISHER- PER-PORTFOLIO-ORGANISATIONAL-DOMAIN-IDENTIFICATION- PRECONDITION companion documenting the per- publisher per-portfolio per-primary + per- secondary + per-parked-domain inventory enumeration discipline, the Public-Suffix-List- anchored organisational-domain identification rule the receiver-side DMARC adkim=relaxed / adkim=strict + aspf=relaxed / aspf=strict identifier-alignment evaluator consumes, the per-primary-domain _dmarc.<primary> policy-mode publication discipline coordinated against the per-subdomain sp= subdomain-policy hardening posture, and the per-parked-domain locked-down v=spf1 -all + DKIM-empty-p= + _dmarc.<parked> at p=reject + null-MX defensive- publication discipline. The ARC-vs-multi- domain-DMARC-strategy relationship is downstream-recovery-vs-upstream-portfolio- coordination: THIS page documents how ARC recovers original DMARC verdicts through forwarder hops; the multi-domain-DMARC- strategy spoke documents the per-publisher per-portfolio DMARC publication-coordination discipline that determines whether the per-publisher organisational-domain identification is itself well-defined at the receiver-side chain-validation boundary in the first place. Four ARC-vs-multi-domain- DMARC coordination dimensions matter at the chain-of-custody layer: (i) per-publisher per-portfolio organisational-domain identification — the receiver-side DMARC algorithm walks up the Public-Suffix-List boundary to discover the organisational domain whose _dmarc record publishes the alignment policy, and the per-publisher per-portfolio multi-domain DMARC publication discipline determines which of the per-primary + per-secondary + per-brand domains is identified as organisational at each per-message receiver-side evaluation through the ARC chain; (ii) per-portfolio-subdomain-policy coordination — the per-primary-domain p=quarantine sp=reject subdomain-policy hardening published per memory the multi-domain-strategy spoke documents determines which per-message chain-validation outcome the ARC receiver-side algorithm produces for forwarded subdomain traffic; (iii) per-portfolio-parked-domain ARC chain attack-surface — attackers target the weakly-published parked-domain DMARC posture as the per-publisher per-portfolio forwarder-hop spoofing-bypass entrypoint, and the multi-domain-strategy spoke's locked-down per-parked-domain defensive- publication discipline closes that per-publisher per-portfolio attack-surface before ARC chain-of-custody recovery becomes the load-bearing receiver-side DMARC outcome; (iv) per-portfolio per- secondary-domain ARC trusted-sealer coordination — when the per-publisher per-portfolio per-secondary-domain outbound-mail is forwarded through ESP- operated ARC sealers, the per-portfolio per-secondary-domain DMARC-record publication coordination the multi-domain- strategy spoke documents determines whether the per-secondary-domain organisational-domain identification produces a chain-validation cv=pass outcome the receiver-side DMARC evaluator can act on. Read THIS page when DEPLOYING the ARC chain-of-custody protocol at the receiver-side trusted- sealer-list layer; read the multi-domain- strategy spoke when PUBLISHING the per-publisher per-portfolio per-primary + per-secondary + per-parked-domain coordinated DMARC publication discipline whose per-publisher per-portfolio organisational-domain identification IS the load-bearing receiver-side precondition the ARC chain-validation algorithm consumes when recovering the ORIGINAL pre-forwarder DMARC verdict through forwarder hops.
• MTA-STS for Google Workspace
• RFC 8617 — Authenticated Received Chain (ARC) — the foundational specification.
• RFC 8601 — Authentication-Results header — the per-message verdict header whose format the AAR mirrors.
• Microsoft SNDS + JMRP monitoring — forwarding chains that break authentication also skew complaint attribution: SNDS + JMRP shows how Microsoft's consumer network judges the IPs that actually deliver your (possibly forwarded) mail.

Inspect an ARC chain now

DMARC Analyzer's includes/EmailHeaderParser.php recognises every Authentication-Results family header including ARC-Authentication-Results, ARC-Message-Signature, and ARC-Seal. Paste any forwarded message's raw headers into the Email Header Analyzer and walk the chain hop-by-hop — every AAR shows the receiving entity's verdict, every AMS / AS records the signer and selector, and the chain validation state surfaces in the top-level Authentication- Results.

Sign up — Free plan Analyze an ARC chain