Mailpitの代替：GrabMailとMailHogの比較

ひと目でわかる比較

14行の表で、自分のホスト上で動くツールであるため、いくつかの行には「該当なし」と書かれています。Mailpitの各セルは、2026年9月2日時点のドキュメント、README、実行時オプションのページの記載内容そのものです。GrabMailの各セルは、このサービスが実際に適用している定数から読み取ったものです。

2026年9月2日時点で確認。Mailpitのデフォルト値は、実行時オプションからの引用です。最新500件のメッセージを保持、終了時に削除される一時データベース、50 MBのメッセージ上限です。MailHogの状況は、引用したリポジトリの日付から推測したものです。プロジェクトには非推奨の通知は一切ありません。

Mailpitが優れている点

Mailpitは、アプリケーションを構築している間、その隣で動かすツールです。GrabMailにはできない、Mailpitができる4つのことを挙げます。

• 送信するものすべてを、ローカルで捕捉する。アプリをポート1025に向ければ、パスワードリセットも請求書もすべて、8025番のWeb受信箱に届きます — 一通たりとも実際のアドレスに届くことはありません。GrabMailは、あなたの送信メールを一度も目にすることがありません。
• 配信だけでなく、メッセージそのものをテストする。HTML互換性チェック、リンクチェッカー、SpamAssassinによるスコアリング、スクリーンショット、タグ付け。GrabMailはメッセージを渡すだけで、そこで終わりです。
• カオス。バージョン1.20以降、選んだ段階に選んだ確率でSMTP障害を注入し、メールサーバーが機能しないときでもアプリケーションが対処できることを証明できます。ホスト型のサービスでこれを提供しているものはありません。
• それはあなたのものである。MITライセンス、単一のバイナリ、1秒あたり200〜300件のメッセージ、ベンダーなし、アカウントなし、インターネット不要。一方GrabMailは他人のサーバーであり、そこにあるものはすべて公開されています。

GrabMailが違う点

GrabMailは、ローカルのSMTPキャッチャーにはできない、ただひとつのことをします。インターネット上に存在し、他人のサーバーが配信できるアドレスを持つことです。

• 本物の受信メール。テストがサードパーティのサービスにサインアップし、そのサービスがコードを送ってきます — GitHubであれ、Stripeであれ、統合先が何であれ、アドレスは本物でなければなりません。run-42@grabmail.ioは本物で、MXレコードを持ち、そのメールはキー不要のGETで読み取れます。
• 動かすものも、公開するものもない。Mailpitをインターネットから受信できるようにするには、公開ホスト、MXレコード、ファイアウォールルールが必要であり、そのドキュメントもそのような用途を想定していません。GrabMailはすでにそこにあります。CIランナーに必要なのは、送信方向のHTTPSだけです。
• 独自ドメインがそのままキャッチオールになり、ホストされる。smtp.grabmail.ioへのMXレコード1件だけで、そのドメイン上のすべてのアドレスがどこからでも受信でき、5日間保持され、あなた自身のデーモンは一切関与しません。
• エージェント向けのMCPサーバー。どこかにサインアップしなければならないエージェントは、ローカルのSMTPキャッチャーをそもそも使うことができません。https://grabmail.io/mcpにあるGrabMailのサーバーは、キーなしで、受信箱と、最大25秒ブロックするwait_for_messageを与えてくれます。

価格を並べて比較

Mailpitには価格をつけるものが何もありません。無料のソフトウェアであり、コストはそれを動かすホストです。GrabMailの唯一の有料プランは、使い捨てメールのブロックリストに載らないよう保たれたドメイン群へのアクセスを購入するものです。上の表にあるものはすべて無料のままです。

2026年9月2日時点で公開されている内容です。完全な料金表はGrabMailの料金ページにあります。

開発者向け: メールボックスを読む

この2つのAPIは異なるメールを読み取るので、ここでは外部世界からの受信メールを読み取る方を紹介します。これは、ヘッダーもキーもアカウントも使わずにGrabMailのメールボックスを読み取ります。

$ curl -sG https://grabmail.io/api/v1/mailbox --data-urlencode "address=anything@grabmail.io" | jq '{count, alias}'

Mailpitでの相当する処理は、自分のインスタンス上でのGET http://localhost:8025/api/v1/messagesで、アプリケーションがそこに送信したものの一覧を返します — これは、アプリが正しいメッセージを生成したことを確認するための正しい呼び出しです。サードパーティがテストユーザーに送ったものを読み取るのはGrabMailの仕事です。リファレンスは3つのエンドポイントであり、GitHub Actionsガイドでは、両方の種類のテストを1つのワークフローで示しています。

CIでは、この2つが並んで使われます。アプリケーション自身のメール用に1025番でサービスコンテナとして動くMailpit、そしてテストスイートが実際のサービスに対して行うサインアップ用のGrabMailアドレスです。どちらもシークレットを必要としません。

AIエージェント向け

MailpitはMCPサーバーもllms.txtも公開しておらず、ウェブサイトにサインアップしようとするエージェントがローカルのSMTPキャッチャーを使うことはできません。https://grabmail.io/mcpにあるGrabMailのサーバーは、エージェントにキー不要の受信箱を与えます: create_inbox、最大25秒ブロックするwait_for_message、read_messageです。

AIエージェント向けのメールでは、この4回の呼び出しからなるループとガードレールについて解説しています。クライアントガイドには、Claude、Cursor、その他5つのクライアントの設定が載っています。

MailpitまたはMailHogからの乗り換え

MailHogからは、Mailpitに乗り換えてください — それが、同じ役割を果たす、現在もメンテナンスされている後継だからです。どちらからGrabMailへ乗り換えるかは、受信を行うテストに限られます。

1. 捕捉についてはMailHogをMailpitに置き換える。考え方は同じ、ポートも同じ、そしてメンテナンスされているプロジェクトです: docker run -p 8025:8025 -p 1025:1025 axllent/mailpit。これにはGrabMailは一切関係しません。
2. 外部とやり取りするテストを見つける。実際のサードパーティサービスに登録し、そのメールを待つテストは、ローカルのキャッチャーでは対応できません。run-{id}@grabmail.io、あるいはsmtp.grabmail.ioに向けたドメイン上のアドレスを与えてください。
3. GETで読み取る。期限付きで毎秒/api/v1/mailbox?address=…を呼び出します。Playwrightガイドにこのループが載っています。トークンも、サービスコンテナも不要です。
4. それ以外のすべてについてはMailpitを使い続ける。テンプレート、リンク、スパムスコア、障害注入 — それがMailpitの仕事であり、GrabMailはそのどれもできません。

どちらを、何のために

正直な分け方は、メールの向きによるものです。

Mailpitにとどまるべきとき

GrabMailが間違ったツールになる3つの状況があります。

• テストが、自分の送信内容を確認している。GrabMailは、あなたのアプリケーションの送信メールをまったく見ることができません。それこそがMailpitの存在意義そのものです。
• メールが建物の外に出てはならない。ローカルのキャッチャーは、すべてのメッセージを自分のホスト上に保持します。一方、すべてのGrabMailのメールボックスはインターネット上で公開されています。
• 障害をテストしている。カオスモード、実際のサーバーへのリレー、転送ルール — これらは自分で動かすツールの機能であり、ここにホスト型の同等品はありません。

質問