Docker開発環境でメール送信を安全に確認する

メール機能を本番SMTPで開発確認すると、テストデータが実在の宛先へ送られる危険があります。逆にメール確認を後回しにすると、本番でテンプレート崩れやリンク誤りが見つかります。

メールは非同期送信されることが多く、画面操作と送信結果が分かれます。テンプレートには環境ごとのURLや差し込みデータが入り、添付ファイルを扱う場合もあります。

メール機能は、画面上の成功表示だけでは品質を確認できません。宛先、件名、本文、リンク、添付、文字化け、テンプレート変数の欠落を見なければ、利用者に届く時点で問題が表面化します。

Docker Composeにメールプレビュー用サービスを入れ、開発環境のSMTPはそこへ向けます。ステージングでは、許可ドメイン以外へ送らないガードや宛先置換を入れます。

設計では、開発、テスト、本番のメール送信経路を分けます。Docker Composeにメールプレビュー用サービスを置き、LaravelやNode.jsのSMTP設定を開発時だけそこへ向けます。本番のSMTP認証情報はローカルに持ち込みません。

アプリ設定では、SMTPホスト、ポート、送信元、ベースURLを環境変数で管理します。メール送信処理はテンプレート生成と送信を分け、テストでは本文に必要な情報が入るかを確認します。

アプリ側では、メール送信を直接SMTPに書かず、通知サービスやmailer interfaceを通します。テストではfake mailerで送信要求を検証し、ローカル確認ではプレビュー画面で実際のHTMLとテキストを確認します。

検証では、登録、通知、リセット、承認など主要メールをローカルで発火し、件名、宛先、本文、リンク、添付を確認します。ステージングで外部宛先に送れないこともテストします。

検証では、登録、招待、パスワード再設定、通知、添付ありメールなど代表ケースをプレビューします。CIではメール送信要求が発生したことと、宛先やテンプレート変数が正しいことをテストします。

完全に実メールを送らない環境では、迷惑メール判定やDNS設定は確認できません。配信到達性は本番相当の別テストで確認し、日常開発では誤送信防止を優先するのが安全です。

プレビュー環境だけでは、本番SMTPの到達性や迷惑メール判定までは分かりません。開発では誤送信防止を優先し、ステージングで実送信に近い確認を限定的に行うなど、環境ごとに役割を分ける必要があります。

メール機能は、送れることより誤って送らないことが重要です。Docker開発環境にプレビューSMTPを入れるだけで、本文確認と安全性を両立できます。

メール機能は、送信成功だけでは完成しません。Docker上で安全にプレビューできる環境を作ると、誤送信を防ぎながら利用者に届く内容を確認できます。