ARCとは｜転送メールが認証で落ちる問題の解決策
目次
この記事でわかること
- ARC が解決する「転送するとメールが届かなくなる」問題の正体
- ARC ヘッダーで何が記録され、どう検証されるか
- 中小企業が DMARC を
p=rejectまで強化する前に知っておくべきこと
「メーリングリストに転送したら届かない」問題
社内のメーリングリストや、Gmail の自動転送ルールでメールを送っているのに、転送先で迷惑メール扱いされる、または届かない ── という事象を経験したことはないでしょうか。
これは故障ではなく、SPF / DKIM / DMARC の仕組み上、避けられない副作用です。
転送が認証を壊す典型例:
- メーリングリストが件名に
[ML名]を付ける: DKIM 署名が崩れる - 転送時に Subject や本文の改行コードが書き換わる: DKIM 署名が崩れる
- 転送サーバーの IP が SPF の許可リストにない: SPF が fail する
From:を MLM(メーリングリスト管理プログラム)が書き換える: DMARC のアラインメントが崩れる
つまり、「転送するたびに認証情報が壊れる構造になっている」ことが、ML やメール自動化の世界での歴史的問題でした。詳しい認証の役割はSPF・DKIM・DMARC の違いを参照してください。
ARC は「転送経路の認証チェーン」を残す仕組み
ARC(Authenticated Received Chain、認証済み受信チェーン)は、RFC 8617 で標準化された仕組みで、転送を経由したメールにも「途中の認証情報」を引き継ぐことができます。
仕組みは次のとおり:
- 元の受信側(ML サーバー等)が、その時点で SPF / DKIM / DMARC の認証結果を判定
- その結果を ARC ヘッダーに記録し、自分の署名(ARC-Seal)を付ける
- 次の転送先は、ARC ヘッダーを見て「途中で認証は通っていた」と判断できる
最終的な受信側(社員の Gmail / Outlook 等)は、SPF / DKIM が直接 fail していても、ARC チェーンで「途中までは認証が通っていた」ことを確認できれば、メールを正規メールとして扱える、という設計です。
つまり 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強化の手順でも触れていますが、p=quarantine や p=reject に進めると、転送経路で認証が壊れた正規メールも止めてしまうリスクがあります。
ARC が機能していれば最終受信側で救済されますが、すべての受信側が ARC を活用してくれるとは限らないのが現実です。DMARC を強化する前に、
- 御社のメールが取引先のどこへ転送されているか
- その転送先が ARC を活用しているか
を DMARC レポートで見ておくのが安全です。詳しくはDMARC レポートの読み方で扱っています。
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 や自動転送でどう扱われているか、現状を把握するなら、まず無料のドメイン診断で SPF / DKIM / DMARC の状態を確認できます。DMARC を導入していれば、レポート(rua)で転送経路の認証状態が見えるようになります。
DMARC レポート分析を含む継続運用を専門家に任せたい場合は、お気軽にご相談ください。