LabHub

ブログ

2026年メールインフラ — Resend・Postmark・Loops・SES・SendGrid・Mailgun 徹底比較

2026-05-14 · 36 分で読めます · #email#resend#postmark#loops#ses#sendgrid#mailgun#deliverability#saas-infra#japanese

한국어English日本語

プロローグ — メールは死んでいない、ただ難しくなっただけ

2026年もメールはあらゆるSaaSの1番手チャネルだ。パスワードリセットのリンク、決済領収書、会議招待、オンボーディングシーケンス、休眠ユーザー再エンゲージ — プッシュ・SMS・アプリ内通知がどれだけ増えても、この5つはメールで届く。問題は送信ではない。受信トレイに到達させること だ。

2024年2月、GoogleとYahooは送信者認証の要件を引き上げた。1日5,000通以上を送るドメインはSPF・DKIM・DMARCの3つを通過しなければならず、マーケティングメールには1クリック配信停止(List-Unsubscribe-Post ヘッダー)が必須、迷惑メール報告率(complaint rate)が0.30%を超えるとドメイン全体が隔離(quarantine)または拒否される。Microsoft 365も2025年に同じ基準に追いつき、2026年現在は小規模ISPもほぼ同じポリシーを採っている。つまり DKIMなしでメールを送る時代は終わった。

その背景の上で、メールインフラ市場は二つに分かれた。

  1. トランザクション優先 — Resend・Postmark・AWS SES。1通ずつトリガーされる領収書・通知が主役。
  2. メールが製品そのもの — Loops・Customer.io・Brevo。シーケンス・セグメント・自動化が1級市民。

両者はしばしば重なる。どんなSaaSも結局は両方必要になる。本稿はその選択を扱う。どの段階でどのツールを使うのが正しいか、購読者1万人で月いくらかかるか、日本のISPまでどう満足させるか — 2026年5月時点の実状で整理する。

1章・メールインフラの責任分岐線

1.1 ESPがやること、やらないこと

ESP(Email Service Provider)はSMTPサーバー1行で終わるものではない。すべてのESPは次を行う。

ESPが やらないこと:

要点はこうだ。ESPは道具を貸すが、結果を保証しない。 一度の誤ったキャンペーン(例:コールドメーリングリスト購入)でドメイン評判が崩壊すれば、どのESPに移っても同じく迷惑メールフォルダに行く。

1.2 SPF・DKIM・DMARC — 2026年の最小要件

3つを一行ずつ。

2024年のGoogle・Yahooガイドライン以降、事実上 3つすべて通過しなければ 受信トレイに入らない。Resend・Postmark・SESのドメイン認証画面が似てきた理由だ。DNSにTXTを3 ~ 4個入れて1時間待てば終わる。

; example.com SPF
example.com.    IN  TXT  "v=spf1 include:_spf.resend.com -all"

; resend._domainkey.example.com DKIM
resend._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."

; _dmarc.example.com DMARC
_dmarc.example.com. IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100"

DMARCポリシーは最初は p=none で開始してレポートのみ受け取り、1 ~ 2週間モニタリングしてから p=quarantine、最後に p=reject と段階的に上げる。一気に reject にすると間違ったSPF1行で正常なメールまで全部拒否される。

1.3 IP評判 vs ドメイン評判

2010年代まではIP評判がほぼすべてだった。だから専用IPが高くても買った。2026年は ドメイン評判 が支配する。Gmail・Outlookは学習モデルでドメイン+送信者ペアを別々にスコア化する。

これは二つの意味を持つ。

2章・Resend — 開発者ファーストESPの新基準

2.1 ポジショニング

Resendは2023年に登場し、2024 ~ 2025年の間にインディーハッカー・Next.js陣営で急速に定着した。React Email ライブラリと組んで「JSXでメールを書く」が中核メッセージ。Vercel・Stripe出身のチームが作り、シリーズB(2024年)まで完了した。

価格(2026年5月時点):

// Resend — 最小トランザクション送信
import { Resend } from 'resend'

const resend = new Resend(process.env.RESEND_API_KEY)

await resend.emails.send({
  from: 'Acme <hello@mail.acme.com>',
  to: ['user@example.com'],
  subject: 'ようこそ',
  html: '<strong>ご登録ありがとうございます。</strong>',
})

