ウェブ開発でメール送信サービスを選ぶならどれ？ SendGrid・AWS SES・Resend・Nodemailer + Postfix、主要サービスを徹底比較【2026年版】

2026年3月20日2026年3月29日

ウェブアプリケーションにメール機能を組み込むとき、自前のSMTPサーバーを立てる時代はとうに過ぎた。現在は外部のメール送信APIを使うのが標準的なアプローチだが、選択肢が多すぎてどれを選べばいいか迷う開発者は多い。

特に個人開発者やフリーランスにとっては、「SendGridは日本では法人限定」「AWS SESはセットアップが重い」といった事情もあり、サービス選びのハードルが高い。

本記事では、法人向けの定番である SendGrid と AWS SES に加え、個人開発者から支持を集めている Resend の3サービスを軸に、導入方法からメリット・デメリット、そして他の主要サービスやGmail SMTP・レンタルサーバーのメール機能まで幅広くカバーする。個人開発でも法人プロジェクトでも、自分の状況に合ったサービスを選べるようになることを目指す。

なぜ外部メール送信サービスを使うべきなのか

自前でメールサーバーを運用すると、SPF・DKIM・DMARCといった認証設定の管理、IPレピュテーションの維持、バウンス処理、スパムフィルタへの対応など、本業とは無関係な運用コストが積み上がる。

外部サービスを使えば、これらのインフラ面を丸ごと委託でき、開発者はアプリケーション側のロジックに集中できる。配信到達率（デリバラビリティ）の面でも、専業のサービスが持つIPレピュテーションの恩恵を受けられるため、自前運用より格段に有利だ。

SendGrid（Twilio SendGrid）とは

SendGridは2009年に創業し、現在はTwilio傘下にあるメール送信プラットフォームだ。
トランザクションメール（パスワードリセット、注文確認など）とマーケティングメール（ニュースレター、プロモーションなど）の両方を1つのプラットフォームで扱える点が大きな特徴になっている。

SendGridの導入方法

導入は非常にシンプルだ。アカウントを作成したら、送信ドメインのDNSにSPFとDKIMのレコードを追加し、APIキーを発行する。あとはSDK（Node.js、Python、Ruby、Go、Java、C#など主要言語に対応）をインストールして数行のコードを書くだけで送信できる。

const sgMail = require('@sendgrid/mail');
sgMail.setApiKey(process.env.SENDGRID_API_KEY);

const msg = {
  to: 'user@example.com',
  from: 'noreply@yourdomain.com',
  subject: '注文確認',
  html: '<p>ご注文ありがとうございます。</p>',
};

await sgMail.send(msg);

GUIのテンプレートエディタも用意されているため、非エンジニアのマーケティング担当者でもメールのデザインや配信設定を操作しやすい。

SendGridのメリット

SendGridの最大の強みは、メールに関する機能がオールインワンで揃っている点にある。ドラッグ＆ドロップのテンプレートビルダー、開封率やクリック率のトラッキング、A/Bテスト、IPウォームアップの自動化、バウンス・サプレッション管理など、メール運用に必要な機能が標準で組み込まれている。

ダッシュボードが直感的に操作でき、配信状況をリアルタイムで把握しやすいのも利点だ。ドキュメントやチュートリアルも充実しており、初めてメールAPIを使う開発者でもスムーズに立ち上げられる。

SendGridのデメリット

日本では個人利用ができない。 これはSendGridを検討する際に最初に知っておくべき重要な制約だ。日本国内でのSendGrid提供は正規代理店である構造計画研究所が担っており、利用規約上「法人向けサービス」と明記されている。個人開発者やフリーランスがアカウントを作ろうとしても審査で弾かれる。以前は個人でも登録できた時期があったが、現在は法人限定に変更されている。

