# SMTP リレー サービス：認証・ウォームアップ・配信トレース URL: https://notificationharbor.com/ja/lp/smtp-relay-service Type: landing Locale: ja Published: 2026-11-11 Updated: 2026-11-12 --- > SMTP リレー サービスに求められる条件を整理しました。ポート 587 での受け付け、送信ドメインの認証チェック、4週間のウォームアップ、再試行の制御、送信ごとのトレースです。 *インフラとしての 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. **送信ドメインを追加** — サービスが提供する SPF の include と DKIM レコードを公開します。何かが送信される前に、アラインメントが検証されます。 2. **SMTP 認証情報を作成** — アプリケーションごとに範囲を絞った認証情報を発行します。1つのパスワードが漏れても、メールを送る他のサービスすべてが露出することはありません。 3. **メーラーをリレーに向ける** — ホストを設定し、ポート 587 と STARTTLS を使ってテストメールを送ります。Postfix の場合は main.cf の relayhost の1行で済みます。 4. **目標の送信量と期間を設定** — どの量まで、どれくらいの期間で到達したいかを決めます。コールドドメインでは、4週間で1日10万通が一般的な出発点です。 5. **トレースを確認してから切り替え** — 一部の送信量を先に流し、トレースを読みます。バウンス率と苦情率が通常の範囲に収まったら、残りの送信量を移します。 *想定する利用者* ## 自社 Postfix の運用をやめるチームのために 自前で運用するメールサーバーは、ある日まで動き続けます。IP がブロックリストに載る、遅い受信先の後ろでキューが詰まる、設定を理解していた1人が退職する、といった日です。リレーが配信、評判、再試行を引き受け、アプリケーションは今までどおり SMTP エンドポイントへ送信し続けます。どのバッチがなぜバウンスしたかは、SSH でメールログを読む代わりに確認できます。 - アプリがすでに使っている SMTP のインターフェースを維持 - 面倒を見る必要のあるキューやブロックリストがない - ステータス表示だけでなく、トレースに生の SMTP レスポンスを含む *想定する利用者* ## トランザクションメールの量が段階的に増えるプロダクトチームのために トランザクションメールは段階的に増えます。新しいオンボーディングフローが公開され、機能が一般提供になり、1日の送信数が一晩で2倍になる。新しい量を裏側でウォームアップしておけば、パスワードリセットや領収書は、パイプラインが拡張される間も受信箱に届き続けます。何かが引っかかったときも、推測する代わりにアラートがどのシグナルかを示します。 - 一定の成長だけでなく、段階的な増加にも対応 - ウォームアップ中も既存のトランザクション送信は影響を受けない - バウンス率または迷惑メール率が閾値を超えたら自動停止 ## SMTP リレーは、自前運用と API の間のどこに位置するか | 比較項目 | 自前の MTA | SMTP リレー サービス | 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つ変えるだけで、残りのスタックはそのまま メーラーをリレーに向け、ドメインをウォームアップし、送信ごとのトレースを確認します。ウォームアップと自動停止は、初期設定でオンになっています。 *Call to action: 無料で始める* ## FAQ ### 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 の評判の維持、キューの監視、バウンス処理がそれにあたります。新しいオンボーディングフローや一般提供の開始などで送信量が段階的に増える場合に、その効果は最も大きくなります。