インフラとしての SMTP リレー

SMTP リレー サービスで、結果を追える送信を

ホストとポートを変えるだけで、既存のコードはそのまま使えます。SMTP リレー サービス経由で送信されるすべてのメッセージについて、認証チェック、ウォームアップ、再試行、トレースを確認できます。

SMTP で送信を始める リレーが扱う範囲を見る
暗いサーバー通路の端で、青い状態ランプが光る監視端末に向かうエンジニア
リレーが扱う範囲

手作業をやめられる6つの仕事

SMTP リレーは手間を減らして初めて価値があります。ここに挙げるのは、送信メールの運用で cron ジョブと手順書の山になりがちな部分です。

そのまま使える SMTP エンドポイント

ポート 587 の STARTTLS、またはポート 465 の暗黙的 TLS に対応します。SMTP を話せるフレームワークのメーラー、CMS、既存システムは、ホストと認証情報を変えるだけで動きます。

認証を最初に検証

本番の初回送信の前に SPF、DKIM、DMARC のアラインメントを確認します。レコードの不備が、後続の設定をこっそり壊すことはありません。

固定スケジュールのウォームアップ

新しいドメインは約4週間かけて、1日50通から10万通まで段階的に増えます。送信のカーブは表計算ではなく、リレー側で強制されます。

指数バックオフ付きの再試行

4xx の一時的な失敗は指数バックオフで再試行します。5xx の拒否は即座に停止して分類されるため、存在しないメールボックスに一晩中送り続けることはありません。

送信ごとのトレース

メッセージごとに開封、クリック、バウンス、迷惑メールの信号を取得し、SSE で配信します。送信が失敗した場合は、生の SMTP レスポンスも添付されます。

既存のスタックへエクスポート

同じイベントを Datadog や Grafana に送り、配信をレイテンシやエラー率と同じように監視できます。

導入の流れ

ローカルの Postfix から中継まで、5つのステップ

移行の多くは半日で終わります。時間がかかるのはウォームアップの期間で、そこは人手なしで進みます。

  1. 1

    送信ドメインを追加

    サービスが提供する SPF の include と DKIM レコードを公開します。何かが送信される前に、アラインメントが検証されます。

  2. 2

    SMTP 認証情報を作成

    アプリケーションごとに範囲を絞った認証情報を発行します。1つのパスワードが漏れても、メールを送る他のサービスすべてが露出することはありません。

  3. 3

    メーラーをリレーに向ける

    ホストを設定し、ポート 587 と STARTTLS を使ってテストメールを送ります。Postfix の場合は main.cf の relayhost の1行で済みます。

  4. 4

    目標の送信量と期間を設定

    どの量まで、どれくらいの期間で到達したいかを決めます。コールドドメインでは、4週間で1日10万通が一般的な出発点です。

  5. 5

    トレースを確認してから切り替え

    一部の送信量を先に流し、トレースを読みます。バウンス率と苦情率が通常の範囲に収まったら、残りの送信量を移します。

想定する利用者

自社 Postfix の運用をやめるチームのために

自前で運用するメールサーバーは、ある日まで動き続けます。IP がブロックリストに載る、遅い受信先の後ろでキューが詰まる、設定を理解していた1人が退職する、といった日です。リレーが配信、評判、再試行を引き受け、アプリケーションは今までどおり SMTP エンドポイントへ送信し続けます。どのバッチがなぜバウンスしたかは、SSH でメールログを読む代わりに確認できます。

  • アプリがすでに使っている SMTP のインターフェースを維持
  • 面倒を見る必要のあるキューやブロックリストがない
  • ステータス表示だけでなく、トレースに生の SMTP レスポンスを含む
ターミナルのログと、メールサーバーを矢印で結んだノートのスケッチを並べたノートパソコン
想定する利用者

トランザクションメールの量が段階的に増えるプロダクトチームのために