「では本家のsendgrid.comから直接登録すればいいのでは？」という情報がネット上に散見されるが、これも注意が必要だ。Twilioの利用規約（Terms of Service）には冒頭で「THE SERVICES ARE INTENDED FOR BUSINESS USE OR USE IN CONNECTION WITH AN INDIVIDUAL’S TRADE, CRAFT, OR PROFESSION ONLY」と明記されており、純粋な個人利用は想定されていない。さらに日本向けの条項（Section 10.4.1）では「The Services are intended for business use by corporate or business entities, and you agree that you will not use the Services for any personal or individual use」とより明確に制限されている。フリーランスや個人事業主が自身のサービス・プロダクトのために業務利用する形なら規約上は許容される余地があるが、サポートは英語のみで、日本語対応は一切ない。個人開発で手軽に始めたい場合は、ResendやAWS SESなど個人利用に制限のないサービスを選ぶ方が無難だ。

料金面でも、2019年のTwilio買収以降、料金体系が段階的に引き上げられてきた。2025年5月には無料プランが廃止され、現在は60日間のトライアル後に有料プランへの移行が必須となっている。月間5万〜50万通あたりの中規模送信帯では、AWS SESと比較してコストが数倍になるケースがある。また、共有IPプールの品質低下を指摘する声もあり、デリバラビリティに影響が出ることがある。サポートの応答速度についても、上位プランでないと十分なレスポンスを得にくいという報告が散見される。

AWS SES（Amazon Simple Email Service）とは

AWS SESはAmazonが提供するクラウドベースのメール送信インフラだ。「メール送信エンジン」という表現がもっとも的確で、SendGridのようなフルプラットフォームではなく、あくまで送信に特化したサービスである。

AWS SESの導入方法

導入にはまずAWSアカウントが必要だ。AWSマネジメントコンソールからSESを有効化し、送信ドメインのDNS認証（SPF・DKIM）を設定する。初期状態ではサンドボックスモードになっており、検証済みアドレスにしか送信できない。本番利用にはAWSへのサンドボックス解除申請が必要で、利用目的やバウンス処理の仕組みなどを説明する必要がある。IAMでの権限設定も行う。

const { SESClient, SendEmailCommand } = require('@aws-sdk/client-ses');

const client = new SESClient({ region: 'ap-northeast-1' });

const command = new SendEmailCommand({
  Source: 'noreply@yourdomain.com',
  Destination: { ToAddresses: ['user@example.com'] },
  Message: {
    Subject: { Data: '注文確認' },
    Body: { Html: { Data: '<p>ご注文ありがとうございます。</p>' } },
  },
});

await client.send(command);

AWS SDKは主要言語に対応しているが、SendGridと比べるとセットアップに必要なステップが多い。

AWS SESのメリット

最大のメリットは圧倒的なコストパフォーマンスだ。1,000通あたり$0.10という従量課金で、月10万通送っても$10程度にしかならない。SendGridで同じ量を送ると$60〜$90以上かかるため、大量送信のコスト差は無視できない。EC2からの送信であれば毎月62,000通が無料になる特典もある。

また、Lambda・SNS・S3・CloudWatchなどAWSの他サービスとシームレスに連携できるため、バウンス処理の自動化やメール受信のトリガー処理をサーバーレスで構築できる。スケーラビリティも申し分なく、月間数十億通の規模まで対応可能だ。

AWS SESのデメリット

SESはあくまで送信エンジンなので、テンプレートビルダー、開封・クリックトラッキング、サプレッション管理、詳細なアナリティクスダッシュボードといった機能は自前で構築するか、CloudWatchやSNSなど他のAWSサービスを組み合わせて実装する必要がある。

AWSに慣れていないチームにとっては、IAM・リージョン選択・サンドボックス解除申請・SNSトピック設定など初期セットアップのハードルが高い。IPレピュテーションの管理やウォームアップも自己責任で行う必要があり、メール運用に詳しいエンジニアがいないチームでは運用負荷が大きくなりがちだ。

Resend

Resendは2023年に登場した比較的新しいサービスだが、開発者コミュニティで急速に支持を広げている。

個人利用に制限がなく、法人登録や審査も不要で、メールアドレスだけでアカウントを作成してすぐに使い始められる。

