ランディング · 無料SMTPサービス

プロダクトチームが無料SMTPサービスを選ぶときは、何を評価すべきですか？

無料SMTPサービスは、コストゼロのホスト名としてではなく、制約のある本番環境の依存先として評価します。その提供内容が継続的な無料枠なのか期限付きのトライアルなのか、どのメッセージ、受信者、バイト数、ログ、イベント、サポートが上限にカウントされるのか、上限に達したときに何が起きるのか、支払い情報の登録や自動的な超過課金が必要かを確認してください。そのうえで、TLSの必須化、スコープ付きの認証情報、検証済みの送信ドメイン、SPF、DKIM、DMARCアライメント、一部の受信者だけが失敗した場合の挙動、4xxと5xxの応答、バウンス、苦情、サプレッション、保持、エクスポート、削除をテストします。移行コストはリリース前に見積もり、無料枠で受け付けられたことを配信や受信トレイへの到達と同一視してはいけません。

「無料」の意味は現行の契約から定義する

「無料」という言葉は、継続的な無料枠、期間限定のトライアル、初回特典のクレジット、検証済みの受信者に限ったテスト、一時的なクレジット付きの有料プランなどを指すことがあります。評価する当日に、プロバイダーの現行の料金と規約を読んでください。通貨、リージョン、税、支払いカードの要否、トライアルの期限、含まれる単位数、超過時の挙動、停止時の挙動、ダウングレード時に使えなくなる機能を記録します。検索結果の抜粋、古い比較記事、スクリーンショット、あるいは確かな契約上の根拠がない営業チャットに頼ってはいけません。AWS SES、Resend、Mailgunはそれぞれ公式ページで異なる料金モデルと含まれる機能を公開しており、どれも互換性があると想定すべきではありません。確認したページのURLと取得日を判断に紐付け、プロバイダーの提供内容は変わりうるため、リリース前の再確認を予定しておきましょう。導入費用が無料でも、エンジニアリング、DNS、監視、プライバシー、インシデント対応、移行にかかるコストはなくなりません。

課金単位と運用単位でワークロードをモデル化する

メッセージ数、受信者数、添付ファイル、バイト数、APIまたはSMTPのリクエスト数、イベントの配信数、受信メール、保存されるコンテンツ、ログの保持、ドメイン数、チームメンバー数、環境の数を見積もります。複数の受信者を含むメッセージは、受信者が1人のトランザクションとはクォータの消費の仕方が異なる場合があります。再試行、テスト用のトラフィック、ウォームアップ、バウンス、Webhookの再送によって送信量が増えることもあります。平均、ピーク時の1分、ピーク時の1時間、1日、1か月、季節ごとの需要に加え、成長とインシデントに備えた余裕を計算してください。アプリケーション側のレート制御はプロバイダーの上限より低く設定し、テナント同士が影響し合わないように保護します。残りの単位がゼロになったときに何が起きるかを確認しましょう。ハードな拒否、送信の保留、自動課金、機能の制限、あるいはログが黙って失われるのか、といった点です。送信の呼び出しはカバーしていても、実用的なイベント履歴、サポート、サプレッションのエクスポートが含まれない無料枠は、小規模な有料プランより運用面で高くつくことがあります。本番運用の前に、管理されたトラフィックでアカウントのカウンターを実際に確認してください。

安全なSMTPサブミッションを必須にする

本番用のSMTPサービスは、保護されたサブミッション、対応ポート、TLSの挙動、認証方式、証明書の要件、認証情報のスコープ、ローテーションについてドキュメント化しているべきです。TLSを必須にすることを優先し、STARTTLSがない場合、証明書の検証に失敗した場合、ホスト名が一致しない場合、未対応のプロトコルの場合は、安全側に倒して失敗させてください。認証情報は管理された秘密情報ストアに保存し、ブラウザのコード、モバイルアプリ、ソースコード、イメージ、ログ、URL、アナリティクス、チケット、プロンプトには決して含めないでください。本番、テスト、テナント、管理者の権限を分離します。無料枠で認証情報、送信元IP、ドメイン、リージョン、同時接続数に制限があるかも確認しましょう。RFC 8314は、サブミッションとアクセスには平文のプロトコルを廃止してTLSを使うよう推奨しており、RFC 4954はSMTP認証をプロダクトの認可ではなくプロトコル拡張として定義しています。アプリケーションは、SMTP接続を開く前に、業務イベント、送信者、テナント、受信者、テンプレート、メッセージの種類を引き続き自ら認可する必要があります。

送信者IDとDNSの所有権を検証する

組織が所有するFromドメインと、文書化されたドメイン検証のプロセスを必須にします。SMTPのMAIL FROMまたはリターンパス、表示上のFrom、DKIMのd=ドメインとセレクター、送信IP、返信の扱いを洗い出してください。実際の経路を含む有効なSPFポリシーを1つだけ公開し、保護された鍵でDKIM署名を設定し、表示上のFromドメインとのDMARCアライメントを評価します。プロバイダーでの検証は、ある1つの設定チェックに合格したことの証拠にすぎません。受信者の同意、本番の正しいルーティング、レピュテーション、受信トレイへの到達を証明するものではありません。どのDNSレコードをプロバイダーが管理し、どれが組織の権威ゾーンに残るのかを把握しておきましょう。以前の値とロールバック手順を保存してください。本番のIDにプロバイダー専用のFromドメインを使うのは避けましょう。移植性が損なわれ、DMARCアライメントやブランドの継続性がベンダーに依存することになりかねません。すべてのストリームと環境について、実際に受信した生のメッセージをテストしてください。