トランザクションメールは段階的に増えます。新しいオンボーディングフローが公開され、機能が一般提供になり、1日の送信数が一晩で2倍になる。新しい量を裏側でウォームアップしておけば、パスワードリセットや領収書は、パイプラインが拡張される間も受信箱に届き続けます。何かが引っかかったときも、推測する代わりにアラートがどのシグナルかを示します。

  • 一定の成長だけでなく、段階的な増加にも対応
  • ウォームアップ中も既存のトランザクション送信は影響を受けない
  • バウンス率または迷惑メール率が閾値を超えたら自動停止
黄色いケーブルと青い状態ランプが光るサーバーラックのパッチパネル
比較

SMTP リレーは、自前運用と API の間のどこに位置するか

ランキングではありません。適切な選択は、既に運用しているものと、配信のどこまでを自社で持ちたいかによります。

比較項目自前の MTASMTP リレー サービスHTTP メール API のみ
既存の SMTP コードで動くはいはいいいえ、連携の実装が必要
IP とドメインの評判自社で管理ウォームアップ付きで管理ウォームアップ付きで管理
再試行とバウンス処理自前の設定組み込み、分類済み組み込み、分類済み
送信ごとのトレースサーバー上のメールログトレースと SSE イベントトレースと SSE イベント
冪等性キー利用不可API と SDK 経由ネイティブ対応
運用の負荷高い低い低い

よくある質問

SMTP リレー サービスとは何ですか。
アプリケーションから SMTP でメールを受け取り、認証を行い、受信先のメールサーバーへ代理で配送するマネージドサーバーです。既存のコードやフレームワークのメーラーはそのまま使い、変更するのはホスト、ポート、認証情報だけです。
SMTP リレーにはどのポートを使うべきですか。
多くのアプリケーションでは、STARTTLS を使うポート 587 を使います。暗黙的 TLS を使う場合はポート 465 です。ポート 25 はサーバー間の通信用で、多くのクラウドプロバイダーが外向きをブロックするため、リレー経由で送信するアプリには通常適しません。
SMTP リレーとメール API はどう違いますか。
どちらも同じ配信パイプラインに届きます。SMTP は互換性のための経路で、SMTP を話せるフレームワーク、CMS、既存システムなら何でも変更なしで動きます。HTTP API と Node、Python、Go の SDK は、新規コード向けに冪等性キーと構造化されたエラーを追加します。
リレーを使っても SPF、DKIM、DMARC は必要ですか。
はい。リレーは署名して送信しますが、ドメインがそれを許可している必要があります。サービスは本番の初回送信の前に SPF と DKIM のアラインメントを確認します。レコードの欠落は、移行後にメールが迷惑メールに入る最も一般的な原因だからです。
自前の Postfix サーバーから、停止なしで移行できますか。
できます。Postfix をリレーへのスマートホストとしてポート 587 に向け、少量の送信量を先に流して、トレースを確認します。バウンス率と苦情率が正常に見えたら、残りを移し、直接配送の経路を廃止します。
送信が失敗した場合や、受信先のサーバーが混雑している場合はどうなりますか。
4xx の遅延などの一時的な失敗は、指数バックオフで再試行されます。mailbox unknown の 550 のような恒久的な失敗はハードバウンスとして分類され、再試行を止めて、生の SMTP レスポンスとともに送信ごとのトレースに表示されます。
新しいドメインは、初日から受信箱に届きますか。
確実には届きません。コールドドメインには評判がないため、送信量は段階的に増やすべきです。ウォームアップは1日50通から10万通まで約4週間かかり、バウンス率または迷惑メール率が閾値を超えると、送信は自動的に一時停止します。
月に数千通の送信でも、リレーを使う価値はありますか。
少量でも、多くの場合は価値があります。回避できるコストは運用の負担だからです。IP の評判の維持、キューの監視、バウンス処理がそれにあたります。新しいオンボーディングフローや一般提供の開始などで送信量が段階的に増える場合に、その効果は最も大きくなります。

ホストを1つ変えるだけで、残りのスタックはそのまま

メーラーをリレーに向け、ドメインをウォームアップし、送信ごとのトレースを確認します。ウォームアップと自動停止は、初期設定でオンになっています。

無料で始める ロールアウトの流れを見る
notificationharbor
無料で始める