違いをひとことで言うと？
SMTPは、ソフトウェアがメールをサーバーに渡すためのオープンなプロトコルです。メールAPIは、プロバイダーごとに異なるHTTPSのインターフェースで、構造化されたデータとイベントのフィードバックによって同じ役割を果たします。受信トレイに届くかどうかを決めるのは送信プロトコルではなく、認証とドメインの評価です。SPF、DKIM、DMARCは、どちらの経路にもまったく同じように適用されます。ですから、移行のしやすさ、エラー処理、ツールといった連携面の観点で選んでください。プロバイダーがメッセージを受け付けたあとに起きることについては、スタートアップのためのメール到達率のガイドで解説しています。
SMTPでの送信はどう機能しますか？
アプリケーションがプロバイダーのサーバー（SMTPリレー）に接続し、完成したメッセージを渡します。送信には、RFC 6409の規定どおり、通常は認証付きの587番ポートを使います。転送プロトコルそのものはRFC 5321で、現在の形で標準化されたのは2008年ですが、それよりずっと前から使われています。だからこそ、あらゆるものが対応しています。どんなフレームワーク、CMS、フォーラム、監視ツール、数十年前のスクリプトでも、ホスト、ポート、認証情報さえあればこの方法で送信できます。これがSMTPの目立たない利点です。移行は認証情報の差し替えで済むため、メール配信プラットフォームを乗り換えても、送信のコードを書き直す必要はありません。SMTPへの対応が標準で備わっている、セルフホストのスタックにも自然に合います。
メールAPIでの送信はどう機能しますか？
コードから、プロバイダーのHTTPSエンドポイントをJSONデータとともに呼び出します。宛先、本文またはテンプレートの参照、タグ、メタデータに加え、重複送信を防ぐための冪等性キーを付けることもよくあります。応答は同期的で、メッセージIDとともに成功が返るか、コードで捕捉して再試行できるエラーが返ります。Postmarkのドキュメントはこの違いを明示しています。同社のREST APIは成功かエラーをすぐに返し、SMTPエンドポイントはすべてのメッセージを受け付けたうえで、エラーをバウンスとして記録します。そのバウンスは、バウンス用のWebhookで引き続き取得できます。受け付けたあとは、Webhookがバウンス、迷惑メール報告、開封をアプリに送り返します。これが、送信除外の自動化を可能にしています。プロバイダーのSDKを使えば、これらすべてを数行で書けます。その代わり、連携はそのプロバイダー専用になります。
SMTPとAPIの比較
判断のすべては、1つのトレードオフに集約されます。SMTPで得られるのは移行のしやすさ、APIで得られるのはフィードバックとツールです。項目ごとに見ると、次のようになります。
| SMTP | メールAPI | |
|---|---|---|
| 概要 | オープンなプロトコル（RFC 5321）。どこでも同じ | プロバイダーごとに異なる、HTTPS上の製品インターフェース |
| 連携の手間 | ソフトウェアがすでにSMTPに対応していればほぼゼロ。ホスト、ポート、認証情報だけ | プロバイダーのエンドポイントやSDKに合わせたコードが必要 |
| 移行のしやすさ | 高い（プロバイダーの乗り換えは認証情報の差し替えで済む） | 低い（プロバイダーごとに形式が異なり、乗り換えには連携の書き直しが必要） |
| 失敗時の扱い | 送信時に受け付けられ、一部の失敗はあとから非同期のバウンスとして表れる | 捕捉して再試行できる同期的なエラーと、非同期のイベント |
| イベントのフィードバック | プロトコル自体にはなし。SMTPで送ったメールもプロバイダーのバウンス用Webhookで把握できるが、別途つなぎ込みが必要 | Webhookがバウンス、迷惑メール報告、開封をアプリに通知 |
| テンプレートと分析 | プロトコル自体にはなし。完成したメッセージを送る | テンプレートの参照、タグ、メッセージごとのメタデータ |
| セルフホストとの相性 | 自然。セルフホストのソフトウェアは最初からSMTPに対応 | スタックに、ベンダー固有の依存関係が1つ増える |
SMTPが適しているのはどんなときですか？
- すでにSMTPに対応しているソフトウェア。CMS、フォーラム、ヘルプデスク、レガシーアプリは、新しい認証情報を入れるだけでプロバイダー経由の送信を始められます。
- 移行のしやすさを最優先するとき。コードに手を入れずにプロバイダーを替えられる自由が欲しいなら、SMTPが中立なインターフェースです。
- セルフホストのスタック。自社のインフラで動かすものには、ほぼすべてSMTPへの対応が組み込まれており、SDKは要りません。
- 少量の業務メール。cronのアラートや社内通知のために、専用のAPI連携を組むほどの価値はまずありません。
APIが適しているのはどんなときですか？
プロダクトから大規模に送信するときです。オンボーディング、領収書、ライフサイクルのフローなど、メールがアプリケーションに組み込まれているなら、同期的なエラー、テンプレートの参照、イベントのWebhookは連携のコストに見合います。アドレスがバウンスしたり迷惑メール報告を受けたりした瞬間に、送信除外リストを自動で更新することもできます。ただし、APIで評価は買えません。評価は送信の経路ではなく送信ドメインに付くため、ドメインのウォームアップと認証は、どちらの方法で送信してもまったく同じように必要です。
fromHelloが両方に対応している理由
この選択は到達率ではなく連携の問題なので、fromHelloは両方のアダプターを備えています。HTTP API（Resend、Postmark、SendGrid）、任意のSMTPサーバー、Microsoft 365のメールボックスです。ワークスペースごとに既定のプロバイダーを設定でき、テンプレートごとに専用のプロバイダーを指定することもできます。アーリーアクセス中のfromHello Cloudでは、Teamプラン以上にメール送信の設定が含まれます。Coreプランやセルフホストでは、プロバイダーを自社で用意します。いずれの場合も、上限はプロバイダー側で決まります。たとえばResendは、SMTPエンドポイントにもAPIと同じレート制限を設けていると明記しています。そして送信除外リストと同意は、送信の経路に関係なくプラットフォームが適用します。送信除外されたアドレスは、メッセージがHTTPSで出ていくか587番ポートで出ていくかにかかわらず、除外されたままです。