メーリングリストでDMARCが失敗する理由
目次
この記事でわかること
- メーリングリスト(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 アライメントの仕組み、トラブル全般の原因切り分けはDMARC fail のトラブルシューティングを併読してください。
影響範囲は思ったより広い
「自社では 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 とは何かで解説しています。
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: [email protected]
変更後: From: [email protected]
Reply-To: [email protected]
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 に以下を追加します。
[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 対応プラットフォームへの移行も検討してください。
設定状況がわからない方は、無料のドメイン診断で現状をチェックできます。 DMARC・SPF・DKIM・SSL の状態が数十秒でレポートされます。 判断に迷う場合はお問い合わせからご相談ください。専門家がわかりやすくサポートいたします。