独自SMTP：SES、SendGrid、Mailgunで中継するタイミング

管理型送信が適切な標準であり、独自SMTPは代替手段です。管理型送信では、別の運用者がIP評価を管理し、ブロックリストを監視し、フィードバックループへ対応します。深夜に共有IPがリストへ載った場合の対応も担当します。多くの送信者にとって、すべてを自分で行うより有利です。

独自SMTPでは、外向きメールを自分のAmazon SES、SendGrid、Mailgun、Postmarkアカウント経由で送ります。三つの具体的な状況では本当に適していますが、実際には正しくない二つの理由で選ばれることも少なくありません。

自分がどの状況に該当するか、導入時のドメイン別SMTPルーティングがどう機能するかを説明します。

独自SMTPで実際に変わること

変わるのは外向き経路だけです。受信メールは引き続きMXレコード経由で当社サーバーに届き、フィルターされ、同じメールボックスへ入ります。送信時の最後のホップが変わり、メッセージを当社の送信基盤へ渡す代わりに、お客様のプロバイダーへ認証して引き渡します。

それ以降はプロバイダー側の領域です。IPアドレス、評価、レート制限、バウンス処理、抑制リストも同社のものになります。運用者を別の会社へ替え、新しい会社との関係を自ら管理することになります。

具体的には、次の項目がお客様側へ移ります。

独自SMTPを選ぶ三つの妥当な理由

1. プランの想定を超える送信量。 プランの上限は、メールボックスごとに一日数千通程度までです。月に数十万件のトランザクションメッセージを送るなら、専用送信プロバイダーのほうが安く、用途にも適している場合があります。それが同社の製品だからです。メールボックス基盤に大量配信を無理に通すべきではありません。

2. すでに取引関係がある。 アプリが温まった専用IPのSESを通じて領収書やパスワード再設定を送信しているなら、スタッフメールも同じ場所から送ることで、二つの送信元に分けず評価を集約できます。構成要素が減り、問題発生時に確認するコンソールも一つになります。

3. Nanoを利用している。 Nanoには管理型送信が含まれないため、独自SMTPが送信方法です。回避策ではなく、想定された経路です。

成立しない二つの理由

「配信性能が向上する」通常はそうならず、当初は逆になる場合もあります。成熟したプロバイダーの共有プールには、数千の送信者が築いた評価があります。新しいSESサブアカウントには評価がありません。ゼロから始まり、評価を得るまで大手受信者には未知の送信者として扱われます。専用IPを温め、維持できるだけの送信量がなければ、自分で築かずに済んだ良い評価を、これから築く空白の評価と交換することになります。

「送信制限を回避したい」新しいドメインからの大量送信は侵害されたアカウントのように見え、受信者がそれに応じて反応するため、制限があります。別経路で送っても、突然一万件を送るドメインに対するGmailの評価は変わりません。プロバイダーも段階的な増量を求め、超過すればアカウントを停止する可能性があります。手動解除が必要な停止は、レート制限より深刻です。送信制限とドメインのウォームアップをご覧ください。

ドメイン別の独自SMTPと再利用可能なプロファイル

独自SMTPはドメインごとに設定します。これは想像以上に便利です。

各ドメインが独自の外向き経路を指定します。一つはSES経由、別のドメインは管理型送信、三つ目はまったく別のプロバイダーを利用できます。代理店なら、独自インフラを希望する顧客だけに提供し、他の顧客の設定を変えずに済みます。

認証情報はドメインごとに入力するのではなく、アカウントのプロファイルとして保存されます。SESを一度追加し、そのプロファイルを必要な数のドメインへ関連付けます。認証情報のローテーション時も一か所だけ変更します。同じ情報を六回入力すると、五つが古いまま残りやすくなります。

設定方法：ドメインのSMTPタブを開き、保存済みの独自SMTPプロファイルを選ぶか、ホスト名、ポート、ユーザー名、パスワードを使って作成します。保存前に必ずテストしてください。実際のSMTPセッションを開いて認証します。テストを省くと、重要なメールを送る瞬間に認証情報の不備が発覚し、そのエラーがお客様ではなく送信者に表示されます。

見落とされがちなDNS設定

独自SMTPにすると、ドメインを代表して送信するサーバーが変わるため、DNSにも反映が必要です。省略すると、すべてのメッセージが認証に失敗します。

