## この記事でわかること

- 転送経由で SPF / DKIM / DMARC が崩れる仕組みと、ARC が解決する範囲
- ARC が付与する 3 種類のヘッダ（AAR / AMS / AS）と信頼チェーンの作り方
- 受信側が ARC を「信用する／しない」を判断する観点
- 自社が転送される側だった場合の運用ポイント

## 転送で DMARC が崩れる問題

メーリングリストや個人のフォワーダ（`@gmail.com` から `@example.com` に転送する等）を経由すると、Subject に `[ML名]` が付くなどで本文ハッシュが変わり DKIM が破綻、エンベロープ From も書き換わって SPF が pass しなくなります。結果として DMARC は fail。本来正規メールなのに `p=reject` で弾かれます。

![転送経路で DMARC が崩れる図](/blog/arc-authentication-deep-dive/forwarder-break.svg)

## ARC が解決する範囲

ARC（RFC 8617）は、**転送する各 MTA が「私が中継した時点での認証結果」を署名付きで残し、最終受信者がそのチェーンを検証することで元の認証結果を信頼できるようにする**仕組みです。3 種類のヘッダが連鎖します。

![ARC の 3 ヘッダ](/blog/arc-authentication-deep-dive/three-headers.svg)

- **ARC-Authentication-Results（AAR）**: その時点での Auth 結果（SPF/DKIM/DMARC）
- **ARC-Message-Signature（AMS）**: メッセージ本文＋ヘッダの署名（DKIM 類似）
- **ARC-Seal（AS）**: 前段までの AAR/AMS/AS をまとめて署名（チェーン保護）

各中継 MTA はこの 3 つを `i=1`、`i=2`、`i=3` … のインデックスで積み上げます。最終受信者は AS を辿って改ざんがないことを確認し、最初の AAR で「元の送信時点で DMARC pass だった」と判断できます。

## Gmail / Outlook での扱い

Google は Gmail 受信時に ARC を検証し、信頼できる中継者経由なら DMARC fail でも spam に落とさない判断材料にします。ただし「ARC が pass = 必ず受信」ではなく、**中継者の信頼度**（過去のスパム率）と組み合わせて判定されます。Microsoft も同様に ARC をシグナルとして利用。

つまり ARC は「fail を強引に pass にする」ものではなく「fail の理由が転送に起因することを証明する」だけです。受信側がそれを信用するかは別問題。

## 自社運用での意識ポイント

- **送信者として**: 自社からの直送が DMARC pass であることをまず確保（ARC は救済策、まず本筋）
- **受信者として（社内 MTA を運用しているなら）**: 中継時に AAR/AMS/AS を必ず付ける。Postfix / Exim / Sendmail 等は OpenDKIM / OpenARC で対応可
- **メーリングリスト運用者**: Mailman 3 / Sympa などは ARC 署名対応版を使う。古い ML ソフトは ARC 未対応で受信側が DMARC fail を救えない

詳細は[転送で DMARC が崩れる対処](/blog/dmarc-fail-troubleshooting)も併読してください。

## まずは現状を把握しましょう

自社ドメインの認証状況や転送経由での失敗状況は、無料の[ドメイン診断](/diagnose)で SPF・DKIM・DMARC・SSL を一括チェックできます。判断に迷う場合は[お問い合わせ](/contact)からご相談ください。SSL や DNS の単発チェックは[無料ツール一覧](/tools)からどうぞ。

関連記事: [ARC（Authenticated Received Chain）とは](/blog/arc-what-is) / [DMARC とは？](/blog/what-is-dmarc) / [メールヘッダの読み方](/blog/email-headers-reading-guide)