4 ポイント 投稿者 GN⁺ 2025-10-05 | 1件のコメント | WhatsAppで共有
  • 自前でメールサーバーを運用すると、低コストで自動化処理やメーリングリスト管理が可能
  • 現実的には 配信信頼性 の問題があり、大手サービスとのメール送受信に失敗する可能性がある
  • Postfix と OpenDKIM の設定だけで、基本的な SMTP と認証付きメール送信システムを構築できる
  • SSL 証明書、DKIM、SPF、DMARC の設定により、メールの信頼性と送信時のセキュリティを改善できる
  • PTR(逆引き DNS)レコードまで設定すれば、大手メールサービスへの到達率向上が期待できる

概要

自前でのメールサーバー運用は、メーリングリスト、ニュースレター、メール認証 API などの自動化処理に有用
しかし最大の現実的課題は メール配信の信頼性 であり、メールが正しく届かなかったり受信に失敗したりするリスクがある
運用者はこうしたリスクを受け入れることを前提に、この方式を個人プロジェクトに適用している
自前運用の利点は、追加コストがほとんどかからない点で、既存のウェブサイトにソフトウェアをインストールするだけで 済み、ストレージや電力消費もごく少ない
メールサーバーの運用は非常に難しいと思われがちだが、実際には SaaS 型メールサービスの構成と比べて難易度に大きな差はない
設定のしやすさと単純化のため、ウェブメール、マルチユーザー環境 はひとまず省略し、ユーザーアカウント、データベース、ウェブインターフェースの構成を不要にしている
今回の構成は単一アカウント運用に適しており、必要であれば SSH や mailx, sendmail, mutt などを通じてメールの送受信が可能
今後、必要に応じて拡張やウェブメールの追加も検討できる

Postfix

基本的に ポート 25 を開放し、PostfixOpenDKIM をインストールして設定するだけで、基本的な SMTP サーバーを構成できる
ほとんどのメールサービス(Gmail など)へ安定してメールを届けるには、OpenDKIM(メール認証)が必要
運用者は master.cf はデフォルト値のままとし、メイン設定(main.cf)の例では TLS 暗号化、DKIM 連携 などの中核設定のみを示している
POP3/IMAP は設定せず、必要なら SSH で直接サーバーに接続して mailx などのコマンドでメールを送受信できるよう単純化している

TLS(転送時暗号化)

SSL 証明書 は SMTP サーバーとのデータ転送を暗号化するために必要
ドメインごとに証明書を発行する必要はなく、メールサーバーが置かれている単一ホスト(MX レコード用)にだけ証明書があれば十分
たとえば MX レコードが mx.example.com なら、そのドメインに対してのみ Let’s Encrypt の無料証明書を取得して適用すればよい
TLS はサーバー間の送受信区間だけを暗号化 し、実際の送信ドメイン名の認証とは別物
したがってメールアドレスの From ヘッダーには、任意の値を自由に設定できる

DKIM, SPF, DMARC

DKIM は、そのメールが本当に自分のドメインから送られたことを証明し、メールの信頼性確保に使われる
OpenDKIM で各ドメインごとの鍵ペアを作成し、公開鍵を DNS の TXT レコードとして登録する
鍵は自動では失効しないが、定期的なローテーションが推奨される
SPF, DMARC の TXT レコードも DNS に追加し、どのホストがメール送信可能か、および DMARC ポリシー(例: 認証失敗時に拒否)を設定する
設定ファイルの例(opendkim.conf, KeyTable, SigningTable, TrustedHosts)では、各項目の設定方法を明確に確認できる
DNS には MX、SPF、DKIM、DMARC 関連のレコードだけを追加すればよい

逆引き DNS(PTR)

PTR レコード(逆引き DNS) はメールサーバーの信頼性を高め、Gmail などの大手サービスでメールがブロックされにくくなる可能性を高める
ISP に連絡して、メールサーバー用の PTR レコード設定を依頼する必要がある
実際の配備環境では PTR レコードがなくても Gmail、GMX、Outlook などで正常に受信され、mail-tester.com で 10/10 点を獲得した
PTR 未設定による減点要因はあったが、"trusted relay" により加点を得た
ブラックリストにも登録されておらず、送信 IP の信頼性も良好

Gmail 送信テスト