無料プランでは月3,000通（1日100通）まで送信でき、この無料枠に期間制限はない。
有料プランは$20/月からで、超過分は従量課金となる。

最大の特徴は、React Emailとの統合によりメールテンプレートをReactコンポーネントとして記述できる点にある。Next.jsやRemixなどのフレームワークとの相性が良く、既存のプロジェクトに数行のコードで組み込める。

APIの設計はシンプルかつ現代的で、エラーメッセージもわかりやすい。Node.js、Python、Ruby、Go、Elixir、PHPなど幅広いSDKを提供している。
2025年にはインバウンドメール処理（受信メールをWebhookで処理する機能）も追加され、プラットフォームとしての幅を広げている。

日本語でのサポートは提供されていないため、問い合わせは英語になる。

導入手順

アカウント作成はGitHubアカウントでスムーズにログイン可能です。

メイン認証設定（DNS編集が必要）

Resendから独自ドメインでメール送信するには、ドメインの所有証明が必要。

開発中の代替手段

ドメイン認証前でも onboarding@resend.dev というテスト用アドレスから自分宛にのみ送信可能。開発・テスト段階ではこれで進められる。

ウェブアプリAPI実装

パッケージインストール

npm install resend

Add domain

Add API Key

その他の注目サービス

Postmark — トランザクションメール特化で最速の配信

Postmarkは2009年から運営されている老舗で、トランザクションメールの配信速度と到達率に特化している点が特徴だ。マーケティングメールとトランザクションメールのインフラを完全に分離する「ストリーム分離」の仕組みにより、マーケティング送信が原因でトランザクションメールのデリバラビリティが低下するリスクを排除している。

メッセージの保持期間は45日間（最大365日まで拡張可能）で、トラブルシューティング時の追跡がしやすい。サポート品質にも定評がある。料金は月1万通で$15から。10万通で$95と、SESやMailgunと比較すると割高だが、配信の信頼性を最優先するサービスには適している。

Mailgun — 柔軟性とコストのバランス

MailgunはSinch傘下のメール送信サービスで、APIの柔軟性と豊富な機能が強みだ。メールのバリデーション（アドレスの存在確認）機能が組み込まれており、リスト管理やA/Bテスト、送信タイミングの最適化機能も標準で利用できる。トランザクションとマーケティングの両方に対応し、10万通で月$75と価格も比較的手頃。ただし、ログの保持期間が基本プランで5日間と短く、デリバラビリティの面でPostmarkほどの評価は得ていない。

Brevo（旧Sendinblue） — 非エンジニア向けのオールインワン

Brevoはメール送信だけでなく、SMS、チャット、CRMまでを1つのプラットフォームで提供する総合マーケティングツールだ。ビジュアルなオートメーションビルダーがあり、コードを書かずにメールフローを構築できるため、エンジニア以外のチームメンバーが主体的に運用する場合に向いている。無料プランで1日300通まで送信可能。ただし、デリバラビリティはPostmarkやSendGridと比較するとやや劣る。

Gmail SMTP — 個人開発者の「とりあえず」の選択肢

SendGridが日本国内では法人限定であること、AWS SESはセットアップのハードルが高いことから、個人開発者やサイドプロジェクトではGmailのSMTPサーバーを使ってメール送信するケースが根強く残っている。実際、「まずは動くものを作りたい」というフェーズでは、追加費用なしで始められるGmail SMTPは現実的な選択肢だ。

設定としては、Googleアカウントで2段階認証を有効にした上でアプリパスワードを発行し、smtp.gmail.com（ポート587、TLS）に接続する形が基本となる。Node.jsであればnodemailerを使えば数行で送信できる。

const nodemailer = require('nodemailer');

const transporter = nodemailer.createTransport({
  service: 'gmail',
  auth: {
    user: 'youraddress@gmail.com',
    pass: process.env.GMAIL_APP_PASSWORD, // アプリパスワード
  },
});