2.2 強み

2.3 弱み

2.4 いつ使うか

3章・Postmark (ActiveCampaign) — 到達率の王

3.1 ポジショニング

Postmarkは2010年Wildbitが作ったESP。2022年にActiveCampaignに買収された。トランザクション到達率(deliverability) が信条だ。平均到達時間を公開(「median 9.8s」)し、分析ツールも到達率中心。マーケティングメールは同じインフラから送らない — これを逆に強みとして売っている。

価格(2026年5月時点):

// Postmark — Server Token一本
import { ServerClient } from 'postmark'

const client = new ServerClient(process.env.POSTMARK_TOKEN!)

await client.sendEmail({
  From: 'hello@mail.acme.com',
  To: 'user@example.com',
  Subject: 'パスワードリセット',
  HtmlBody: '<a href="https://acme.com/reset?token=xxx">リセット</a>',
  MessageStream: 'outbound', // 'broadcast' と区別必須
})

3.2 強み

3.3 弱み

3.4 いつ使うか

4章・Loops — メールが製品

4.1 ポジショニング

Loopsは2022年登場、2024年シリーズA。「インディーSaaSのマーケ+トランザクション統合ESP」 という狭く強いポジションを掴んだ。オーディエンス管理、シーケンス(loops)、トランザクションを一画面に。UI自体がSaaSらしく洗練され、Slack・Notion・Linearに近いインディー陣営の顧客向けメールでよく見かける。

価格(2026年5月時点):

// Loops — トランザクションイベントトリガー
import { LoopsClient } from 'loops'

const loops = new LoopsClient(process.env.LOOPS_API_KEY!)

await loops.sendTransactionalEmail({
  transactionalId: 'cltt6abcd1234', // Loopsダッシュボードで作成したID
  email: 'user@example.com',
  dataVariables: {
    firstName: 'ヨンジュ',
    resetUrl: 'https://acme.com/reset?token=xxx',
  },
})

4.2 強み

4.3 弱み

4.4 いつ使うか

5章・AWS SES — 最安、しかし責任は全部あなたのもの

5.1 ポジショニング

SES(Simple Email Service)は2011年リリースのAWSメールサービス。価格は事実上業界最安。ただし到達率・ウォームアップ・UI・自動化機能はすべて利用者が作る。DIYメールの土台 だ。

価格(2026年5月時点):

// AWS SES v2 — Node SDK
import { SESv2Client, SendEmailCommand } from '@aws-sdk/client-sesv2'

const ses = new SESv2Client({ region: 'us-east-1' })

await ses.send(new SendEmailCommand({
  FromEmailAddress: 'hello@mail.acme.com',
  Destination: { ToAddresses: ['user@example.com'] },
  Content: {
    Simple: {
      Subject: { Data: 'ようこそ' },
      Body: { Html: { Data: '<strong>登録完了</strong>' } },
    },
  },
}))

5.2 強み

5.3 弱み

5.4 いつ使うか

6章・SendGrid (Twilio) — エンタープライズのデフォルト

6.1 ポジショニング

SendGridは2009年登場、2019年にTwilioに買収された。トランザクション+マーケティングの巨人。大企業の第一選択肢としてよく入り、API・連携・SDKが圧倒的に広い。ただしUI・UXは旧時代の痕跡を多く残し、価格は交渉領域が大きい。

価格(2026年5月時点):

// SendGrid — v3 API
import sgMail from '@sendgrid/mail'

sgMail.setApiKey(process.env.SENDGRID_API_KEY!)

await sgMail.send({
  to: 'user@example.com',
  from: 'hello@mail.acme.com',
  subject: '決済領収書',
  html: '<p>ご利用ありがとうございます。</p>',
})

6.2 強み

6.3 弱み

6.4 いつ使うか

7章・Mailgun (Sinch) — 旧開発者フレンドリー、2026年の位置

7.1 ポジショニング

Mailgunは2010年登場、2017年Rackspace買収、2021年にSinchが親会社を買収。2010年代初頭の開発者フレンドリーESPの元祖。APIがクリーンで、EUデータレジデンシー(EU region)オプションが早くから存在した。

価格(2026年5月時点):

// Mailgun — REST API
import formData from 'form-data'
import Mailgun from 'mailgun.js'

