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

- ARC が解決する「転送するとメールが届かなくなる」問題の正体
- ARC ヘッダーで何が記録され、どう検証されるか
- 中小企業が DMARC を `p=reject` まで強化する前に知っておくべきこと

## 「メーリングリストに転送したら届かない」問題

社内のメーリングリストや、Gmail の自動転送ルールでメールを送っているのに、**転送先で迷惑メール扱いされる、または届かない** ── という事象を経験したことはないでしょうか。

これは故障ではなく、**SPF / DKIM / DMARC の仕組み上、避けられない副作用**です。

転送が認証を壊す典型例:

- **メーリングリストが件名に `[ML名]` を付ける**: DKIM 署名が崩れる
- **転送時に Subject や本文の改行コードが書き換わる**: DKIM 署名が崩れる
- **転送サーバーの IP が SPF の許可リストにない**: SPF が fail する
- **`From:` を MLM(メーリングリスト管理プログラム)が書き換える**: DMARC のアラインメントが崩れる

つまり、**「転送するたびに認証情報が壊れる構造になっている」**ことが、ML やメール自動化の世界での歴史的問題でした。詳しい認証の役割は[SPF・DKIM・DMARC の違い](/blog/spf-dkim-dmarc-difference)を参照してください。

![転送で認証が壊れる構造](/blog/arc-what-is/forwarding-broken.svg)

## ARC は「転送経路の認証チェーン」を残す仕組み

ARC(Authenticated Received Chain、認証済み受信チェーン)は、RFC 8617 で標準化された仕組みで、**転送を経由したメールにも「途中の認証情報」を引き継ぐ**ことができます。

仕組みは次のとおり:

1. **元の受信側(ML サーバー等)が、その時点で SPF / DKIM / DMARC の認証結果を判定**
2. **その結果を ARC ヘッダーに記録し、自分の署名(ARC-Seal)を付ける**
3. **次の転送先は、ARC ヘッダーを見て「途中で認証は通っていた」と判断できる**

最終的な受信側(社員の Gmail / Outlook 等)は、SPF / DKIM が直接 fail していても、**ARC チェーンで「途中までは認証が通っていた」ことを確認**できれば、メールを正規メールとして扱える、という設計です。

![ARC ヘッダーチェーンの動作](/blog/arc-what-is/arc-chain.svg)

つまり ARC は、SPF / DKIM / DMARC を **置き換えるのではなく、補完する**仕組みです。

## ARC ヘッダーは 3 種類

メールの header を見ると、ARC ヘッダーは次の 3 種類で 1 セットになっています。

- **ARC-Authentication-Results(AAR)**: 各中継サーバーでの認証結果
- **ARC-Message-Signature(AMS)**: 中継サーバーが付けた本文の DKIM 風署名
- **ARC-Seal(AS)**: 上記 2 つを保護する署名

これらが転送ごとに **i=1、i=2、i=3 …** と番号付きで蓄積されていきます。最終受信側は **チェーン全体の検証(AS のチェーン整合性)を確認**することで、改ざんがないことを判定します。

詳細仕様は IETF の RFC 8617 を参照してください。

## 中小企業が知っておくべき 3 つのこと

Web 担当者・情シス・制作会社担当者として、ARC は **「自分で設定する」ものではなく、「使われている前提で運用する」**もの、という距離感が現実的です。

### 1. Gmail / Microsoft 365 は ARC に対応している

Gmail と Microsoft 365 は ARC に対応しており、自社で何もしなくても、これらのメール基盤を経由する転送には ARC ヘッダーが自動で付きます。中小企業の大部分はこの恩恵を自動的に受けています。

### 2. DMARC を `p=reject` に強化する前に転送経路を確認

[DMARC強化の手順](/blog/dmarc-policy-tightening)でも触れていますが、`p=quarantine` や `p=reject` に進めると、転送経路で認証が壊れた正規メールも止めてしまうリスクがあります。

ARC が機能していれば最終受信側で救済されますが、**すべての受信側が ARC を活用してくれるとは限らない**のが現実です。DMARC を強化する前に、

- 御社のメールが取引先のどこへ転送されているか
- その転送先が ARC を活用しているか

を **DMARC レポート**で見ておくのが安全です。詳しくは[DMARC レポートの読み方](/blog/dmarc-report-reading)で扱っています。

### 3. ML を運用するなら ARC 対応の MLM を選ぶ

社内で独自の ML サーバーを運用している場合は、**ARC に対応したメーリングリストソフトウェア**を選ぶ価値があります。Postfix + ML プログラムなどの自前運用は、認証チェーンが切れる問題に長く悩まされてきましたが、ARC 対応の MLM(Mailman 3 等)を使えば、最終受信側での到達率が大きく改善します。

## まとめ

- ARC は「転送経路で SPF / DKIM / DMARC が壊れる」歴史的問題への対応として標準化された仕組み
- 中継サーバーが認証結果を ARC ヘッダーに残し、最終受信側がチェーン検証で正規メールを救済する
- 中小企業は Gmail / Microsoft 365 経由で恩恵を自動的に受けている。DMARC `p=reject` 強化前に転送経路の状態を確認しておく

## DMARC レポートで転送経路を把握

御社のメールが ML や自動転送でどう扱われているか、現状を把握するなら、まず無料の[ドメイン診断](/diagnose)で SPF / DKIM / DMARC の状態を確認できます。DMARC を導入していれば、レポート(rua)で転送経路の認証状態が見えるようになります。

DMARC レポート分析を含む継続運用を専門家に任せたい場合は、お気軽にご相談ください。