await transporter.sendMail({
  from: 'youraddress@gmail.com',
  to: 'user@example.com',
  subject: '注文確認',
  html: '<p>ご注文ありがとうございます。</p>',
});

ただし、Gmail SMTPには明確な限界がある。まず送信上限が1日あたり500通（Google Workspaceでは2,000通）と少ないため、ユーザーが増えた時点で破綻する。次に、Gmailの送信元アドレスが@gmail.comになるため、独自ドメインのブランディングとは合わない（Fromヘッダの書き換えは可能だが、受信側でGmail経由であることが見える）。さらに、大量送信するとGoogleからスパム判定を受けてアカウントが一時停止されるリスクもある。

もう1つ重要な変化として、Googleは2025年3月に基本認証（ユーザー名＋パスワードによるSMTP認証）を廃止した。現在はアプリパスワードまたはOAuth 2.0での認証が必須となっている。アプリパスワード自体もGoogleは推奨しておらず、将来的に廃止される可能性が示唆されている。つまり、Gmail SMTPは「いつ使えなくなってもおかしくない」暫定手段であると認識しておく必要がある。

結論としては、Gmail SMTPはプロトタイピングやテスト送信、個人プロジェクトの初期段階では十分に使えるが、本番サービスとして運用するものではない。ユーザーが増えてきた段階でResend（月3,000通無料）やAWS SES（従量課金で非常に安い）など、本格的なメール送信サービスへの移行を計画しておくべきだ。

レンタルサーバーのメール機能 — Xserver・さくらインターネットという選択肢

Xserverやさくらインターネットのレンタルサーバーを既に契約している場合、追加費用なしで独自ドメインのメール送受信が使える。「既にサーバー代を払っているのだから、メールもそこから送ればいいのでは？」と考えるのは自然な発想だ。

Xserverのメール送信上限は全プラン共通で1,500通/時間・15,000通/日と、レンタルサーバーとしてはかなり余裕がある。PHPのmail()関数やSMTP認証（ポート587）経由でアプリケーションから送信でき、SPF・DKIM・DMARCにも対応済みだ。小〜中規模のウェブサービスであれば数字上は十分に足りる。

さくらインターネットはXserverより送信制限が厳しく、スタンダード・プレミアムプランで概ね100通/15分程度（1分あたり約6.6通）とされている。DKIM・DMARCへの対応は2024年1月末に実装され、Gmailの送信者ガイドライン強化にも対応できるようになった。ただし対応がやや遅かった経緯があり、以前はGmail宛のメールが迷惑メール判定される問題が報告されていた。

レンタルサーバーのメール機能は、WordPressのお問い合わせフォーム通知や、1日数十〜数百通程度の自動返信メールには十分実用的だ。何より追加コストがゼロで、既にサーバーを使っているなら設定も最小限で済む。

ただし、ウェブサービスのトランザクションメール（ユーザー登録確認、パスワードリセット、決済通知など）を本格的に運用する場合は、いくつかの根本的な限界を理解しておく必要がある。

まず、共有IPのレピュテーション問題がある。IPアドレスとはインターネット上の住所のようなもので、メールを送信する際には必ずこの送信元IPアドレスが付与される。レピュテーションとは「信用度」のことで、GmailやOutlookなどの受信側サービスは、送信元のIPアドレスごとに「このIPから届くメールは信用できるか」をスコアとして記録している。

レンタルサーバーでは、1台のサーバーに何十人、何百人ものユーザーが同居しており、全員が同じIPアドレスを共有してメールを送信する。ここで問題になるのは、同居しているユーザーの中に1人でもスパム（迷惑メール）を大量送信する人がいると、そのIPアドレス全体の信用スコアが下がることだ。一度スコアが下がると、同じIPから送っている自分の正当なメールまで迷惑メールフォルダに振り分けられてしまう。自分は何も悪いことをしていないのに、同じサーバーの別ユーザーの行動によって巻き添えを受ける形になる。

