ARC 認証の深掘り｜転送で DMARC が崩れる問題を救う仕組みを Web 担当者向けに整理

この記事でわかること

• 転送経由で 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 で弾かれます。

ARC が解決する範囲

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

• 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 が崩れる対処も併読してください。

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

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

関連記事: ARC（Authenticated Received Chain）とは / DMARC とは？ / メールヘッダの読み方