どんなプロダクトも、いずれはメールを送る必要が出てきます。そのとき最初に決めるのは、コードとメールシステムのやり取りの方法です。答えは2つあります。SMTPで直接通信するか、HTTPS経由でメールAPIを呼び出すかです。
どちらも機能します。ただし、アプリケーションに求めるものは大きく異なり、どちらを選ぶべきかは、コードがどこで動いているか、メール送信の仕組みをどこまで自分で管理したいかによって決まります。
SMTPが得意なこと
SMTP（Simple Mail Transfer Protocol）は、1980年代初頭からメールサーバー同士がメールをやり取りするために使われてきたプロトコルです。すべてのメールボックスプロバイダーが対応しており、ほぼすべてのフレームワークにSMTPのメーラーが組み込まれています。Nodemailer、Djangoのsend_mail、Laravel Mail、RailsのAction Mailerなどです。
長所：
- 汎用性：あらゆるメールアカウント、あらゆる言語で使えます。
- ベンダーロックインがない：ホスト名とパスワードを変えるだけでプロバイダーを切り替えられます。
- 自社のドメインと評価：メールは自社で管理またはレンタルしているサーバーから、自社ドメインのアドレスで送られます。
アプリの中でSMTPが厄介な点
SMTPは、やり取りの多いステートフルなプロトコルです。メッセージを1通送るために、アプリはTCP接続を開き、サーバーに挨拶し、TLSにアップグレードし、認証を行い、さらに送信者、受信者、データについて一連のコマンドと応答をやり取りします。各ステップがネットワークの往復になります。
実際には、次のような問題が生じます。
- リクエストが遅い：遠くのサーバーとのハンドシェイクだけで、メッセージの送信が始まる前に数百ミリ秒かかることがあります。
- ポートのブロック：多くのクラウドプラットフォームやサーバーレスのランタイムは、スパム対策として送信方向のポート25、465、587を制限しています。ポート443のHTTPSがブロックされることはほとんどありません。
- 認証情報があちこちに：メールを送るサービスはどれも、メールボックスのパスワードを必要とします。パスワードを変更するには、それらすべてを再デプロイしなければなりません。
- 可視性が低い：何かが失敗しても、エラーは1つのサービスのログにしか残らず、そもそもログに記録されていないこともあります。
メールAPIで変わること
メールAPIは、送信処理をJSON本文付きの1回のHTTPSリクエストにまとめます。コードはPOSTを1回送り、ステータスコードを受け取るだけです。SMTP接続と認証情報はAPIサービス側が保持します。
長所：
- 高速なリクエスト1回：ポート443経由で、コンテナ、サーバーレス関数、エッジランタイム、CIジョブなど、どこからでも送信できます。
- パスワードではなくキー：各サービスには権限を限定した専用のAPIキーを割り当てられ、他に影響を与えずに1つだけを失効・ローテーションできます。
- 一元的な可視性：API呼び出しと配信結果を1か所で追跡できます。
- わかりやすいHTTPエラー：
401や429は、スタックトレースに埋もれたSMTPの応答コードよりもはるかに扱いやすいものです。
トレードオフ：多くのメールAPIでは、メールはそのサービスのサーバーから送られます。そのため、送信ドメインの設定やIPの評価はそのサービスに依存することになり、後で乗り換えるときには、別の場所ですべてを検証し直す必要があります。
Inbixio：SMTPサーバーの前に置くAPI
Inbixioはシンプルな考え方に基づいて作られています。SMTPの価値ある部分、つまり自社のメールサーバーと送信者としてのアイデンティティは残し、アプリケーションの中で厄介な部分だけを置き換えるというものです。
- ダッシュボードで、ホスト、ポート、ユーザー名、パスワードを入力してSMTPサーバーを一度だけ接続します。
- 各サービスは、InbixioのAPIキーを使って
POST /api/send-email/を呼び出します。 - InbixioがTLS経由でSMTPサーバーにサインインし、自社のアドレスからメッセージを配信します。
- ダッシュボードには、送信数、配信失敗率、配信レイテンシに加えて、すべてのAPI呼び出しのログが表示されます。
curl -X POST https://backend.inbixio.com/api/send-email/ \
-H "X-API-Key: $INBIXIO_API_KEY" \
-H "Content-Type: application/json" \
-d '{"to_email":"user@example.com","subject":"Welcome!","message":"<h1>Hello</h1>"}'これによって得られるもの：
- SMTPのパスワードは1か所にだけ保管されます。各サービスが扱うのはAPIキーだけです。
- キーを特定の1台のサーバーに固定できるので、請求サービスは
billing@から、認証サービスはsecurity@から送信できます。 - 各キーの権限は明示的で、メールサーバーに手を加えずにキーを更新・削除できます。
- 送信ドメイン、プロバイダー、評価はそのまま維持されます。メールプロバイダーを変更する場合も、サーバーの登録情報を1つ更新するだけで、コードは一切変わりません。
比較表
| SMTPを直接使用 | 一般的なメールAPI | Inbixio | |
|---|---|---|---|
| アプリからの通信方式 | SMTP、ポート25/465/587 | HTTPS、ポート443 | HTTPS、ポート443 |
| メッセージあたりの呼び出し | 多数の往復 | リクエスト1回 | リクエスト1回 |
| サービスが持つ認証情報 | メールボックスのパスワード | APIキー | APIキー |
| 送信元 | 自社のメールサーバー | プロバイダーのサーバー | 自社のメールサーバー |
| プロバイダーの切り替え | すべての設定を変更 | ドメインを再検証し、コードを変更 | サーバーの登録情報を1つ編集 |
| 配信の可視性 | 自分で作った範囲のみ | プロバイダーのダッシュボード | Inbixioダッシュボード：送信数、失敗率、レイテンシ、APIログ |
結局どちらを使うべきか
- SMTPを直接使うのは、送信方向のSMTPが許可されたサーバー上で小規模なアプリを1つだけ運用していて、そこで認証情報を管理することに抵抗がない場合です。
- メールAPIを使うのは、複数のサービスを運用している場合、SMTPポートをブロックするプラットフォームにデプロイしている場合、ログを一元管理したい場合、メールボックスのパスワードを受け渡すのをやめたい場合です。
- Inbixioを使うのは、こうしたAPIのメリットを得ながら、メールは引き続き自社のメールサーバーとドメインから送りたい場合です。
試してみませんか？5分でできるクイックスタートで、登録からメールの配信までを完了できます。