SPFに新しい送信元を含めます。プロバイダーはinclude:amazonses.com、include:sendgrid.netなどのincludeメカニズムを公開します。二つ目のレコードとして公開せず、既存レコードへ追加してください。一つのドメインに二つのSPFレコードがあると無効な構成になり、どちらも機能しません。

検索枠を確認します。SPFで許可されるDNS検索は十回です。includeはそれぞれ少なくとも一回を消費し、プロバイダーのincludeは頻繁に入れ子になります。三つ目の送信元を加える際に上限をひそかに超え、レコードが恒久エラーになる場合があります。SPF検索上限をご覧ください。

DKIMはプロバイダーから提供されます。プロバイダーは独自キーで外向きメールへ署名するため、同社のDKIMレコードを当社のレコードと併存させます。多くの場合、公開するCNAMEは二つか三つです。同社経由で送信し、当社だけが署名したメールはDKIMに失敗します。

DMARCアライメントも必要です。DMARCでは、SPFまたはDKIMを表示上のFromドメインと合わせる必要があります。お客様のドメインではなくプロバイダー自身のドメインで署名する設定は、DKIMには合格してもアライメントに失敗し、DMARCも失敗します。BYO-SMTP移行で最も起きやすい問題の一つで、レポートが届くまで見えません。DMARCアライメントをご覧ください。

デスクトップクライアントは別の判断

独自SMTPルーティングは、Webメールで作成したメールや当社APIから送信したメールに適用されます。デスクトップクライアントは、設定されたSMTPサーバーへ直接送信します。

妥当な構成は二つです。クライアントを当社へ接続し、ドメインの経路を適用すれば、変更箇所を一つにできます。またはクライアントをプロバイダーへ直接接続し、ホップを減らしてわずかに高速化できます。

一部のクライアントだけ別の方式にすることは避けてください。外向き経路が二つあると、認証結果も調査箇所も二組になり、どの端末がどちらか分からなくなります。

新たに管理するもの

バウンス処理。プロバイダーで生じたハードバウンスは、プロバイダー側で抑制します。ダッシュボードには当社基盤が観測した内容が表示されますが、相手側のキューは見えません。

苦情フィードバックループ。スパム苦情は送信IPの所有者へ届きます。プロバイダーで転送または保存を設定し、実際に確認してください。苦情率の上昇は、配信性能が低下する前に得られる初期の警告です。

認証情報のローテーション。期限切れのSMTPパスワードは次の送信で失敗します。プロファイルで更新し、誰かが気付く前にテストボタンで確認してください。

プロバイダー独自の規則。SESはサンドボックスから始まり、検証済みアドレスにしか送信できません。解除には用途を説明するサポート依頼が必要です。金曜日の移行中に初めて知るチームもあります。

よくある質問

独自SMTPで受信方法は変わりますか？

いいえ。変わるのは外向き経路だけです。受信メールは引き続きMX経由で当社サーバーへ届き、同じフィルターを通って同じメールボックスへ入ります。

ドメインごとに異なるSMTPプロバイダーを使えますか？

はい。独自SMTPはドメインごとのため、一つはSES、別のドメインは管理型送信を利用できます。認証情報は再利用可能なアカウントレベルのプロファイルとして保存されます。

独自SMTPで配信性能は向上しますか？

それだけでは向上せず、当初は逆になることもあります。新しいプロバイダーのサブアカウントには評価がありません。専用IPを温めて維持できる送信量がある場合や、すでに確立した送信関係へ集約する場合に役立ちます。

SPFとDKIMレコードは引き続き必要ですか？

以前より重要です。プロバイダーのSPF includeを既存レコードへ統合し、同社のDKIMレコードを公開します。同社経由でも当社だけが署名したメールはDKIMに失敗し、署名の不一致はDMARCに失敗します。

独自SMTPで送信制限はなくなりますか？

当社の代わりにプロバイダーの制限が適用されます。段階的な増量要件は通常より厳しく、超過するとレート制限ではなくアカウント停止になる場合があります。

プロバイダーが停止したらどうなりますか？

その経路を使うドメインの外向きメールは、復旧するまで失敗します。管理型送信は代替経路ではなく、ドメインは設定済みの経路を使います。

Nanoプランでは独自SMTPが必要ですか？

はい。Nanoには管理型送信が含まれないため、このプランでは独自SMTPで外向きメールを送ります。

APIから独自SMTPを設定できますか？

はい。独自SMTPプロファイルとドメイン別ルーティングは、接続テストを含めてREST APIとMCPの両方から利用できます。