オープンソースプロジェクトに独自ドメインメールが必要な理由

コミュニティーを運営し始めた頃、私たちの「メールシステム」は一人のGmailアカウントだった。スポンサーからの問い合わせやセキュリティ報告は個人の受信箱に届いた。プレスからの問い合わせも、パスワードを持っている唯一の担当者が休暇中だったため何日も未読のまま放置される。新しい共同チェアが加わったとき、LINEでログイン情報を共有した。恥ずかしい話だが、この状態を改善するまでに驚くほど時間がかかった。

初日からプロジェクト用のメールを設定しておくべきだった。5分で終わる作業だ。それなのに、何年も「なんとかなっている」状態で走り続け、なんとかならなくなった瞬間にようやく問題に気づいた。

あなたのオープンソースプロジェクトがまだ誰かの個人メールアドレスで運用されているなら、この記事はあなたのためのものだ。

Gmailという問題

ほとんどのオープンソースプロジェクトは同じパターンで始まる。誰かがドメインを取得し、GitHubで静的なウェブサイトを立ち上げ、連絡手段は創設者が既に使っている個人メールになる。[email protected] がプロジェクト全体の事実上の連絡先になるわけだ。

一人で趣味の延長として開発しているうちは問題ない。しかし、以下のどれか一つでも起きた瞬間に破綻する。

1. バスファクター。 メールアカウントを管理しているのは一人だけ。その人が燃え尽きたり、プロジェクトを離れたり、単にパスワードを忘れたりすれば、プロジェクトの連絡手段が失われる。Pythonコミュニティでこれが実際に起きるのを何度も見てきた。
2. 複数メンテナーへの転送ができない。 スポンサーからパートナーシップの問い合わせが来る。Bobの受信箱に2週間放置される。Bobは本業が忙しい。他の誰もそのメールが届いたことすら知らない。
3. 送信者のアイデンティティが不格好。 プロジェクトはちゃんとしたドメインと洗練されたウェブサイトを持っている。しかしカンファレンス主催者に返信すると、メールは[email protected]から送られる。プロジェクトの公的な顔とメールアドレスの乖離は信頼を損なう。
4. セキュリティ報告が個人受信箱に届く。 誰かが脆弱性を発見し、READMEに書かれたアドレスにメールを送る。そのアドレスは二要素認証なし、2015年から使い回しているパスワードの個人Gmail。仮定の話ではない。よくある話だ。

共有Gmailアカウントも解決策にはならない。共有パスワードはセキュリティ上の負債だ。Googleの利用規約は厳密に言えばこれを禁じている。そして二人が同時にログインした瞬間、返信が衝突してスレッドが破綻する。

他のコミュニティープロジェクトのメンテナーとも話したことがあるが、パターンは驚くほど一貫している。「あとで直す」という暫定措置が既成事実化し、何か目に見える問題が起きるまでそのまま放置される。大抵はスポンサーからのメールの見落とし、一週間誰も気づかなかったセキュリティ報告、あるいは誰もチェックしていないアドレスに届いたドメイン更新通知がきっかけだ。

実際に必要なもの

良い知らせがある。オープンソースプロジェクトのメールは複雑である必要がない。ほとんどのプロジェクトに必要なのは、プロジェクトドメイン上のいくつかのエイリアスと、それぞれを適切な人の既存受信箱に転送する設定だけだ。

• hello@ または contact@: 一般的な問い合わせ用。コミュニティ対応担当者に転送
• security@: 脆弱性報告用。セキュリティチーム（一人でも）に転送
• sponsors@ または treasurer@: 財務関連用。予算管理担当者に転送
• press@: メディア対応用。プロジェクトの規模が十分であれば

共有パスワードは不要。別々の受信箱をチェックする必要もない。各メンテナーは毎日使っている自分の受信箱でプロジェクトのメールを受け取る。誰かがチームから離れるときは、転送先を変更するだけ。パスワードのリセットも、アカウントの移行も、引き継ぎの混乱も不要だ。

これは何年も前に誰かが教えてくれていればと思う部分だ。多くの人が持っている先入観は「プロジェクトメール＝メールサーバーの運用、もしくはGoogle Workspaceへの課金」というものだが、そうではない。既存ドメイン上の転送エイリアスだけで、プロジェクトのコミュニケーションに必要なものはすべて揃う。エイリアスの裏にいる人たちは、自分が普段使っている受信箱をそのまま使い続けられる。

メール転送ならメールサーバーは不要

プロジェクトメールを動かすためにVPS上でPostfixを運用する必要はない。メール転送はその名の通り、あなたのドメイン宛に送られたメールを、背後にある実際の受信箱に転送する仕組みだ。

設定はシンプルだ。ドメインのMXレコードを転送サービスに向け、エイリアスを作成し、それぞれの配信先を指定する。転送サービスが受信を処理し、既存の受信箱がそれ以外のすべてを処理する。

