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

- メーリングリスト(ML)経由のメールが DMARC で失敗する根本原因
- ARC 署名・From 書き換えなど受信側で再認証させる仕組み
- 自社で ML を運用する場合の Mailman 3 設定例

## なぜ ML 経由のメールは DMARC で fail するのか

ML(メーリングリスト)は、購読者全員に同一メールを配信するために、**元のメールを取り込み → 加工 → 再送信**するフローを取ります。この「加工」のステップで、DKIM 署名と SPF 認証の前提が崩れます。

典型的な改変内容:

- 件名への `[list-name]` プレフィックス追加
- 本文末尾への購読解除リンク・スポンサー文言の追加
- Reply-To ヘッダの書き換え
- MIME 構造の変換(text/plain と text/html の組み替え)

DKIM 署名は本文と一部ヘッダのハッシュをカバーしているため、本文や Subject が変わると **署名検証が fail**します。SPF も、ML のサーバー IP が元ドメインの SPF に含まれていないため fail します。

その結果 DMARC は SPF/DKIM のどちらも align しない状態となり、From ドメインが `p=reject` の場合は購読者全員に届かなくなります。

DMARC の判定ロジックは[DMARC アライメントの仕組み](/blog/dmarc-alignment-explained)、トラブル全般の原因切り分けは[DMARC fail のトラブルシューティング](/blog/dmarc-fail-troubleshooting)を併読してください。

![ML 経由メールで DKIM 署名が壊れる流れ](/blog/mailing-list-dmarc-failure/dkim-break-flow.svg)

### 影響範囲は思ったより広い

「自社では ML を運用していないから関係ない」と思いがちですが、実際には次のような場面で問題が顕在化します。

- 業界団体や勉強会の ML に社員が投稿 → 配信が止まる
- 取引先の社内 ML に営業メールを送ったが届かない
- お客様サポートで使う問い合わせ ML(info@ → 担当者複数転送)で配信失敗

DMARC を `p=reject` で運用している企業が増えるほど、ML 経由の配信失敗も増える構造です。Yahoo! が 2014 年に `p=reject` を採用したとき、世界中の ML が大規模配信障害を起こしたのは有名な事例です。

## 解決策 1: ARC 署名による検証チェーン

ARC(Authenticated Received Chain、RFC 8617)は、**メールが転送される過程で各ホップが署名を追加していく仕組み**です。最初の DKIM 署名が ML の改変で壊れても、ML 側が「自分が受け取った時点では DKIM が pass していた」という証跡を ARC 署名として残します。

下流の受信サーバー(Gmail 等)は ARC チェーンを検証し、**信頼できる中継サーバーが pass を付けていれば DMARC を救済**する判定を行えます。

ARC の詳しい仕組みは[ARC とは何か](/blog/arc-what-is)で解説しています。

![ARC 署名チェーンによる検証パスの再確立](/blog/mailing-list-dmarc-failure/arc-chain.svg)

ARC を実装している主要 ML プラットフォーム:

| プラットフォーム | ARC 対応 | 備考 |
|---|---|---|
| Google Groups | 対応済 | 自動的に ARC 署名を付加 |
| Microsoft 365 配布グループ | 対応済 | テナント既定で有効 |
| Mailman 3 | 対応(要設定) | DKIMSign プラグインと併用 |
| Mailman 2 | 非対応 | 移行検討推奨 |
| ezmlm | 非対応 | パッチ実装の OSS あり |
| Sympa | 6.2.62 以降で対応 | 設定で有効化 |

ただし ARC はあくまで**受信側の判断材料**であり、Gmail のように ARC を考慮するサーバー以外では救済されません。万能策ではない点に注意が必要です。

## 解決策 2: From ヘッダの書き換え

ML 側が **From ヘッダを ML 自身のアドレスに書き換える**方式です。元の送信者は `Reply-To` か本文先頭に置きます。

```
変更前: From: tanaka@example.co.jp
変更後: From: list@ml-host.org
        Reply-To: tanaka@example.co.jp
```

From ドメインが ML 側のものになるため、ML が自分の DKIM/SPF で正しく認証すれば DMARC は pass します。Mailman の `from_is_list` オプションや、`dmarc_moderation_action` の `Munge From` 設定で実現できます。

トレードオフは「元の送信者の所属が見えにくくなる」「アドレス帳の自動補完で混乱する」点。社内向け ML では許容しやすい一方、対外的な議論メーリングリストでは違和感が大きく、運用ポリシーで合意形成が必要です。

## 解決策 3: 配信元ドメインを ML 専用に分ける

DMARC を `p=reject` で運用する基幹ドメインとは別に、**ML 投稿専用のサブドメイン**を切る方式もあります。

例:
- 基幹: `example.co.jp`(`p=reject`)
- ML 用: `ml.example.co.jp`(`p=none` または `p=quarantine`)

社員が ML に投稿する際は ML 用ドメインから送ることで、基幹ドメインの厳格ポリシーを保ちつつ ML 配信を成立させます。サブドメインポリシーの設計は別途記事で扱います。

### Mailman 3 で ARC を有効にする設定例

自社で Mailman 3 を運用している場合、ARC 署名を有効にする設定例を示します。`mailman.cfg` に以下を追加します。

```ini
[ARC]
enabled: yes
authserv_id: ml.example.co.jp
selector: arc2026
privkey: /etc/mailman3/arc-private.key
trusted_authserv_ids: mx.example.co.jp
```

事前準備として ARC 用の鍵ペアを生成し、公開鍵を `arc2026._domainkey.ml.example.co.jp` の TXT レコードに登録します(DKIM 公開鍵と同じ書式)。`authserv_id` は受信ホストの識別子で、DNS 名と揃えるのが一般的です。

設定反映後は Gmail 宛にテスト投稿し、受信ヘッダの `ARC-Seal:` `ARC-Message-Signature:` `ARC-Authentication-Results:` 3 行が記録されているか確認してください。

## まとめと自社の確認方法

ML 経由のメールは本文・Subject 改変で DKIM 署名が壊れ、DMARC fail を引き起こします。ARC 署名は中継サーバーが「自分が受けた時点で pass していた」と証言する仕組みで、Gmail などが下流で参照します。ARC が使えない場合は From 書き換え、または ML 専用サブドメイン分離が現実解です。自社で ML を運用しているなら Mailman 3 など ARC 対応プラットフォームへの移行も検討してください。

設定状況がわからない方は、無料の[ドメイン診断](/diagnose)で現状をチェックできます。
DMARC・SPF・DKIM・SSL の状態が数十秒でレポートされます。
判断に迷う場合は[お問い合わせ](/contact)からご相談ください。専門家がわかりやすくサポートいたします。