判断：Mailpitを使った自社アプリのメール試験には適しています。 ただし、送信処理の呼び出し成功だけではMailpitへの保存を確認できません。まずアプリが実際に使ったSMTPまたはAPIの接続先と送信結果を調べ、その後に受信の有無、解析結果、テストコードの検索条件を確認してください。
自社サービスの登録・認証メールを試験する開発者は、送信処理と受信の証拠を分けて確認できます。
QAエンジニアは「試験は成功したのにメールがない」という失敗を切り分けられます。
メール連携を保守する個人開発者は、Mailpit 1.33.1の解析変更が影響するかを確かめられます。
最終更新：2026年11月10日。Mailpitの公式リリース記録とSMTP設定、HTTP設定、API資料を確認しています。
Mailpit 1.33.1でテストメールが表示されないときは、送信と検索を分ける
「テスト成功」は何を確かめた結果でしょうか。テストが送信メソッドを呼び出したこと、アプリ側のアサーションが通ったこと、Mailpitがメールを受信・保存したことは、それぞれ別の事実です。最初の2つだけでは、受信箱にメールが存在するとは判断できません。
たとえば、コンテナ内で動くアプリがSMTPの接続先にlocalhostを指定していると、アプリ自身のコンテナを参照してMailpitに到達しない場合があります。また、開発環境と試験環境で別のSMTPホストを使っていれば、メールが届いていても確認中のMailpitには現れません。
ログで送信処理が実行されたことだけを見るのではなく、実行環境が実際に参照した接続先と送信時の応答を確認します。SMTPを使ったのかHTTP APIを使ったのかも区別してください。Mailpitのメール送信に関する公式ガイドとアプリの設定を照らし合わせると、送信経路の取り違えを見つけやすくなります。
接続先が現在のMailpitインスタンスを向いているか確認する
まずアプリの実行環境から設定値を確認します。開発者の端末で使うホスト名と、コンテナや別の実行環境から使うホスト名は同じとは限りません。SMTPのホスト・ポートと、Web画面やAPIのベースURLを、それぞれMailpit側の設定と照合します。
次に、今回のテストがどの環境変数や設定ファイルを読み込んだかを確認してください。起動時のログに接続先を出す場合は、認証情報などを含めず、ホストと環境名だけを記録します。MailpitのSMTP設定資料とWeb・APIの設定資料は、SMTPとHTTPの役割を分けて確認するのに使えます。
- [ ] テスト実行時のSMTPホストとポートが、確認中のMailpitインスタンスを指している
- [ ] アプリの環境変数・設定ファイルが、想定した環境のものになっている
- [ ] SMTP送信とHTTP API送信のどちらを使ったか、ログや設定で確認できる
- [ ] 送信先のメールアドレスと実行環境を照合し、別環境への送信を除外した
- [ ] テストコードが今回の実行を識別する値でメールを検索している
チェックが残る場合は、Mailpit内の検索より先に接続設定を修正してください。検索条件を何度変えても、別のインスタンスへ送られたメールは見つかりません。
Mailpit 1.33.1の解析変更を、メールの見え方と分けて調べる
Mailpit 1.33.1の公式リリース記録には、非UTF-8の表示名を含むメールヘッダーの解析に関する修正、Bcc受信者の処理に関する修正、解析できないメールを拒否する変更が記載されています。これらはこの版で確認すべき変更点ですが、あらゆるメール欠落の原因を説明するものではありません。
| 確認する点 | 起きていることの見分け方 | 次に行うこと |
|---|---|---|
| 表示名の文字コード | メールは見えるが、差出人などの表示が想定と異なる | 該当するヘッダーを含む再現用メールを保存し、表示と解析結果を比べる |
| Bccの扱い | メール自体は見えるが、受信者の表示や検査結果が想定と異なる | 自社アプリから送ったBcc付きメールで、実際の表示・応答を確認する |
| メールの解析 | Mailpitで受信を確認できず、解析できないメールの可能性がある | 送信側の応答と再現用メールを保存し、実際のバージョンと公式記録を照合する |
解析できないメールは、公式リリース記録上、黙って破棄されるのではなく拒否される扱いです。したがって、受信箱に見当たらない場合は、アプリ側の送信応答やログも確認してください。公式に記載されていないエラーコードや拒否条件を推測して、原因を決めつけるのは避けます。
Mailpitの統合テスト資料も参照し、問題を再現できる小さなテストを用意します。送信したメールのサンプルとサーバー応答を残しておけば、設定の問題と解析の問題を後から区別できます。
メールが保存済みなら、画面とAPIの検索条件を照合する
Mailpitの画面でメールが見えるか確認します。画面に存在するのに自動テストが見つけられない場合は、送信ではなく検索条件やテストコードを調べる段階です。差出人・宛先フィルター、検索語、テストが保持しているメール識別子が今回の送信内容と一致しているか確認してください。
画面にないときは、Mailpit APIの公式資料を参照して、APIのメッセージ一覧や検索結果を確認します。テストコードが使うエンドポイント、応答に含まれる識別子、ページングやフィルターの指定を、実際の応答と照合してください。別の環境のAPIを見ていないかも確認します。
Mailpit APIで直近のメールを検索できない場合の切り分け
「最新のメール」を読む実装は、検索対象が広すぎると別の試験のメールを拾い、条件が狭すぎると新着を除外します。試験ごとに差出人や宛先、件名などを区別できる値を使い、APIの返却内容から対象メールを特定してください。最新という前提だけに依存せず、取得した識別子を後続の本文検査に渡すと、検索失敗と内容検査失敗を分けられます。
画面でもAPIでも見つからない場合は、送信ログへ戻ります。APIだけで見つからない場合は、APIの接続先と検索条件、画面だけで見つからない場合は、画面のフィルターや対象インスタンスを見直します。
修正後は失敗経路ごとに再試験し、合格範囲を明記する
修正後は、通常のメールに加えて、非UTF-8の表示名を含むメールとBcc付きメールを自社製品から再送します。Mailpitへの到達、画面またはAPIでの検索、解析後の宛先・本文の確認を別々に記録してください。これにより、どの段階が直ったのかを試験結果から判断できます。
Mailpitで捕捉できたことが証明するのは、アプリからローカルの試験用受信先までの経路です。外部のメールサービスに届いたことや、受信トレイに分類されたことの証明にはなりません。外部配送を受け入れ条件にする場合は、管理下にある外部受信先で別途確認します。
この切り分けでは、実在の個人情報を含むメールをむやみに試験環境へ持ち込まないことも重要です。試験データの扱いを決める際は、Tmpkeyのデータ取り扱いに関する案内も確認し、実環境の情報を再利用しない運用にしてください。
Mailpitが受信・検索できるかを確かめる目的なら、まず自社のMailpit環境で送信経路とAPI検索を検証するのが確実です。別の受信経路も試したい場合は、Tmpkeyの案内ページで現在確認できる機能と利用条件を見て、テストの目的に合うか判断してください。Mailpit 1.33.1でテストメールが表示されないときも、外部配送まで確認したいときも、ローカル捕捉と実際の受信を別の合格条件として扱うことが大切です。