2025/10/04(土)Gmailにも届く、完璧なメーリングリスト(ML)の作り方（特にビジネス）
メーリングリストは生きている
「ファックス」はいずれなくなるといわれつづけ、しかし一部では現役で使われています。ML(メーリングリスト）も、Slackなどの導入で不要になる、と言われ続け、しかしまだ現役で使われています。
一方で、需要減に対応してか、各レンタルサーバー会社では、MLの機能提供がなおざりになっている状況もみてとっています。
そこでここでは、さくらインターネットを例にとって、メーリングリスをより使いやすくするための技術的tipsをご紹介します。
この記事は、レンタルサーバーでメーリングリストを運用しており、メールが届かない・迷惑メール扱いされるといった問題に悩む技術担当者向けです。
現状のメーリングリストの問題点
運用上の問題点 reply-to
メーリングリスト+Ccで他のアドレス（MLメンバーではないアドレス）がある場合、通常、「全員返信で返信します」。ところが、多くのメーリングリストサービスは、reply-to ヘッダが、MLアドレスまたはFromアドレスの二択（あるいはどちらか一択）の場合がほとんどです。
しかし、実務ではこんな問題が起きます。
あるメール
To: ml<mladress@example.com>Aさん、BさんはMLの登録メンバーではありません。
From: Aさん<a-san@example.com>
Reply-to: ml<mladress@example.com>
Cc: Bさん<b-san@example.com>
これに全員返信すると、
To: ml<mladress@example.com>となり、肝心のAさんが宛先から抜けてしまう！のです。
Cc: Bさん<b-san@example.com>
しかし、返信した人は「全員返信」しているつもりなので、Aさんにも届いていると誤解したままコミュニケーションミスが発生する、ということがビジネスの現場でたまにみられます。
では、常にreply-to を、投稿者(Fromのアドレス)にしてしまうとどうでしょう。
To: ml<mladress@example.com>これに全員返信すると、
From: Aさん<a-san@example.com>
Reply-to: Aさん<a-san@example.com>
Cc: Bさん<b-san@example.com>
Tp: Aさん<a-san@example.com>となり、きちんと全員返信の目的を達成できます。
To: ml<mladress@example.com> ※Ccとなるメーラーもある
Cc: Bさん<b-san@example.com>
ところが、これも問題があります。
仮に、Aさんが登録メンバーだったらどうなるでしょうか。
全員返信すると結果は同じですが
Tp: Aさん<a-san@example.com>Aさんには、同じ内容のメールが2通届きます。
To: ml<mladress@example.com> ※Ccとなるメーラーもある
Cc: Bさん<b-san@example.com>
また、このようなやりとりを他のMLメンバーも参加してお互いに投稿すると、toやcc にMLメンバーのアドレスがどんどん追加されて、宛先欄が汚れるだけではなく、余分なメールが行き交うようになります。
そこで以下のように解決すべきと考えています。
① Fromが、MLメンバーの場合には、reply-to はMLアドレスで問題ない。これで、上記の不具合は解決します。※解決策は下記にて。
② Fromが、MLメンバーではない場合には、reply-to は、FromアドレスとMLアドレスを加える*1。
③ ただし、元のメールにreply-to の設定がある場合には、それのみを生かす。
※google-groups も似たような挙動をします。
受信できない問題
昨今、迷惑メール対策として、いわゆるFrom偽装や、内容改変のあるメール、転送メールに対して、受信サーバーが強硬な姿勢で、メールの受信拒否をしています。Gmailが筆頭で、yahooメールは、通信会社関係も強きの受信拒否をしています。
そうすると、MLメールが受信拒否されたり、あるいは、受信できても迷惑メールに振り分けやすくなります。
ビジネスではメールを受信できていない（+迷惑メールになりやすい）、というのは致命傷ですので、なんとかする必要があります。
そこで、①受信サーバーに受信されやすくする、②受信後、迷惑メールに分類されにくくする、と問題にわけて、それぞれの方策が必要となります。
MLは、いったんMLが運用されているサーバーが受信したうえで、A:必要な加工をして、再度、B:MLサーバーが各登録メンバーに送信する作りになっています。
転送はメールをそのまま“通過”させますが、MLは“再送信”する点が、メール転送とMLの違いです*2。
Aの問題
通常、Subject(件名）を書き換えます。[ml-No:0001]みたいな番号をSubject(件名）の先頭につけます。最近はDKIMという仕組みがほぼ必須となっているのですが、このように重要ヘッダであるSubjectヘッダを書き換えると、DKIM=fail となり、内容改変メールと判定されます。
すると、上記①②の問題が発生しやすくなります。
DKIMが壊れているので、当然にDMARCのDKIMアライメントもfailとなります。
※DKIMアライメントとは、DKIMで署名に使われたドメインとFromのドメインの一致(alignment)を確認することです。
DKIMなどの仕組みは、メールセキュリティ覚書(SPF,DKIM,DMARC)を参照してください。
Bの問題
SPFという正当な送信サーバーから送信されているか、をチェックする仕組みがあります。具体的には、SMTPコマンドMAIL FROM（エンベロープFrom→Return-path:）と、送信サーバーのIPアドレスを取得し、それがMAIL FROMのドメインに設定されているSPF情報と整合性があるかを検証します。
多くのMLサーバーは、自身でMAIL FROMを投稿者ではなく、自らのMLドメインに変更するので、MLドメインでのSPF は pass (成功）します。
正当なサーバーからの送信として解釈されることとなります。
ところが最近は、DMARCというFrom偽装を防ぐ仕組みであり、このMAIL FROM（エンベロープFrom→Return-path:）とヘッダーFromドメインを一致を確認し、それがfailだと、DMARC もfailします。
この場合でも、DKIMが通っていて、DMARCのDKIMアライメントが通っていればいいのですが、上記のとおりDKIMは壊れているので、DMARC も fail します。
すると、このメールはFrom偽装のなりすましメールだということとなり、受信拒否されやすくとなります。
技術的な表現
内容改変によって、DKIMが壊れるので、MLが再度、自身のドメインでDKIM署名しないとDKIMは通りません。ARCによって、一定の信頼チェーンは作れますが、これをどう解釈するかは受信側に委ねられており、完全な対応ではありません（もちろんARCはあったほうがよい）。
すると、DKIMが壊れている以上、DMARCのDKIMアライメント（署名ドメインとFromドメインの一致）も fail します。
同様に、SPFがpassしても、DMARCのSPFアライメントが通りません。
受信できない問題の解決策
現実的な解決策として以下が考えられます。FromをMLアドレスとすることで、DMARCのSPFアライメントを成功させ、DMARC pass とする。DMARCを pass するので、受信確率がぐっと上がります。
ただし、このFromアドレスの変更をするには、ビジネス上の留意点があります。
それは、Fromの表示名、です。
このFromの表示名まで、MLの名前が表示されるようになると、誰からのメールかについてすぐにわからない（本文読まないとわからない）、ということになるのです。
実際の投稿者は、
From: Aさん <a-san@example.com>なのに
From: tips456のML <ml@tips.net>みたいになるのです。これでは困ります(エックスサーバーはこの仕様なのでビジネスで使いづらい。）。
そこで解決策は、
- Fromのアドレスは、MLアドレスであるが
- Fromの表示名は、投稿者の名前
さらに発展形としては、
- Fromのアドレスは、MLアドレスであるが
- Fromの表示名は、"投稿者の名前_via_ML"
Fromヘッダは以下のようになります。
From: "投稿者の名前_via_ML" <ml@tips.net>また技術上は、例えば X-Original-From として
X-Original-From: （投稿者の表示名とメールアドレス）というぐあいに、投稿者の投稿時のFromを残しておくことは有用です。
MLサーバーでDKIMを再署名できないの？
理論上はできると思いますが、さくらインターネットで試みたところ、できませんでした*3。おそらくMLはARC対応で十分と考えているのでしょう。
もし、MLがDKIM再署名しているサーバー等をご存じの方は教えてください。
追記:
google-groups は、MLサーバーで再署名しています。さすがですね。
さくらインターネットではなぜできないのか、くやしいの～。
整理
これまでの議論で、以下のことをすれば、ビジネス上も実務に耐えるメーリングリスト運用ができることとなります。- Fromヘッダについて、アドレスはML、表示名は投稿者+via_MLに変換することで、受信確率を上げて（ほぼ大丈夫）、迷惑メールに分類させる確率を下げる（メールの内容次第）。
- Reply-toは、投稿者がMLメンバーかどうかによって、投稿者のアドレスをいれるかどうか振り分ける
さくらインターネットMLでFromを書き換えてSPFalignmentを成功させる
という記事を投稿しております。これでばっちりです。
ただし、これを メーリングリストプログラムのfmlに組み込むのは、ほんのちょっと、サーバー管理の知識が必要です。しかし、怖がるほどのものではないと思いますので、頑張って設定してみましょう。一度やればあとは簡単です。
どのサービス（レンタルサーバー）を使用するか
私は、さくらインターネットを長く使っており、このレンタルサーバーの議論しかできません*4。最近、縁あってエックスサーバーを触る機会があったのですが、ユーザーの自由度が低く、上記の設定が（たぶん）できないので*5、オススメできません。
追加的施策
不要なヘッダの削除
どうせfailするDKIMヘッダなどをMLサーバーが削除しておければ、受信側のネガティブ要素を無くすことができます。ただし、この措置はかえって偽装メールと判断されかねない要素なので、必須ではないと考えています。
いずれこの点も記載したいと思います。
その他
こちらのサイト https://mekiku.com/view.php?a=89 は、簡潔な方法で解決されています。エレガントでいいですね。これでもいいと思います。ただし、Fromの表示は単に投稿者のFromをそのまま流用しているだけとなります。
この場合、投稿者からの送信かML経由が一目ではわからないので、当サイトでは、_via_ML を付ける方法をご紹介しています。マルチバイトに対応するために、MINEデコード、エンコードもしていますので、スクリプトが長くなっています。
まとめ：ビジネスMLの完璧運用を今すぐ実現
メーリングリスト（ML）は、非同期コミュニケーションの強力なツールですが、DMARC/SPF/DKIMの認証失敗による受信トラブルが最大の敵です。これを解決する鍵は以下の3ステップ：- Fromヘッダの書き換え：MLアドレスをFromに設定し、表示名で「投稿者_via_ML」と明記。SPFアライメントを確保し、配信率を劇的に向上。
- reply-toのスマート設定：投稿者がMLメンバーならMLアドレス、非メンバーならFrom+MLの組み合わせに。Reply Allの混乱を防ぎ、コミュニケーションをスムーズに。
- さくらインターネット活用：DKIM再署名不可の制約をFrom書き換えでカバーし、ARCで信頼性を補強。Xserverのような柔軟性の低いサービスは避けましょう。
これらを実装すれば、ビジネスMLはスパム判定を回避し、確実に届く「完璧なツール」へ。fmlなどのMLソフトに組み込む際は、テスト運用からスタートを。あなたのチームの生産性を高める一手、ぜひ試してみてください！