KaiMailはそういったサービスの一つだ（私が作ったサービスなので、その点は開示しておく）。しかし、どの転送サービスを選んでも原則は同じだ。Cloudflare Email Routing、ImprovMX、Forward Emailもそれぞれ同様のことを実現できる。重要なのは、プロジェクトのメールアイデンティティを個人のアカウントから切り離すこと。そしてそれをインフラの運用なしで実現することだ。

私のキャリアはSMTPの理解とメールサーバーの運用から始まった。メールインフラには特別な思い入れがある。しかし2026年の今、オープンソースプロジェクトが独自のメールサーバーを運用することは勧めない。転送サービスがまさにこの問題を解決するために存在しているのに、運用の負担を背負う意味がない。

5分でできるセットアップ

実際の手順はこうだ。

1. ドメインはすでにある。 プロジェクトにウェブサイトがあるなら、ドメインもある。難しい部分はもう終わっている。
2. MXレコードを転送サービスに向ける。 DNSレコード3つの作業だ。ウェブサイト用にCNAMEを設定したことがあるなら、これもできる。AWS Route 53を使っているなら、DNSコンソールを開いたついでに長いDKIMキーの扱い方も読んでおくといい。
3. SPFとDKIMレコードを追加する。 これを設定すると、転送サービスを経由したメールが認証チェックを通過する。GmailやYahooがDMARC enforcement を強化している今、これがないと転送メールがスパムフォルダ行きになる確率が高まっている。
4. エイリアスを作成する。 security@はAliceに。sponsors@はBobに。hello@は両方に。
5. テストメールを送る。 届くことを確認する。完了だ。

全作業にかかる時間は、プロジェクトの連絡方法をREADMEに書くより短い。

オープンソースプロジェクトはコストに敏感だ（それでいい）

オープンソースコミュニティに長く関わってきた身として、1円の重みはよく分かる。PyCon JPも、PyCon MYも、そして特にPython Asia Organizationもボランティアの時間と注意深く数えた予算で運営されていた。ほとんどのオープンソースプロジェクトも同様だ。メールエイリアスが数個必要なだけなのに、Google Workspaceのユーザー単位の料金を払うのは現実的ではないし、そうである必要もない。

メール転送サービスは通常、小〜中規模のオープンソースプロジェクトに必要なものをカバーする無料プランを提供している。1ドメイン、いくつかのエイリアス、適度なメール量。マーケティングメールを大量送信するわけではない。スポンサーからの問い合わせやセキュリティ報告を受け取るだけだ。無料プランで十分対応できる。

KaiMailの無料プランは1ドメインの基本転送と月300通のメールをカバーしている。週に十数通程度のメールを受け取るプロジェクトなら十分だ。ImprovMXやCloudflare Email Routingにもそれぞれ異なるトレードオフを持つ無料プランがある。重要なのは、コストがプロジェクトを個人Gmailのまま放置する理由にはならないということだ。

プロジェクトが転送だけでは足りなくなるとき

いずれ、転送だけでは不十分になる瞬間が来る。プロジェクトのドメインから返信する必要が出てきたとき（個人アドレスからではなく）、SMTP送信機能が必要になる。スポンサーへの返信が[email protected]ではなく[email protected]から届くべきだ。

KaiMailは有料プランでSMTP送信に対応しており、他のサービスも同様の機能を提供している。アップグレードパスは自然だ。まず転送から始め、必要になったら送信を追加する。初日に構築したセットアップから移行する必要は一切ない。

プロジェクトが成長して複数ドメイン（プロジェクト本体用と年次カンファレンス用など）や、より大きな送信量、受信メールをイシュートラッカーに流すwebhook連携が必要になれば、そういったオプションも存在する。しかしほとんどのプロジェクトは、無料の転送プランで長い間十分にやっていける。

プロジェクトには独自のメールアイデンティティが必要だ

コミュニティー活動の初期を振り返ると、メールの問題はあの手の「小さく見えて実は大きい」問題の典型だった。見逃されたスポンサーメール。未読のまま放置されたセキュリティ報告。認証情報が一人のLINEのチャット履歴にしか残っていない、うまくいかなかった引き継ぎ。

すべて回避できたことだ。すでに持っていたドメイン、転送サービス、5分のDNS設定。それだけだ。

あなたのオープンソースプロジェクトがまだ誰かの個人メールに依存しているなら、今日修正してほしい。楽しいインフラ作業だからではない（楽しくない）。プロジェクトのコミュニケーションが、一人の人間がGmailをチェックすることを覚えているかどうかに依存すべきではないからだ。

5分で終わる。これから入ってくるボランティアもスポンサーもきっと感謝する。

私自身もコミュニティ運営者であり、お役に立ちたいと考えています。オープンソースコミュニティの運営者やプロジェクトリーダーの方を対象に、無料アップグレードプログラムをご用意しています。該当される方は、ぜひご応募ください。