受信者単位の有用な結果を求める

サービスは、SMTPまたはAPIでの受け付け、受信者単位の拒否、一時的な保留、恒久的な失敗、後から届くバウンス、苦情、配信停止、プロバイダーによるサプレッションを区別できなければなりません。無料枠で、これらの結果がどのように届けられ、認証され、再試行され、順序付けられ、保持され、エクスポートされるかを確認してください。Webhookはパースする前に認証し、鮮度と再送に対する制御を強制し、受信確認を返す前にイベントを永続的に取り込み、アプリケーションが管理する送信試行と関連付けます。受け付けられた受信者と拒否された受信者の範囲は別々に保存します。再試行の対象となる一時的な失敗は、上限付きのバックオフ、ジッター、試行回数の上限、キューの滞留時間の制限を設けて再試行してください。恒久的なアドレスの失敗、苦情、配信停止があった場合は、該当する範囲で自動送信を停止します。エクスポート可能な証跡のないダッシュボードは、運用上のロックインを生みます。プロバイダーの「配信済み」イベントは、多くの場合、最終的なメールボックスのフォルダではなく、宛先サーバーによる受け付けを表しています。開封やクリックはエンゲージメントの計測であり、プライバシー保護技術によって歪められることがあります。

料金ページの外にある制限を確認する

料金ページに運用上の契約がすべて書かれていることはまれです。受信者数、メッセージサイズ、添付ファイルのサイズ、接続レート、同時セッション数、APIのレート、DNSドメイン数、テンプレート数、Webhookの試行回数、イベントの保持期間、サプレッションの容量、トライアル時の受信者の制限について、現行のドキュメントを確認してください。サポート、監査ログ、専用IP、リージョン内での処理、受信ルート、コンプライアンス機能に有料プランが必要かどうかも確かめましょう。新規アカウントやトライアルのアカウントは上限が低かったり手動審査が入ったりすることがあるため、実際のアカウントでテストしてください。すべての制限を、出典URLと確認日とともに記録します。上限ちょうどで設計するのではなく、プロバイダーの変更、再試行、インシデントからの復旧に備えて余裕を残しましょう。ユーザーが指定した受信者の配列や添付ファイルによってアプリケーションが気づかないうちに上限を超えうる場合は、まずプロダクト側でより厳しい制限を設けてください。ドキュメント化されていない、あるいは不明確な制限は、無制限の容量ではなくリスクとして扱います。

プライバシー、セキュリティ、不正利用対策を評価する

メッセージのコンテンツ、受信者データ、ヘッダー、イベントのペイロード、IPアドレス、ログ、サポートによるアクセス、バックアップ、サブプロセッサーが、どのリージョンにまたがっているかを整理します。カスタムメタデータは最小限にし、タグやヘッダーに秘密情報や不要な個人データを入れないようにしましょう。無料アカウントの保持と削除の挙動を、解約後も含めて確認してください。テナントの分離、ロールベースのアクセス制御、MFA、監査履歴、認証情報のローテーション、Webhookの署名、サプレッションの認可、インシデントの通知を検証します。ヘッダーインジェクション、任意の送信者の選択、過剰な受信者数、添付ファイルの悪用、テナントをまたいだイベントの参照、リプレイをテストしてください。無料枠は不正利用の標的になりやすいため、プロバイダーが自動審査や即時の停止を行うことがあります。プロダクトには永続的なキューと、安全に一時停止できる経路が必要です。アカウント、ドメイン、認証情報、IPを切り替えて不正利用対策を回避することは決してしないでください。停止や移行によって受信者の保護が失われないよう、同意とサプレッションの状態はプロバイダーの外にも保持しておきましょう。

送信を始める前に乗り換えコストを計算する

プロバイダー固有のフィールドは1つのアダプターの背後にまとめ、アプリケーションのイベントモデルは独立させておきます。SMTPのホストと認証、APIのペイロード、テンプレート、送信ドメイン、リターンパス、DKIMセレクター、Webhook、イベント名、メッセージ識別子、タグ、サプレッション、受信ルート、ログを洗い出してください。サプレッションと運用履歴は、プロダクト側で検証できる形式でエクスポートできることを必須にします。移行では、業務イベントのキー、送信試行の履歴、同意、受信者の安全、送信者の所有権を維持しなければなりません。管理されたIDで2つ目の送信経路をテストしますが、受信者やポリシーの恒久的な失敗を自動的に迂回する経路として設定してはいけません。DNSの変更期間、認証情報のローテーション、テンプレートの変換、Webhookの二重処理、重複の防止、古いイベントの保持にかかる工数を見積もりましょう。乗り換えの際に証跡を失う、送信者IDを変える、あるいはインシデントの最中に安全対策を作り直すことになるなら、最も安い無料枠が誤った選択になることもあります。

