著者 メールのセルフホスティングは2026年も価値がある？
自分のVPSでメールを受信するのは簡単ですが、Gmailへの到達性が難関です。送信者評価や認証、port 587のリレーが必要な理由と、リレーを選ぶべきケースを解説します。
短い答え
2026 年でも、役割を2つに分けるなら、メールのセルフホスティングには十分な価値があります。自分の VPS で自分のメールを受信する運用はリスクが低く、問題なく機能します。受信側は自分であり、誰かが自分を信頼する必要がないためです。一方、大手メールプロバイダーに受け入れられるメールを送信する作業は別です。これは、自分で構築するのではなく、引き継いだ IP アドレスのレピュテーションに左右されます。
経験豊富な運用者が実際に採用している構成はハイブリッドです。自分のサーバーでメールボックスとアーカイブを保持し、外向きのメールは port 587 の認証済みリレー経由で送信します。送受信の両方を完全にセルフホスティングする構成が有利になるケースもいくつかありますが、それらはこの投稿の終盤で説明します。
自己ホスト型メールで難しいのは到達性です
メールサーバーの構築自体は、週末の作業で完了します。最新の構成では、1 つの compose ファイルから、メール転送用の SMTP（simple mail transfer protocol）、メール閲覧用の IMAP（internet message access protocol）、スパムフィルタリング、Webmail インターフェースを導入できます。VPS への Mailcow メールサーバーのインストールでも、その手順を説明しています。インストール作業そのものは難しくありません。
難しくなるのは、あなたのサーバーが、あなたのことを一度も聞いたことがない企業の運用するサーバーへ接続し、誰かの受信トレイにメッセージを配信するよう要求するときです。受信側には、受け入れる理由がありません。受信側は、接続元 IP アドレスの評価、ドメインの評価、メッセージが認証済みかどうか、過去にそのサービスのユーザーがあなたのメールへどう反応したか、といったシグナルから判断します。新しい送信者には履歴がありません。履歴がないことは、中立とは評価されません。リスクとして評価されます。そのため、最初のメッセージは迷惑メールフォルダーに入るか、送信実績が蓄積されるまで保留されます。
拒否メッセージが表示されます。Gmail は次の形式の恒久的な拒否を返します。
550-5.7.1 [203.0.113.5 19] Our system has detected that this message is
550-5.7.1 likely unsolicited mail. To reduce the amount of spam sent to Gmail,
550-5.7.1 this message has been blocked.Microsoft は異なる形式の拒否を返します。末尾の block-list code は変わります。
550 5.7.1 Unfortunately, messages from [203.0.113.5] weren't sent. Please
contact your Internet service provider since part of their network is on
our block list (S3150).まず、他の部分より先に最初の数字を確認します。4 で始まるコードは一時的なエラーです。そのため、サーバーはメッセージを保持して再試行します。5 で始まるコードは恒久的なエラーです。そのため、メッセージは直ちに送信者へ返送されます。解消しない 4xx の遅延は、レート制限または評価に基づく制限です。これは自動的に解消する場合があります。5xx は受信側の決定であり、自動的には解消しません。
新しいサーバーからのメールが迷惑メールに分類されるのはなぜですか？
IP アドレスは新しいものではないためです。新しいアドレスが割り当てられるわけではありません。プロバイダーのアドレスプールから再利用されたアドレスが割り当てられ、その履歴も引き継がれます。以前の利用者がスパムを送信していた場合、2通目を送る前に、最初のメールが拒否されることさえあります。
そのアドレス上に何かを構築する前に、アドレスを確認してください。公開ブロックリストは DNS 経由で応答します。アドレスの4つのオクテットを逆順にします。
sudo apt update && sudo apt install -y bind9-dnsutils netcat-openbsd swaks
dig +short 10.0.0.10.zen.spamhaus.org空の応答なら、そのアドレスは登録されていません。127.0.0.0/8 内の応答なら登録されており、最後のオクテットで一致したリストを確認できます。このテストには注意点があります。Spamhaus は、大規模な公開リゾルバー経由で到着したクエリを拒否します。そのため、8.8.8.8 経由で同じ検索を実行すると、実際の状態にかかわらず 127.255.255.254 が返されます。このコードはクエリが拒否されたことを示すものであり、アドレスが登録されていることを示すものではありません。自分のサーバーのリゾルバー経由で実行するか、Web の検索機能を使用してください。
クリーンな結果は必要ですが、それだけでは十分ではありません。登録されていないということは、そのアドレスについて最近苦情が寄せられていないことを示すだけです。良好な評価は付いておらず、メールを受信トレイに届けるには良好な評価が実際に必要です。良好な評価は、数週間にわたって受信を望まれているメールを少量ずつ送信することで得られます。
同じネットワーク上の他の利用者も影響します。受信側の一部は、単一のアドレスではなく、ネットワークブロック全体で評価するためです。同じ /24 範囲内の別の顧客がスパムの送信を始めると、その影響であなたのメールの配信が遅くなることがあります。このブロック単位の評価があるため、アカウント所有者が送信していないトラフィックについても、VPS の受信トレイに不正利用の苦情が届くことがあります。苦情はアドレス範囲に紐づいて届くためです。
開始前に確認すること: port 25 と PTR レコード
Outbound TCP port 25 はインターネット上で最も悪用されている port です。そのため、多くのホスティングプロバイダーは新規アカウントでデフォルトで閉じています。依頼すれば開放するプロバイダーもあります。アカウントの利用期間や支払い実績が積み上がると開放するプロバイダーもあります。決して開放しないプロバイダーもあります。プロバイダーごとにポリシーは異なり、時間とともに変更されるため、この記事、古いフォーラムのスレッド、プロバイダーのマーケティングページを最新情報として扱わないでください。料金を支払う前に問い合わせ、回答を文書で受け取ってください。
サーバー自体から経路をテストします。
nc -vz gmail-smtp-in.l.google.com 25経路が開いていれば、1 秒以内に succeeded! が出力されます。ブロックされている場合はハングした後、タイムアウトします。パケットが暗黙に破棄されると通常のネットワーク障害とまったく同じに見えるため、ブロックを示すメッセージは表示されません。
2 つ目の要件は PTR レコードです。これは reverse DNS とも呼ばれます。受信側は接続元の IP アドレスを取得し、その PTR レコードを検索して名前を得ます。次に、その名前を検索してアドレスを取得し直します。2 つが一致する状態を forward-confirmed reverse DNS と呼びます。これは、接続元ホストが名乗っている所有者に属することを確認する、安価なチェックです。
dig -x 203.0.113.5 +short
dig +short mail.example.com1 つ目はメールホスト名を返す必要があります。2 つ目は、最初に使用したものと同じアドレスを返す必要があります。IP アドレスの所有者だけが PTR レコードを公開できるため、これはホスト側で設定してもらうか、コントロールパネルで設定します。PTR レコードがない場合や、203-0-113-5.static.example-isp.net のような汎用的な値になっている場合は、強いマイナス要因です。実際のメールサーバーにはほぼ必ず対応する名前があり、大量スパムの送信元には対応する名前がないことが多いためです。
ホストが IPv6 も割り当て、サーバーが IPv6 を優先する場合は、上記の内容が IPv6 アドレスにも適用されます。Gmail は IPv6 についてより厳格です。PTR レコードのないアドレスから IPv6 で送信すると、PTR レコードと認証に関する IPv6 の送信ガイドラインを満たしていないという拒否を受けます。IPv6 の PTR レコードを設定できない場合は、IPv4 のみで送信してください。Postfix では smtp_address_preference = ipv4 で IPv4 を優先できます。inet_protocols = ipv4 で IPv6 を完全に無効化することもできます。
ホストに確認する 3 つの質問
- 新規アカウントで outbound TCP port 25 は開いていますか。開いていない場合、開放するための正確な手順と所要期間はどのくらいですか。
- IPv4 アドレスと IPv6 アドレスの PTR レコードを設定できますか。設定場所はどこですか。
- 以前の顧客が原因でアドレスが blocklist に登録されていた場合、別のアドレスに変更してもらえますか。
購入前に、3 つすべてを確認してください。購入後ではいけません。最初の 2 つに明確に回答し、3 つ目には「いいえ」と答えるホストでも、利用できます。初日にアドレスを確認して、必要なら解約できるためです。3 つのいずれにも文書で回答しないホストは、そこでメールを運用するとどうなるかをすでに示しています。
SPF、DKIM、DMARCが実際に証明すること
DNSレコード3つにより、自分のドメインから送信されたと主張するメールが、本当にそのドメインから送信されたことを確認できます。それぞれ異なる問いに答えます。3つ目を理解するには、最初の2つを理解する必要があります。
SPF (sender policy framework) は、自分のドメイン宛てのメールを送信してよいサーバーを列挙する TXT レコードです。受信側はこれをエンベロープ送信者と照合します。これは SMTP MAIL FROM コマンドで指定されるアドレスであり、受信者に表示される From: ヘッダーではありません。
DKIM (domainkeys identified mail) は、メッセージヘッダーに暗号学的署名を追加します。署名は本文と、選択したヘッダー一覧を対象にします。対応する公開鍵は、指定したセレクターの下で DNS に登録します。これにより、誰でも、そのメッセージが秘密鍵の保持者によって署名され、途中で改変されていないことを検証できます。
DMARC (domain-based message authentication, reporting and conformance) は、他の2つの認証結果を表示される From: ヘッダーのドメインに関連付けます。その関連付けに失敗した場合の処理を受信側に指示します。
example.com. TXT "v=spf1 mx -all"
mail._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"重要なのはアライメントです。SPF に合格しただけでは DMARC に合格しません。SPF または DKIM に合格し、合格した認証のドメインが From: ヘッダー内のドメインと同じ場合に、DMARC に合格します。これが、リレーされたメールが気付かないうちに失敗する理由です。リレーがエンベロープ送信者を自分のドメインに書き換えると、SPF には合格します。しかし、合格したドメインはリレーのドメインなので、アライメントしていません。自分の DKIM 署名が存在し、有効でない限り、DMARC は失敗します。自分のドメインで公開した鍵を使って署名すれば、この問題は解消します。
アライメントにより、転送の仕組みも説明できます。メーリングリストや、以前使っていた大学のアドレスがメールを転送すると、転送サーバーが接続元 IP アドレスになります。その IP アドレスは自分の SPF レコードに含まれないため、最終的な宛先で SPF は失敗します。署名対象のヘッダーが変更されない限り、DKIM は転送後も有効です。機能しなければならないのは DKIM です。
まず rua= のレポートアドレスを指定して p=none を公開し、設定を厳格化する前に2週間、集計レポートを確認します。これらのレポートだけで、自分が送信していないのに自分の名前で送信されたメールを確認できます。また、把握していなかった転送サーバーを見つける唯一の方法でもあります。いきなり p=reject にすると、この手順を省略することになり、何が壊れたのかを記録できないまま正当なメールまで失敗します。
次に、チェーン全体をエンドツーエンドでテストします。大手プロバイダーで自分が管理しているアカウントにメールを1通送信し、その raw source を開きます。
swaks --to you@gmail.com --from postmaster@example.com --server 127.0.0.1
sudo journalctl -t postfix/smtp -fswaks は、SMTP のやり取りを進行中に表示します。Postfix が配信時に出力するログ行は、受信サーバーがメッセージを受け入れた場合、status=sent (250 2.0.0 OK ...) で終わります。それ以外の場合は拒否理由をそのまま記録します。その文字列を検索します。配信されたメッセージの raw source には Authentication-Results: ヘッダーがあり、各認証について pass または fail と、認証されたドメインが記載されています。3つすべてが pass で、ドメインが自分のものでなければなりません。
評判の問題を調べるにはどうすればよいですか？
フィードバックループとは、メールボックスプロバイダーの利用者が「迷惑メールを報告」ボタンをクリックするたびに、そのプロバイダーからメッセージのコピーが送られてくる仕組みです。フィードバックループがない場合、最初に問題に気付くのは、すでに配信に失敗した後です。しかも、その通知が届くまで数週間かかることもあります。
各プログラムの仕組みは異なり、1つのアドレスを使う単一の VPS には適さないものもあります。2026年8月時点では、Microsoft はアドレス所有者が登録できる、アドレス単位のデータおよび苦情サービスを運用しています。Yahoo は DKIM 署名ドメインをキーとする苦情フィードバックループを提供しています。Google は個別の苦情ではなく集計された評判データを公開しており、そのダッシュボードは、利用者に対して十分な量のメールを毎日送信するまで空のままです。これらのプログラムは変更されるため、いずれかに依存する前に各サービスの最新の規約を確認してください。どのプログラムも、利用権を保証しているわけではありません。
2024年2月から適用されている Google の公開バルク送信者要件は、大規模な受信側が現在送信者に何を求めているかを示す、最も明確な公開情報です。個人用 Gmail アカウントへ1日5,000通を超えるメッセージを送信する場合、送信者は SPF と DKIM で認証し、DMARC ポリシーを公開し、バルクメールにワンクリック登録解除を提供し、迷惑メールの苦情率を0.3パーセント未満に維持する必要があります。小規模サーバーから個人宛てに送信するメールはこのしきい値を大きく下回りますが、同じシグナルは送信量にかかわらず確認されます。また、フィードバックループがなければ確認できないのが苦情率です。
機能する分離構成: 受信は self-host、送信は relay
受信は、ほとんどデメリットのない部分です。自分宛てに送られたメールを受け取るために、誰かの信頼を得る必要はありません。ドメインのメール交換サーバーを指定する DNS レコードである MX レコードを自分のサーバーに向け、送信者は自分のサーバーへ接続します。その後の判断はすべて自分で行えます。何を保存するか、どの期間保存するか、どうインデックスを作成するか、誰に検索を許可するかを決められます。ストレージは安価です。自分で管理するアーカイブが、どこか別の場所で実行された自動ポリシー判定によって閉鎖されることもありません。必要な作業はありますが、範囲は明確です。スパムフィルターを更新し、TLS (transport layer security) 証明書を更新し、バックアップを維持し、ディスク容量を使い切らないようにします。
送信では、難しい問題を解決するために外部サービスを利用します。すべての送信メッセージを、port 25 でインターネット全体と直接通信させる代わりに、port 587 の認証済み relay へ渡すようにサーバーを設定します。Postfix の main.cf では次のように設定します。
relayhost = [smtp.relay.example]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = encrypteditor で /etc/postfix/sasl_passwd に認証情報を書き込みます。これにより、パスワードが shell history に残りません。1 行で記述し、左側の host は relayhost に表示されるものと完全に同じにする必要があります。
[smtp.relay.example]:587 username:passwordsudo chmod 600 /etc/postfix/sasl_passwd
sudo postmap /etc/postfix/sasl_passwd
sudo chmod 600 /etc/postfix/sasl_passwd.db
sudo systemctl reload postfixその後に送信したメッセージでは、relay=smtp.relay.example[...]:587 と status=sent がログに記録されます。SASL authentication failed と表示されるログ行は、認証情報が受け付けられなかったことを示します。通常の原因は、sasl_passwd に記述した hostname が relayhost のものと異なることです。照合は完全一致で行われるためです。
この分離構成が機能するのは、relay が、長年受け入れてきたメールによって実績を積んだアドレスを保有しており、その評価を維持すること自体が事業だからです。自分ではドメイン、メールボックス、アーカイブ、そして移行できる自由を保持できます。relay の変更は、設定 1 行と DNS レコード 1 件の変更で済むためです。失うのは、relay 運営者に対する送信メールの機密性です。これが、この構成の正直な代償です。後から気付くのではなく、事前に判断しておくべき点です。
初日に、もう 1 つ分離しておく価値があります。大量送信を行うものは、専用の DKIM key を設定した専用の subdomain から送信します。たとえば、newsletter には news.example.com、個人メールには mail.example.com を使用します。評価は送信 domain に紐付くため、self-hosted Listmonk の newsletter に対する苦情率が、個人メールの評価まで引き下げることを防げます。
フルセルフホストを選ぶべきなのはどのような場合か
送信量。1 か月あたり数百通であれば、メッセージ単位のリレー料金は負担になりません。しかし、数百万通になると負担が大きくなります。その規模であれば、専用アドレスと、それを機能させるためのウォームアップスケジュールを用意できます。
管轄。規制や契約によって、メールを第三者のディスクに保存してはならないと定められている場合、配信品質は判断基準になりません。リレーを利用できないためです。
購入できない制御。プランの階層ではなく、自社のポリシーに合わせた保存ルールを適用できます。サービスごとにアドレスを用意すれば、どのサービスから漏えいしたかを確認できます。自分のコードでフィルタリングを実行でき、異議申し立ての手段がないシステムによってアカウント停止を決められることもありません。
ネットワークの外へ出ないメール。アラートなどのマシン間メールでは、両端を自分で管理しているため、配信到達性の問題はありません。ローカル SMTP サーバーから自分のメールボックスへ配信すれば十分です。これは、MCP (model context protocol) 経由でアシスタント専用のセルフホストメールボックスを用意する場合にも使われるパターンです。
外部へ直接送信する場合は、アドレスをウォームアップしてください。最初はメールを待っている受信者に少ない日次量で送信し、数週間かけて段階的に増やします。ウォームアップしていないアドレスから、突然大量送信してはいけません。レピュテーションは、苦情の少ない受信済みメールの実績によって時間をかけて構築されます。そのため、履歴のないアドレスから突然送信量が増えると、侵害されたサーバーとまったく同じように見なされ、同様に扱われます。
メールサーバーの運用開始から最初の1年間にかかる費用は？
1週目は構築作業です。パッケージ、DNS レコード、TLS 証明書、最初のテストメール、p=none の DMARC 設定を行います。
2週目から6週目は、誰も予定に入れない作業の期間です。DMARC 集計レポートを確認し、存在に気付いていなかったアライメントの問題を見つけ、SPF を壊すフォワーダーを発見します。その後、ポリシーを p=quarantine へ移行し、さらに p=reject へ移行します。この期間の対応によって、セルフホスティングが日常の運用になるか、負担に感じるものになるかが決まります。
その後は、月におよそ1時間で落ち着きます。パッケージの更新、更新を想定で済ませず実際に確認する証明書の更新、バックアップからのリストアテスト、ディスク使用量の増加状況の確認、ブロックリストの検索を行います。
ただし、予定に入れられない週もあります。自分が行っていないことを理由に、アドレスがリストに登録されることがあります。大手の受信側がルールを変更し、メールが再び迷惑メールに振り分けられることもあります。キューに入ったメールは、失われたメールではありません。Postfix はデフォルトで遅延したメッセージを5日間再試行します。この期間は maximal_queue_lifetime = 5d で設定されるため、停止が数時間なら遅延が発生するだけです。停止が1週間に及ぶと、メールを失います。
バックアップ MX レコードは、見た目ほど有効な対策ではありません。送信側のサーバーはもともと数日間自動的に再試行するため、キューに入れるだけのセカンダリサーバーを追加しても効果は限定的です。さらに、どのアドレスが存在するかを把握していないセカンダリサーバーがドメイン宛てのメールを受け入れると、存在しないアドレス宛てのメールまで受け取ります。その後、偽装された送信者へバウンスを返すため、バックアップサーバーがバック散乱の発信元になります。監視と、実際にテストしたリストアに労力をかけてください。
全体を評価するときは、サーバー上の他のものにも適用する次の質問を使ってください。このサービスを自分で所有することで、購入できない何かが得られるでしょうか。メールボックスとアーカイブについては、通常は得られます。見知らぬ相手への送信メール配送については、通常は得られません。これは、2026 年にセルフホスティングする価値があるものの一覧 の他の項目を選別する基準と同じです。
FAQ
VPS プロバイダーが外向きの port 25 をブロックしている場合でも、メールを self-hosting できますか？
はい。メールの受信と、relay 経由の送信は可能です。受信メールはサーバーの port 25 に到着するため、外向き通信のブロックは影響しません。送信メールは port 587 の認証済み relay 経由で送信します。プロバイダーは通常、この port をブロックしません。port 25 を閉じた状態でできないのは、他のメールサーバーへ直接配送することです。サーバー間の配送は定義上 port 25 で行われるためです。nc -vz gmail-smtp-in.l.google.com 25 でテストできます。接続が停止した後に timeout になる場合は、port がブロックされています。
SPF、DKIM、DMARC がすべて pass しているのに、メールが spam に振り分けられるのはなぜですか？
認証によって、メッセージの送信者は証明されます。ただし、そのメッセージが望まれていることまでは証明されません。3 つすべてに pass すると、未識別の状態から識別済みの状態になります。その後、受信側は IP アドレスとドメインの reputation を評価します。新しい送信者には、まだ十分な reputation がありません。受信者が予期しているメールを少量ずつ、数週間にわたって送信し、reputation を築きます。次に、PTR record が mail hostname と正引き・逆引きの両方向で一致することを確認します。link shortener や見慣れない tracking domain など、コンテンツ自体が評価を下げる要因になっていないことも確認します。
self-hosted mail server に専用の IP アドレスは必要ですか？
直接送信する場合は必要です。メールサーバーには、PTR record を自分で管理でき、reputation を自分だけで共有できるアドレスが必要です。この意味では、VPS のアドレスはすでに専用です。ただし、そのアドレスの過去の利用状況や、同じ network block 内の近隣アドレスまでは管理できません。送信メールを relay 経由にする場合は、relay のアドレスが reputation を担います。自分のアドレスに必要なのは、受信接続を受け付けることだけです。
メインのアドレスを self-hosted server に移しても安全ですか？
一度に切り替えず、段階的に移行してください。既存の mailbox を稼働させたまま、自分の server を 2 つ目の配送先として追加します。数週間はコピーを自分の server に forward し、DMARC report を確認しながら、メールが双方向に正しく流れることを確認します。テストメールが 1 週間正しく到着してから、MX record を変更します。避けるべきなのは、受信メールを失う cut-over です。受信メールは後から再構築できないためです。
メールの管理権限を維持する最小構成は何ですか？
mailbox と archive は自分の server で管理し、送信は port 587 の認証済み relay に任せます。データとドメインを自分で管理でき、reputation の問題も完全に回避できます。方針を変更する場合の負担も小さくなります。relay の設定変更は 1 行と SPF entry 1 つで済むため、後から置き換えても半日程度の作業です。