📝 はじめに
こんにちはpiyovateです。
今回、検証環境でメール送信機能の確認を行う機会があり、
その際に MailHog を利用しました。
「MailHogって何？」「送信元なの？送信先なの？」と少し混乱した部分もあったため、
実際に使ってみて理解した内容を整理してみます。
🎯 今回の概要
今回の記事では、以下についてまとめます。
- MailHogとは何か
- どういう場面で使うのか
- 実際に検証でどのように使ったか
- Inboxの意味（送信元？送信先？問題）
📌 MailHogとは？
MailHogは、開発・検証環境向けのSMTPテストサーバーです。
通常、アプリケーションがメールを送信すると：
アプリ → SMTPサーバ → ユーザーのメールアドレス
という流れになります。
しかし検証環境で本物のメールを送ってしまうと、
- 誤送信のリスク
- テストアドレスへの実配送
- 外部依存の増加
といった問題が発生します。
MailHogを使うと：
アプリ → MailHog → （ここで止まる）
となり、実際のユーザーには送信されません。
🛠️ 今回の検証での使い方
① MailHogを起動
Dockerで起動しました。
docker run -p 1025:1025 -p 8025:8025 mailhog/mailhog
- 1025 → SMTPポート
- 8025 → Web UI
② アプリのSMTP設定を変更
検証環境のSMTP設定をMailHogに向けます。
例：
MAIL_HOST=localhost
MAIL_PORT=1025
MAIL_ENCRYPTION=null
これにより、本番SMTPではなくMailHogへ送信されます。
③ メール送信機能を実行
- 会員登録
- パスワードリセット
- 通知メール
などを実行。
④ Inboxで確認
ブラウザで
http://localhost:8025
にアクセスすると、送信されたメールが一覧表示されます。
📥 Inboxって何？
最初に少し混乱したのがここです。
Inboxに表示されるのは：
❌ 送信元一覧
⭕ MailHogが受け取ったメール一覧
つまり、
アプリ（送信元）
↓
MailHog（SMTPとして受信）
↓
Inboxに表示
という流れです。
本来ユーザーに届くはずだったメールを、
MailHogが代わりに受け取って保持している、という理解が正しいです。
🧠 使ってみて分かったこと
- MailHogは「送信先」ではなく「SMTP受信サーバ」
- 本番配送はしない（外部には送られない）
- HTMLメールの確認が非常に楽
- 認証URLやトークン確認に便利
検証環境ではかなり安心して使えるツールだと感じました。
🔜 今後やりたいこと
- API経由でメール検証を自動化する
- CI環境に組み込む
- 本番との差分を整理する
検証環境でメール機能を扱う際には、
MailHogは非常に便利な選択肢でした。
同じように「Inboxって何？」と混乱した方の参考になれば幸いです。
それでは、また次回の記事でお会いしましょう ✨