本番運用の前に、採点方式で実証する

代表的なテストマトリクスを作成します。TLSのネゴシエーションと証明書の検証失敗、認証とローテーション、検証済みの送信者と認可されていない送信者、プレーンテキストとマルチパートのコンテンツ、Unicode、添付ファイル、一部の受信者だけの失敗、一時的・恒久的な応答、DATA後のタイムアウト、バウンス、苦情、配信停止、Webhookのリプレイ、順序が入れ替わったイベント、クォータの枯渇、プランの期限切れ、エクスポート、アカウントの閉鎖などです。専用の管理された受信者を使い、実際の顧客リストは決して使わないでください。セキュリティ、正確性、証跡、容量、プライバシー、サポート、移植性、総コストを個別に採点します。TLSの検証がない、ローテーションできない共有の秘密情報、テナント間での露出、恒久的な失敗の処理がない、サプレッションをエクスポートできない、黙って超過課金される、保持が不明確、といった場合はリリースを止めてください。料金プラン、送信経路、ドメイン、プロバイダーとの契約が変わったときは、実証をやり直します。無料プランが適切といえるのは、範囲が限られたリスクの低いワークロードで、制御と乗り換え計画が有料の依存先に求めるのと同じ基準を満たす場合に限られます。

SendHQの現在のプランを確認する

SendHQには無料プランがありません。新しいワークスペースには、アカウントのメールアドレスまたはAWS SESシミュレーターアドレスへの100件の配信を対象とする、管理された連携トライアルが提供されます。現在の有料プランの料金、送信枠、機能については、SendHQの料金ページを参照してください。

よくある質問

無料SMTPサービスは本番環境で安全に使えますか？

範囲が限られたワークロードであれば、TLS、スコープ付きの認証情報、送信者の認証、受信者の安全、証跡、プライバシー、容量、サポート、移行の条件をすべて満たす場合に限り、安全に使えることがあります。

無料枠とトライアルの違いは何ですか？

無料枠は現行の規約の下で継続的に使える枠であり、トライアルは期限切れになるか一時的なクレジットを消費するものです。現行の契約と上限時の挙動を確認してください。

チームはどの単位で比較すべきですか？

メッセージ数、受信者数、バイト数、添付ファイル、リクエスト数、イベント、受信メール、ログ、保持、ドメイン数、ユーザー数、環境の数、サポート、超過時の挙動を比較します。それぞれの単位を、平均、ピーク、成長、再試行、インシデント時の送信量で計算してください。

無料SMTPで受け付けられれば、配信されたことになりますか？

いいえ。受け付けは、プロバイダーまたは転送経路の1つの段階にすぎません。受信サーバーによる受け付け、後から届くバウンス、メールボックスのフィルタリング、受信トレイへの到達、人によるエンゲージメントは、それぞれ別の結果です。

サプレッションリストをプロバイダーにしか持たないのは問題ですか？

いいえ。移行や停止によって保護が失われないよう、同意と受信者の安全に関する状態は、証跡と監査履歴とともにプロダクト側で管理してください。その状態は、以後の送信試行のたびに直前に適用します。

クォータを使い切ったときはどう対処すべきですか？

新たな送信要求の受け付けを止めるか、有効期限に応じて永続的にキューに入れ、上限に達する前にアラートを出します。許可されていないアカウントやIDを切り替えて上限を回避することは決してしないでください。

無料サービスでもSPF、DKIM、DMARCは必要ですか？

送信IDには引き続き正しい認証とアライメントが必要です。無料プランだからといって、受信側の基準、ドメインの所有権、DNSの安全性が変わるわけではありません。

SendHQには無料プランがありますか？

いいえ。新しいワークスペースには、アカウントのメールアドレスまたはAWS SESシミュレーターアドレスへの100件の配信を対象とする、管理された連携トライアルが提供されます。

出典

さらに学ぶ

SMTPリレーサービスの評価方法サブミッションのセキュリティ、認証、キュー、再試行の挙動、上限、配信イベント、サプレッション、分離、移行のしやすさの観点からSMTPリレーサービスを評価します。Google SMTPリレーサービスの評価ガイド認可モデル、TLS、送信者ID、クォータ、エラー処理、認証、可観測性、移行リスクの観点からGoogle WorkspaceのSMTPリレーを評価します。プロダクトチームのためのメールAPI実装ガイド検証済みドメイン、キューを使った送信、安定した識別子、制御された再試行、配信イベント、サプレッション、テナント分離を備えた、安全なメールAPI連携を設計します。メール到達率改善サービスの評価方法対象範囲、根拠、認証、フィードバックループ、サプレッション、プライバシー、移植性、運用との適合性の観点から、メール到達率改善サービスを評価します。SMTPポート25・465・587の違い：実践ガイド役割とTLSモードに応じて適切なSMTPポートを選び、接続、ハンドシェイク、認証、メッセージ受け付けの失敗を診断します。