sendmail コマンドで Gmail 宛てにテストメール(HTML メッセージ)を送信
Gmail では即座にメールが到着し、TLS 暗号化が確認 された
"Show original" で元メールを確認すると、SPF、DKIM、DMARC の認証を通過している
mailx を使えばローカル(サーバー)で受信メールの内容を確認できる
設定に問題がある場合は、DNS、証明書、DKIM キーのアクセス権などを再確認する必要があり、特に OpenDKIM の設定ファイルはタイプミスに敏感

次のステップ

次の記事では Python でメールアプリケーション を作る方法を紹介する予定
問い合わせや意見があれば max@idx.cy まで連絡可能

1件のコメント

 
GN⁺ 2025-10-05
Hacker Newsの意見
  • 20年以上メールを自前でホスティングしてきたことを誇りに思っており、今後も続けるつもりです。実際のところ、政府や関係省庁ですらメールシステムを自前で運用できておらず、国家のセキュリティ部門だけが直接ホスティングしています。運が良かったのか、送信トラブルはほとんどなく、最近覚えているのは Microsoft が自分のメールを飲み込んだ件くらいですが、あれは古い exim と outlook 側の TLS 認証の食い違いが原因でした。設定を1つ調整して解決しました。保守にはそれほど手間がかからず、何か触るたびに新しいことを学ぶ機会だと捉えています。今年は Debian jessie から Arch Linux に切り替え、cron ジョブも完全に systemd タイマーへ移行しました。重要なメールを送るときは必ずサーバーログを確認しますが、これも自分でログを見る良い習慣だと思っています。助言するとすれば、自前ホスティングを趣味として楽しめるなら、ずっと良いものになります。最後に、Debian で Exim の設定を考えた人は大量の時間を無駄にさせた張本人です。Debian で Exim を構築するなら、公式の Upstream 設定に切り替えて、自分向けにカスタマイズするのが正解です

    • 最近の SNS は「分散化」や「オープン」を強調して誇っていますが、実際には私たちには独立して完全に自立できるツールがすでにあります。UX を改善すると言いながら、実際にはユーザーの主導権が失われている点を見落としがちです。結局、過度に単純化されたシステムに慣れてしまうと、将来は誰かが遠くから「取引」を許可しない限り、アプリ1つすらインストールできない世界になります

    • 大学時代(WWW 以前)に初めてメールを使い、その後は ISP アカウント(非常に限られた保存容量で POP のみ対応)だったので、自分でメールサーバーを動かすようになりました。常時インターネット接続ではなかったため、リレーとダイナミック DNS でメールを受信していました。現在は VPS を経由して自宅サーバーでメールを受信・保存しています。ここ数年の間に、Outlook などの大手メールサービスに IP やドメインの解除を依頼しなければならなかったこともありますが、そう頻繁ではありませんでした。世界のメールをたった2、3社が支配する世界には住みたくないので、こうした自前ホスティングは小さな抵抗行為だと思っています

    • 昔の20年前ほどのやる気が、今も1%でも残っていてくれたらと思います。今はフルタイムの仕事と家族(妻と子ども)がいて、そういう作業に割ける時間がありません

    • 自分も一時期は自前ホスティングから離れていましたが、時間とコストのバランスが変わってきたので、またやる価値があるか考えています。メールホスティングで一番悩ましいのはスパム対策です。最近はどうなっているのか、何かコツがあればぜひ共有してほしいです

    • 私にとってメールは非常に重要なサービスです。15年間自前でホスティングしたあとやめた理由は、1) 定期的なバックアップ/復元と監視がうまくできていなかったこと、2) 災害復旧計画がなく、他のサービスよりコストがかかったこと、3) セキュリティに常時気を配れなかったことです。友人のサーバーはランサムウェアにやられてデータを全部失いましたが、私は FreeBSD だったので無事でした(攻撃対象ではなかった)。一般的には保守は複雑ではありませんが、一度こじれると本当に大変で、致命的になり得ます

  • 以前はメールを自前でホスティングしていましたが、やめた理由は評判ではなく、100% の稼働率を避けられず、メール消失やブラックリスト登録のリスクがあったからです。メールのプロトコル上はダウンタイムに強いはずですが、現実には大手メールプロバイダーは一度でも問題が起きるとすぐにメールを拒否し、再試行しません。以前の GitHub も一度バウンスすると「受信不可」と記録し、その後はメールをまったく送ってきませんでした。今は改善されましたが、現代のメールシステムは「常時オンライン」を前提にしています

    • 私のメールサーバーは、初回のメールを意図的に拒否するグレイリスティング機能を使っています。非常に多くのメールを受け取ってきましたが、正常なメールが未配達になった例は一度もありません。再送はメール標準に組み込まれているので、心配なら予備の受信メールサーバーを追加し、LMTP でバックホールすればよいです。メールという仕組み自体が、もともと24時間常時接続ではない時代を考慮して設計されたものです

    • そういう話は誇張です。私の場合、メールが来ないと数時間後か1日後にまた届いていましたし、どこで問題が起きたのか普通は知る方法がありません。ちゃんと認証しておけば(たとえば dkim, spf)、自前ホスティングでも 99% 以上の到達性は確保できます。複雑さに怖気づく必要はありません。おまけに caldav も個人的に活用できます

    • サーバーが数時間落ちたくらいで、なぜ「メール消失」を心配するのか不思議です。私のサーバーは 219 日連続稼働中です。普段私たちがやっている仕事に比べれば、メールサーバーの運用は本当に簡単な部類です

    • 本当に最近のメールシステムを見ると、「息子に何をしたんだ」という気分になります

  • メールの自前ホスティングを始めたい人への助言です。まずはアカウント登録用としてだけ自前ホスティングのメールを使ってみてください。最初から個人的な連絡用にする必要はありません。Mail-in-a-box を使えば、https://mailinabox.email./ のインストールガイドに従うだけで数時間で構築でき、ちゃんと動きます。1〜2年使って十分に慣れてから、その時点で個人的な連絡用へ移すことを勧めます

    • Stalwart https://github.com/stalwartlabs/stalwart を勧めます。単一バイナリで完結したメールサービスなので依存関係がなく、インストールや更新がとても簡単です。いろいろなプロジェクトを試しましたが、Stalwart が一番手軽で、問題もなく動いています

    • MIAB をクラウドで何年も運用しています。IP の評判さえきれいなら送信も問題ありませんが、Outlook 側にメールが届かないときは Microsoft postmaster に直接メールして解決しています。DKIM/SPF/DMARC の設定なども学べるので、学習には良くておすすめです。ただし、会員登録メールの受信が本当に大変です。MIAB のグレイリストは初回送信者を拒否して再試行を待ちますが、まともなサイトですら再試行しないことがよくあります。認証用や2段階認証コードのメールが届くまでかなり時間がかかり、スパムフィルターを一時的に無効化する簡単な方法もありません

  • 最近は ISP 提供メールでも、Google Gmail でさえ、スパムフィルタリングなどで時々問題が起きます。例として Shopify 経由で注文すると、shopify のメールが Gmail でずっとスパム扱いされます。DMARC、SPF、DKIM をすべて通過していても、なぜ引っかかるのかわからないほどです。メールの送受信自体は技術的に難しくなく、どのサービスを使っても 100% 完璧ではありません。悪意ある利用者(スパマー)があまりに多いため、この仕組みがここまでうまく回っていること自体が不思議なくらいです

    • DMARC、SPF、DKIM などは認証に関する設定にすぎず、スパムかどうかとは直接関係ありません。きちんと認証されたゴミメールもあれば、認証されていない宝石のようなメールもあります

    • Shopify のメールがスパム分類される理由は、Shopify が多くの人にスパム指定されているか、共有メールサーバーに評判の悪い利用者がいるからです。私が何度「スパムではない」と表示しても、送信者全体の評判が悪すぎるとスパムフォルダから抜け出せません

    • 私は20年近くメールを自前ホスティングしています。10〜15年の間はすべてのメールを Gmail に転送していましたが、重要なメールまで消してしまうスパムフィルターにうんざりして、自分で imapd を動かし始めました。SPF などをきちんと設定しておけば、自前ホスティングのほうがはるかに良いと感じます

    • こういうフィルタリング方針こそが問題です。自前ホスティングや小規模メールサービスを使うほうが、むしろメールが遮断されることはずっと少なくなります(特に Gmail などの厳しすぎるフィルターに対して)。Google はスパムの主犯である Gmail ユーザーを大量に抱えているのに、それでも頻繁なフィルタリング方針を維持しています

    • 最近の Gmail のスパムフィルターは、マーケティングメールに対して過敏すぎます。10年前は逆の問題でしたが、今はスパムフォルダに入りすぎてうんざりするほどです。むしろ最近のスパムのかなりの部分は、小規模な新規メールアドレスから来るコールドメールです。Gmail のマーケティングメールは「配信停止」機能がよく働きますが、こうしたコールドメールには役に立ちません

  • 完全な構成と、さまざまなクライアントと連携可能な IMAP サーバーを望むなら、https://workaround.org/ispmail-bookworm/ のガイドのほうが適しています。私はデータベースの代わりに平文ファイルで簡単に運用しています。利用者が自分だけならこれでも十分で、このガイドは大規模企業向けにも十分拡張可能です

    • 私も上のガイドを使っていますが、データベースは PostgreSQL に置き換えています。最近 Trixie にアップグレードしたあと Dovecot の設定が大きく変わって少し苦労しましたが、今は問題なく動いています
  • 露骨な宣伝です。私たちはセルフホスティングの代替を作る Hyvor Relay https://github.com/hyvor/relay をベータテスト中です。DKIM/SPF の監視や DNS 自動化など、可視性に重点を置いています。Docker compose up を一度実行するだけですぐ運用できます https://relay.hyvor.com/hosting/deploy-easy

  • 10〜15年ほど、安価な kimsufi ボックスで opensmtp、dovecot、rspamd を使ってメールを自前ホスティングしてきました。特に問題はなく、一度だけ telekom.de にサーバーをブロックされたことがありますが、正式なメールで説明したらすぐにホワイトリストへ入れてくれました。IP を長く保持しているからか、個人的には皆が言うような問題を感じたことはありません。ただし、サーバーと IP は自分名義で所有しています

  • Debian trixie ベースの自前メールホスティングに関するドイツ語の記事を https://krei.se/Doc で共有しています。きちんと自分で構築すると本当に楽しいです。自動更新と再起動、カスタム systemd により、毎日状態レポートをメールで受け取っています。2〜3年、trixie なら最大5年は手を入れなくても安定して動きます。メールサーバーソフトウェアはすでに十分成熟しています。自前ホスティングを勧めます。自律性と平穏、そして自分で制御できることには大きな価値があります

  • 10年以上メールを自前運用しており、以前の HN コメントも時々リンクとして残しています(例: 39891262, 38471262)。Digital Ocean の IP が悪性扱いされたため、送信は Amazon SES に置き換え、Gmail を無料のスパム訓練器として使って自前フィルターに活用しています(38843288)。多くの人が言及しているように、グレイリストは大いに役立ちます。まともなメールサーバーは必ず再試行するので、2FA などでは不便ですが、仕組みとしては信頼できます。数日ダウンしても心配はなく、受信/保存サーバーを分離してバックアップもしやすいです(38512732)。2FA メールについては https://github.com/stevejenkins/postwhite も併用していますが、実のところメールを 2FA 用に勧めたいとは思いません(この話題は別途議論が必要です)

    • 最近、Amazon SES から送られた重要なメールをスパムブロックリスト(bl.spamcop.net)のせいで受け取れませんでした。Amazon が複数の IP で再試行する中でグレイリストに遭遇し、結局一度は拒否されました。大手同士(MX 間)の送信ではそれほど問題にならないかもしれませんが、こうした構造も 100% 完全な解決策ではありません

    • 結局、長々と話しても、要するに Gmail などの大手メールサービスを使うほうがよいという結論のように思えます

  • UUCP はどこへ行ったのか、なぜアドレスが bang path ではないのか、sendmail.cf はどこへ消えたのか、という気持ちです

    • その通りです。1984年式(古典的 email)で自前ホスティングしようとすると、すべてのメールを中継するオープンリレーになり、各種脆弱性にさらされて危険です

    • あの頃を思い出すと、大学の研究室で Unix ワークステーション6台を使い、あるサーバーから別のサーバーへ email を移していた時代、ディスクの音でメールの行き来を感じていた思い出があります

    • 私もタイトルを見て、bang path と killer!jolet! アドレスを思い出しました。本当に懐かしい時代です

    • 同感です。『1984』というタイトルに釣られて入ってきたのに、実際には『postfix の設定』の話でがっかりしました