const mg = new Mailgun(formData).client({
  username: 'api',
  key: process.env.MAILGUN_API_KEY!,
})

await mg.messages.create('mail.acme.com', {
  from: 'hello@mail.acme.com',
  to: ['user@example.com'],
  subject: 'ようこそ',
  html: '<p>こんにちは</p>',
})

7.2 強み

7.3 弱み

7.4 いつ使うか

8章・その他 — Brevo・Mailtrap・Customer.io・Plunk

8.1 Brevo (旧 Sendinblue)

パリ拠点。マーケティング+トランザクション+SMS+CRMを束ねたオールインワン。欧州インディー陣営で人気。価格が手頃で無料枠も寛大(1日300通)。ただしマーケに重心があり、純粋なトランザクション到達率はPostmark・Resendよりわずかに低いという評。

8.2 Mailtrap — 開発環境テスト

ステージング・ローカルでメール送信を模倣するツール。実送信なしにSMTPを受け取り、偽の受信トレイに保存 → 開発者が本文・ヘッダー・HTMLを確認。CIで回帰テストとしてよく使われる。2024 ~ 2025年に実送信(Mailtrap Email Sending)も出したが、主用途は依然としてテスト環境。

// Mailtrap — Nodemailer SMTPテスト受信トレイ
import nodemailer from 'nodemailer'

const transporter = nodemailer.createTransport({
  host: 'sandbox.smtp.mailtrap.io',
  port: 2525,
  auth: { user: process.env.MAILTRAP_USER, pass: process.env.MAILTRAP_PASS },
})

await transporter.sendMail({
  from: 'hello@mail.acme.com',
  to: 'qa@example.com',
  subject: 'staging環境テスト',
  html: '<p>Hello, Mailtrap</p>',
})

8.3 Customer.io — 本格マーケティング自動化

イベントベースマーケ自動化の最強候補。シーケンスビルダーが非常に深い(if/else、A/B、分岐後合流、タイムゾーン送信)。価格は急速に上がる — 通常 $50k MRR 以上から導入。Liquidテンプレート・Webhook・アプリ内メッセージまで対応。

8.4 Plunk — オープンソースセルフホスト

plunk.com。2024年登場のオープンソースESP。SESの上で動くホスト版もあり、GitHubリポジトリを取得してself-hostも可能。インディー陣営の「セルフホスト選択肢」。到達率は結局背後にあるSESに依存する。価格に敏感・データ主権要求が強いケースに合う。

9章・10,000購読者の費用マトリクス

仮定:月10,000コンタクト、月送信100,000通(コンタクトあたり平均10通/月)、トランザクション50% + マーケ50%。

サービス月額トランザクションマーケ自動化到達率の評判メモ
AWS SES$10強いなし利用者責任DIY、自社運用
Resend Pro/Scale$90強い中良React Email統合
Postmark Premium$115最強別途分離最強トランザクション専用
Mailgun Scale$90強い弱い中EUデータレジデンシー
SendGrid Pro$89.95強い強い変動的Twilio統合
Loops Business$249強い強い良インディーSaaS統合
Brevo Business$65 ~中強い良マーケ重視
Customer.io Premium$200 ~強い最強良別途トランザクションESPを推奨
Plunk + SES$10 ~ $30SES依存単純SES依存セルフホスト

この表は二つの結論を示す。

  1. 純価格だけならSESが圧倒的。運用人件費を加えると10万通水準では差は小さいが、100万通段階では明確に開く。
  2. マーケ自動化が必要ならLoops・Customer.io がこの価格帯で最も深い。ResendがBroadcastsで踏み込んだが、分岐の深さはまだ届かない。

9.1 10万購読者段階での再計算

仮定:月10万コンタクト、月送信100万通。

サービス月額(目安)運用人件総費用(人件含む)
AWS SES$100約0.3 FTE人件 + $100
Resend$900 ~ $1,5000$900 ~ $1,500
Postmark$1,200 ~0$1,200 ~
SendGrid Pro/Premier$500 ~ $2,000(交渉)0 ~ 0.2 FTE交渉
Customer.io$2,000 ~ $5,0000$2,000 ~ $5,000
SES + 自社ツール$100 + 人件1 FTE本格運用

