MAツールのメール送信基盤の選び方｜SendGrid・SESを比較【2026年最新】

自社で使っていたMAツールを、他社にも使ってもらえる形で提供する。そのとき最初につまずきやすいのが、メールをどこから送るかという問題です。自社1社分の配信なら、どの送信サービスでも大きな差は出ません。ところが利用企業が5社、10社と増えると、会社ごとに送信元ドメインを追加する手間と、1社の配信トラブルが全社に広がるリスクが一気に表に出てきます。

当社でも、開発しているMAツールを他社へ展開する段階で、SendGridを使い続けるか、Amazon SESに移すか、自社でメールサーバーを立てるかを比べました。結論はAmazon SESです。自社メールサーバーは選択肢から外しました。ここでは、その判断に使った比較表、SESに切り替えるときの実装の要点、月額コストの試算をそのまま公開します。

結論：他社展開するならAmazon SES、自社サーバーは選ばない

判断の決め手は、送信ドメインを追加するたびに人の審査が入るかどうかでした。

• SendGrid：送信元ドメインの認証（Sender Authentication）やサブユーザーを追加するたびに、アカウントの審査や制限が関わってくる。利用企業が増えるほど、この待ち時間がボトルネックになる。
• Amazon SES：本番利用の申請（サンドボックス解除）はリージョンごとに最初の1回だけ。その後のドメイン追加は、利用企業のDNSにEasy DKIM用のCNAMEレコードを3本置いて検証するだけで、ドメインごとの人による審査はない。
• 自社メールサーバー：審査はないが、送信IPの評判（IPレピュテーション）をゼロから育てる必要がある。配信そのものが本業でない会社には割に合わない。

ただし、いきなり全部を移す必要はありません。当社は、自社の配信はSendGridのまま残し、他社向けの配信だけをSESで新しく組む並行運用から始めています。

SendGrid・Amazon SES・自社メールサーバーの比較表

比較した観点は9つです。マルチテナント（1つのシステムを複数の会社で共用する形）で配信する前提で評価しています。

表を横に読むと、SendGridが劣っているわけではないことが分かります。自社1社で使う分には十分です。差が出るのは「送信ドメインを次々に増やす」という使い方をしたときで、ここでSESの手軽さが効いてきます。

自社メールサーバーを候補から外した理由

「サーバー代が月数千円で済むなら自前が一番安いのでは」という意見は社内でも出ました。外した理由は3つです。

1. 新しいIPは信用がない。Gmailなどの受信側は、送信実績のないIPからの大量配信を疑ってかかります。少ない通数から数週間かけて増やすウォームアップが必要で、その間は利用企業のメールを安心して流せません。
2. 1社の失敗が全社に及ぶ。同じIPから複数の企業が送るため、ある企業が古いリストに一斉送信してブロックリストに載ると、ほかの企業のメールまで届かなくなります。解除の申請も自社で行います。
3. 送信者要件の監視を全部抱える。2024年からGmailとYahooは、一括送信者にSPF・DKIM・DMARCの設定、ワンクリックでの配信停止、迷惑メール報告率0.3%未満を求めています。これらを自前のサーバーで満たし続ける運用は、配信を本業にしていない会社には重い負担です。

機材費だけで比べると自前が安く見えますが、実際の費用は運用の人件費と、メールが届かなかったときの機会損失で決まります。通数あたりの単価で並べて比べること自体が成り立たない、というのが当社の判断です。

Amazon SESに切り替えるときの実装ポイント10項目

当社のMAツールは、メール送信の処理が1つのモジュールにまとまっていたため、差し替える範囲は小さく済みました。実際に洗い出した項目は次の10個です。

1. 送信処理は呼び出し方を変えずに中身だけ差し替える

既存の送信関数の引数（宛先・件名・本文・HTML本文・オプション）はそのまま残し、内部だけをSESv2のSendEmail APIに置き換えます。呼び出し側のコードを1行も触らずに済むので、テスト範囲を送信モジュールに絞れます。

2. 開封・クリックの計測はメッセージタグとイベント送信先へ移す