SendGridやAWS SESのようなメール送信に特化したサービスでは、スパムを送るユーザーを素早く検知・排除して共有IPの信用スコアを維持する仕組みが整っている。一方、レンタルサーバーはウェブサイトのホスティングが本業であり、メール送信の信用管理にそこまでのリソースを割いていないため、この問題が起きやすい。

次に、バウンス処理やサプレッション管理の仕組みがない。宛先不明のアドレスに繰り返し送信すると送信元の評判が下がるが、これを自動で管理する機能はレンタルサーバーには搭載されていない。

さらに、配信状況の可視化ができない。開封率・クリック率・バウンス率のトラッキング機能は一切なく、メールが実際にユーザーの受信箱に届いたかどうかをサーバー側から確認する手段が限られる。

そしてサービスが成長して送信量が増えた場合、レンタルサーバーの送信上限にぶつかるスケーラビリティの壁もある。

まとめると、レンタルサーバーのメール機能は「既にあるものを活かす」という点でコスト効率が良く、小規模な用途には合理的な選択だ。しかし「確実に届かなければサービスが成り立たないメール」を扱うなら、最初からResendやAWS SESなどの専用サービスに乗せておく方が、後からの移行コストを考えると結果的に安上がりになる。

2025〜2026年のメール送信サービスのトレンド

この1〜2年で、メール送信サービスの業界にはいくつか顕著な動きが出ている。

まず、開発者体験（Developer Experience / DX）の重視が加速している。Resendのように、モダンなフレームワークとの親和性やAPIデザインのクリーンさで差別化するサービスが台頭しており、従来のSendGridやMailgunが「レガシー」と評される場面も増えてきた。

次に、SendGridの料金改定とフリープラン廃止が業界に波紋を広げている。2025年5月に無料プランが終了して60日トライアルのみになったことで、小規模プロジェクトの開発者がResendやPostmark、AWS SESへ流れる動きが見られる。

React Emailの浸透も見逃せない。Resendが主導するオープンソースプロジェクトで、HTMLのtableレイアウトに頼らずReactコンポーネントとしてメールを記述するアプローチが広まりつつある。これまでメール開発は「2010年のウェブ開発」と揶揄されるほど非効率だったが、React Emailはその状況を変えつつある。

さらに、AIエージェント向けのメールインフラという新しいカテゴリも登場している。AIエージェントがプログラマブルにメールの送受信を行うユースケースに特化したサービスが出始めており、この分野は今後拡大する可能性がある。

nodemailer + postfix + docker image

パッケージインストール

npm install nodemailer
npm install -D @types/nodemailer

docker-compose.yml

services:
  mysql:
    image: mysql:8.4.0
    container_name: mysql
    restart: always
    env_file:
      - ./db/.env
    ports:
      - "3306:3306"
    volumes:
      - mysql_data:/var/lib/mysql
      - ./initdb:/docker-entrypoint-initdb.d
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      interval: 10s
      timeout: 5s
      retries: 5

  mailserver:
    image: boky/postfix
    container_name: mailserver
    restart: always
    environment:
      - ALLOWED_SENDER_DOMAINS=localhost
    ports:
      - "1025:25"

  backend:
    build:
      context: ./backend
      dockerfile: Dockerfile
    container_name: backend
    command: npm run dev
    env_file:
      - ./backend/.env
    ports:
      - "8888:8888"
    volumes:
      - ./backend:/app
      - /app/node_modules
    depends_on:
      mysql:
        condition: service_healthy
      mailserver:
        condition: service_started

volumes:
  mysql_data:

Postfix自前運用の懸念点

メールの到達率を自分で管理する必要がある（SPF/DKIM/DMARC設定、IPレピュテーション管理）
Lightsailのような環境ではアウトバウンドのポート25がブロックされていることが多い
スパム判定されやすく、Gmail等に届かない問題と戦い続けることになる
Postfixの運用・監視・セキュリティ対策が継続的に発生する

Postfixのログから「Connection timed out」の原因を読み解く

Postfixでメール送信を構成したとき、ログに以下のようなエラーが記録されることがある。