100万通段階ではSES + 自社インフラが意味を持ち始めるが、そのインフラを組む時間がソロ/小規模チームにあるかは別の話。

10章・React Email・MJML・Maizzle — HTMLメールの現実

10.1 メールHTMLが酷い理由

メールクライアントは1999年で止まったHTMLレンダリングエンジンを動かす。Outlookは今もWordエンジン(2007 ~ )を使う。Gmailは <style> タグの一部しか受け付けず、一部のメディアクエリは無視する。iOS MailはCSS Gridを知らない。現代CSSはほとんど使えない。

対策は二つ。

これを手で書くのは罰だ。だからツールが生まれた。

10.2 React Email

// React Email — コンポーネントでメール
import { Body, Button, Container, Head, Html, Text } from '@react-email/components'

export function WelcomeEmail({ name }: { name: string }) {
  return (
    <Html>
      <Head />
      <Body style={{ fontFamily: 'sans-serif' }}>
        <Container>
          <Text>{name}さん、こんにちは。</Text>
          <Button href="https://acme.com/welcome">はじめる</Button>
        </Container>
      </Body>
    </Html>
  )
}

ビルド段階でインラインスタイルが入ったHTMLに変換される。Resendが同チームから出たため統合が1級。Postmark・SESにもそのまま送れる。

10.3 MJML

Mailjetが作ったマークアップ言語。独自タグ(mj-section、mj-column)を使い、ビルド時に標準テーブルベースHTMLにコンパイル。2015年代の標準として定着し、今もPHP・Ruby陣営でよく使われる。

<mjml>
  <mj-body>
    <mj-section>
      <mj-column>
        <mj-text>ようこそ。</mj-text>
        <mj-button href="https://acme.com/welcome">スタート</mj-button>
      </mj-column>
    </mj-section>
  </mj-body>
</mjml>

10.4 Maizzle

Tailwindベースのメールフレームワーク。通常のHTML + Tailwindクラスで書き、ビルド時にPostCSSがインラインスタイルに変換する。デザイナーに最も自然な選択。React Emailと違いSSR/JSXではなく静的ビルド。CMS運用キャンペーンによく入る。

10.5 どれを使うか

3つとも出力は同じインラインテーブルHTML。ツール選択はチームのスタックに合わせる。

11章・Webhook・バウンス・苦情 — 入ってくるイベントの技術

11.1 すべてのESPは同じイベントを送る

名前は少しずつ違っても核心イベントは同じだ。

11.2 冪等なWebhookハンドラ

// Next.js Route Handler — Resend webhookを冪等に処理
import { headers } from 'next/headers'
import { db } from '@/lib/db'
import { Webhook } from 'svix' // Resendはsvix署名を使う

export async function POST(req: Request) {
  const body = await req.text()
  const h = await headers()

  const wh = new Webhook(process.env.RESEND_WEBHOOK_SECRET!)
  let event
  try {
    event = wh.verify(body, {
      'svix-id': h.get('svix-id')!,
      'svix-timestamp': h.get('svix-timestamp')!,
      'svix-signature': h.get('svix-signature')!,
    }) as any
  } catch {
    return new Response('Bad signature', { status: 400 })
  }

  // 冪等性:イベントIDをPKとして保存
  const stored = await db.emailEvent.create({
    data: { id: event.data.email_id + ':' + event.type, payload: body },
  }).catch(() => null)

  if (!stored) return new Response('Already processed', { status: 200 })

  switch (event.type) {
    case 'email.bounced':
      await suppressUser(event.data.to[0], 'hard_bounce')
      break
    case 'email.complained':
      await suppressUser(event.data.to[0], 'complaint')
      break
  }

  return new Response('ok', { status: 200 })
}

要点:バウンス・苦情は即座に抑制リストに入れる。もう一度送ること自体がドメイン評判の損傷だ。

11.3 1クリック配信停止 (RFC 8058)

2024年のGoogle・Yahooガイドライン以降、すべてのマーケメールに次のヘッダーが必須。

List-Unsubscribe: <https://acme.com/unsub?t=xxx>, <mailto:unsub@mail.acme.com?subject=unsub>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

受信者がメールクライアントの「配信停止」を押すとESPがそのURLに POST する。ユーザーはページを開かずに一度で抜ける。Resend・Postmark・SendGrid・SESすべて送信時に自動でヘッダーを入れるオプションを提供する。