SendGridでメールに付けていた独自の識別情報は、SESではメッセージタグ（EmailTags）で持たせます。開封・クリック・バウンスの通知は、Configuration Setのイベント送信先からSNSを通して、これまでと同じ受け口で受け取る構成にしました。

3. 利用企業にはメール送信用のサブドメインを用意してもらう

利用企業には mail.企業ドメイン.co.jp のような送信専用のサブドメインを作ってもらい、そこにEasy DKIMのCNAMEレコードを3本置いてもらうだけにします。メインのドメインの設定に手を入れないので、企業側の情報システム担当者も承認しやすくなります。

4. サンドボックス解除の申請は具体的に書く

AWSアカウントを作った直後のSESは、検証済みのアドレスにしか送れないサンドボックス状態です。本番利用の申請では、MAツールであること、配信先からの同意の取り方、配信停止の導線、バウンスの処理方法を具体的に書くと通りやすくなります。申請はリージョンごとに必要です。

5. 抑制リストを有効にし、配信停止の管理と同期する

SESのアカウント単位の抑制リスト（バウンスや苦情があったアドレスを自動で送信対象から外す仕組み）は必ず有効にします。ツール側にも配信停止リストがあるので、両者がずれて「片方では停止、片方では配信」とならないように同期させます。

6. 利用企業ごとのブレーカーを持つ

SESはバウンス率と苦情率を、利用企業ごとではなくAWSアカウント全体でも見ています。1社が質の悪いリストに送り続けると、アカウントごと送信停止になり、全社の配信が止まります。そこで企業ごとにバウンス率・苦情率を監視し、しきい値を超えたらその企業の送信だけを自動で止める仕組みをツール側に作ります。今回の検討で最大のリスクと判断した点で、省略はできません。

7. Gmail・Yahooの送信者要件をアプリ側で満たす

ワンクリック配信停止のための List-Unsubscribe と List-Unsubscribe-Post ヘッダーは、送信時にアプリ側で付けます。DMARCは利用企業のドメイン側で設定するものなので、導入時の手順書に設定方法を入れておきます。SPF・DKIM・DMARCそれぞれの役割はSPF・DKIM・DMARCの導入方法とリスクの解説で整理しています。

8. 大口の企業には専用IPを割り当てる

最初は共有IPで十分です。送信量の多い企業が付いた時点で専用IP（Dedicated IP）をその企業に割り当て、ほかの企業と評判を切り離します。

9. 送信サービスを企業ごとに切り替えられる形にする

企業ごとの設定に「SendGridで送るか、SESで送るか」を持たせておくと、自社分はSendGrid、新しい利用企業はSESという並行運用ができます。問題が出たときに企業単位で戻せるので、移行のリスクを小さくできます。企業ごとに設定や権限を分ける考え方は、アカウントごとの権限に変えたSaaSの権限設計の実例でも紹介しています。

10. 送信APIには認証・日次上限・入力検証を付ける

メールを送れるAPIは、外から叩かれると大量送信や課金の暴走につながります。認証を必須にし、1日あたりの送信上限と入力内容の検証を入れ、サーバー側でも同時に立ち上がるインスタンス数の上限を決めておきます。

月額コストの試算：10社×月5万通なら約7,500円

SESの料金は、2026年10月時点の公表値で1,000通あたり0.10ドルです。利用企業10社がそれぞれ月5万通送る場合で計算しました（為替は1ドル150円で仮置き）。

通数に比例して費用が決まるので、利用企業1社あたりの原価が出しやすく、利用料金の設定にもそのまま使えます。1社あたりに直すと、月5万通で約750円です。専用IPは、その企業の送信量と料金プランで回収できるようになってから足せば足ります。

まとめ

自社だけで配信するなら、今の送信サービスを無理に変える必要はありません。他社にもMAツールを提供し、送信ドメインを増やしていくなら、ドメイン追加がDNS設定だけで終わるAmazon SESが向いています。自社メールサーバーは、機材費の安さよりも評判の管理と送信者要件への対応の重さが上回ります。

移行するときは、既存の配信を残したまま新しい利用企業からSESに載せること、そして企業ごとのバウンス率・苦情率で送信を自動停止するブレーカーを最初から用意すること。この2点を先に決めておけば、1社のトラブルで全社の配信が止まる事態を避けられます。