postfix/smtp[1058]: ABC123DEF: to=<user@example.com>,
relay=none, delay=8893, delays=8743/0.21/150/0, dsn=4.4.1,
status=deferred (connect to mail-server.example.com[192.0.2.1]:25: Connection timed out)

一見すると情報量が多いが、各フィールドの意味がわかればログの読み方は難しくない。

Postfixの主要プロセスを把握する

ログを読む前に、Postfixが機能ごとにプロセスを分離していることを知っておく必要がある。メール送信に関わる主なプロセスは以下の通り。

smtpd — 外部やローカルのクライアントからSMTP接続を受け付けてメールを受け取る。末尾の d は daemon（待ち受ける側）を意味する
cleanup — 受け取ったメールのヘッダを整理・正規化する
qmgr — キュー（送信待ち行列）を管理し、送信プロセスにメールを渡す
smtp — キュー内のメールを外部のメールサーバへSMTPで送信するクライアント

ログの postfix/smtp と postfix/smtpd は名前が似ているが役割がまったく異なる。smtpd は受信、smtp は送信。ここを混同するとログの読み間違いにつながる。

ログの各フィールドを読む

先ほどのログを分解する。

postfix/smtp[1058]: ABC123DEF: to=<user@example.com>,
relay=none, delay=8893, delays=8743/0.21/150/0, dsn=4.4.1,
status=deferred (connect to mail-server.example.com[192.0.2.1]:25: Connection timed out)

postfix/smtp — 送信プロセスのログ。smtpd（受信）ではなくsmtp（送信）なので、このサーバから外部へ送ろうとした記録だとわかる
relay=none — メールを中継してくれるサーバが見つからなかった。どこにも届けられていない
delay=8893 — キューに入ってから8893秒（約2.5時間）経過。Postfixが何度もリトライしていることを示す
dsn=4.4.1 — DSN（Delivery Status Notification）コード。先頭の 4 は一時的な障害を意味する（5 なら永久失敗）
status=deferred — 送信に失敗したが、一時的な障害扱いのため後で再試行される。bounced なら再試行されず差し戻しになる
Connection timed out — 宛先サーバのポート25に接続を試みたが、応答が返ってこなかった

「Connection timed out」が意味すること

Connection timed out はTCPレベルで接続が確立できなかったことを示す。Postfix側の設定ミスではなく、ネットワーク経路上でポート25への通信が到達できていない。よくある原因は以下の通り。

クラウド事業者によるポート25の制限 — AWS EC2をはじめ多くのクラウドプロバイダは、スパム防止のためにアウトバウンドのポート25をデフォルトで制限している
セキュリティグループやファイアウォールの設定 — アウトバウンドルールでポート25が許可されていない
ネットワークACLやルーティングの問題 — VPCのルートテーブルやNATの設定が正しくない

原因の切り分けには、Postfixを介さずホストOSから直接接続を試すのが手っ取り早い。

timeout 5 bash -c 'echo QUIT | nc gmail-smtp-in.l.google.com 25' && echo OK || echo FAILED

これがタイムアウトするなら、Postfixやコンテナの問題ではなくインフラ側の遮断だと確定できる。

対策方針

ポート25がブロックされている環境では、Postfixから直接メールを送る構成は使えない。現実的な選択肢は2つある。

SMTPリレーサービスを利用する — Amazon SES、SendGrid、Mailgunなどのサービスをリレー先として設定する。これらはポート587（Submission）を使うため、ポート25の制限に引っかからない。Postfixの relayhost にリレー先を指定すれば、既存の構成をほぼ変えずに対応できる。SPFやDKIMの設定もサービス側で案内されるため、到達率の面でも有利になる
クラウド事業者にポート25の制限解除を申請する — AWSの場合はフォームから申請できるが、スパム対策の審査があるため承認までに時間がかかることが多い。送信元IPのレピュテーション管理やバウンス処理も自前で行う必要があるため、運用コストは高い

特別な理由がなければ、SMTPリレーサービスの導入が推奨される。