12章・日本のISP到達率 — Yahoo!Japan・Gmail日本・docomoなど

12.1 日本が難しい理由

日本のユーザーの受信ドメインはGmail、Yahoo!Japan(@yahoo.co.jp)、docomo(@docomo.ne.jp)、au(@ezweb.ne.jp、@au.com)、SoftBank(@softbank.ne.jp)、Outlook、企業のプライベートドメインが混在する。グローバルESPはGmail/Outlookを基準に評判を管理するが、キャリアメール(docomo・au・SoftBank)は別世界だ。

特に:

12.2 日本のISP到達率を上げる実戦

12.3 日本のユーザー比率に応じた決定

13章・マーケ vs トランザクション — メッセージストリーム分離

13.1 二つのストリームは別IPで送れ

マーケメールとトランザクションメールは評判が違う。マーケメールは本質的にスパム報告率が高く、トランザクションはほぼゼロ。同じIPで混ぜるとマーケがトランザクションの評判を蝕む。

13.2 サブドメイン戦略

acme.com              ← メインドメイン(メール送信なし)
mail.acme.com         ← トランザクション(領収書・認証)
news.acme.com         ← マーケ(ニュースレター・キャンペーン)
notifications.acme.com ← システム通知(Slackスタイル)

それぞれにSPF・DKIM・DMARCを別途設定し、ESPを使い分けることもできる。例:トランザクションはPostmark、マーケはLoops、システム通知はSES。

14章・運用アンチパターン

よく見る失敗。

15章・意思決定ツリー

質問1: トランザクションが主か、マーケが主か?
  ├─ トランザクション優先(認証・領収書・通知)
  │   ├─ Next.js・React本陣 → Resend
  │   ├─ 到達率最優先(金融・ヘルス) → Postmark
  │   ├─ AWS本陣 + 自社運用人員 → SES
  │   └─ レガシー・SAP・エンタープライズ → SendGrid
  │
  └─ マーケ + トランザクション統合
      ├─ インディーSaaS(月 $1k ~ $50k MRR) → Loops
      ├─ 本格マーケ自動化 → Customer.io + トランザクションは別途Postmark/Resend
      └─ EUデータレジデンシー + マーケ + CRM → Brevo

質問2: 月送信量は?
  ├─ < 50,000通 → どれでもOK。価格差は小さい。
  ├─ 50k ~ 500k → ESP価格比較が意味を持つ。
  └─ > 1M → SES + 自社インフラ、またはPremier交渉。

質問3: 日本のユーザー比率は?
  ├─ < 10% → グローバルESP単独。
  ├─ 10 ~ 30% → グローバルESP + ドメイン評判モニタリング。
  └─ > 30% → グローバル + 国内ESP併用を検討。

エピローグ — メールは一度壊すと6か月を失う

メールインフラの怖いところは、一度のミスが6か月を奪うことだ。ドメイン評判が落ちれば新しいドメインを買うか、3 ~ 6か月の回復期間を耐えなければならない。だから 最初の送信前にSPF・DKIM・DMARCをすべて設定し、マーケとトランザクションを分離し、バウンス・苦情のWebhookを冪等に受け取っておくこと が、インディー開発者が最初の1週間で終えるべき作業だ。

2026年のメール市場は8年前と違う。ResendがReact Emailで開発者の心を掴み、Postmarkは到達率信頼の標準として定着した。Loopsがインディー SaaSのマーケ+トランザクション統合の扉を開き、SESは価格で依然として圧倒的。Google・Yahooの2024年ガイドラインは市場を揺らしたが、全員が同じ方向に流れた — SPF・DKIM・DMARCなしでメールを送るな。

最初の1週間チェックリスト

アンチパターン(再整理)

次回予告

次回は メールが届いた後 について書く。受信トレイに到達したメールがどうクリックされ返信され売上につながるか — 開封率・クリック率・返信率・配信停止率・売上貢献をどう測るか、Apple Mail Privacy Protection以降信頼できる指標は何か、A/Bテストはどう設計するか — メール分析の実戦運用を一気に整理する。

参考 / References

コメント

まだコメントはありません。

ログインするとコメントできます