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

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

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なしでメールを送る時代は終わった。

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

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

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

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

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

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

SMTP/REST API を公開し、メール送信リクエストを受け付ける。
共有または専用IP から送信する。
SPF・DKIM・DMARCのアライメント を支援する(自分のドメインを送信者として揃える設定)。
バウンス・苦情・配信・開封・クリック イベントをWebhookやダッシュボードで返す。
抑制リスト(Suppression list) を管理し、同じユーザーへの再送を防ぐ。

ESPが やらないこと:

あなたのドメイン自体の評判(domain reputation)を作ってはくれない。これは累積した送信履歴から育つ。
メール内容の品質を保証しない。スパムキーワード・HTML比率・画像サイズは送信者の責任。
ユーザー同意(consent)・CAN-SPAM・GDPR遵守を代行しない。

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

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

3つを一行ずつ。

SPF (Sender Policy Framework): ドメインのTXTレコードに「このドメインを送信者として使えるIP/ホストは次です」と宣言。ESPのSMTPサーバーを include: で追加。
DKIM (DomainKeys Identified Mail): 送信メールの本文にドメインの秘密鍵で署名を入れる。受信者はDNSの公開鍵で検証する。
DMARC: SPF・DKIMが通過しなかったメールをどう扱うかのポリシー(quarantine/reject)をドメイン所有者が明示する。

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は学習モデルでドメイン+送信者ペアを別々にスコア化する。

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

専用IPの価値が下がった。月5,000 ~ 50,000通の送信なら共有IPで十分。それ以上、または時間に非常に敏感なトランザクション(2FAコード)比率が大きければ専用IPを検討する。
ドメインを差し替えると評判は0からスタート。acme.com から acme.io に移れば新たに育てなければならない。通常 mail.example.com のようなサブドメインを別途用意して評判を分離する。

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

2.1 ポジショニング

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

価格(2026年5月時点):

Free: 月3,000通、1日100通。
Pro: 月 $20 で50,000通、1日10,000通。
Scale: 月 $90 で100,000通、追加は1,000通あたり約 $0.90。
Enterprise: 個別交渉。

// 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 強み

React Email との統合が1級。JSXでメールコンポーネントを書き、そのままインポートして本文に入れる。
開発者体験が圧倒的。ドメイン認証画面、ログ、Webhook、バッチ送信 — すべて整っている。
Batching API で一度に100通までまとめて送信。
Webhookイベント — email.sent、email.delivered、email.bounced、email.complained、email.opened、email.clicked。
Audiences・Broadcasts(2024年 ~ ) — 軽量マーケティング機能が追加され、Loopsの領域に一部踏み込んだ。

2.3 弱み

本格的なマーケティング自動化は弱い。シーケンス・分岐・セグメントはLoops・Customer.ioに比べてシンプル。
高ボリューム送信(月100万通以上)ではSES + 自社インフラのほうが安い。
デリバラビリティ資料は頻繁に公開されるが、本格的な専用IP・ウォームアップでは依然としてPostmarkが一枚上という評価。

2.4 いつ使うか

Next.js・Reactベースのトランザクションメール。
インディーハッカー・1人開発者。
「メールデザインをコードで管理したい」が最優先のチーム。

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

3.1 ポジショニング

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

価格(2026年5月時点):

Free trial: 100通。
Starter: 月 $15 で10,000通。
Premium: 月 $115 で100,000通。上位はパッケージ単位。
Marketing(Streams): 別途 — Postmarkはトランザクションとマーケティングのストリームを強制的に分離する。

// 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 強み

トランザクション到達率は業界最高水準。平均9 ~ 12秒で受信トレイに届くというのが保証付きの売り文句で、おおむね守られる。
Message Streams が強制 — トランザクションとブロードキャストを同じドメインから送ってもIP・評判は分離。
分析ツールが到達率中心。Spam complaints、bounce reasons、開封・クリックなど、すべてが素早く見える。
DMARC Digests が無料 — ドメインのDMARCレポート分析をGUIで見られる。

3.3 弱み

価格が高い。100kで $115 はSESの $10 と比較にならない。
マーケティング自動化は弱い。トランザクション集中。シーケンス・セグメントは親会社ActiveCampaignで。
グローバルIPプールが限定的。日本・韓国のISP向けには評判ウォームアップが長くかかるという声がある。

3.4 いつ使うか

金融・ヘルス・B2B SaaS — 1回の送信が遅れたり消えたりするとクレームになる場合。
売上が到達率に直結するドメイン(認証コード、決済領収書、法的通知)。
「マーケメールはまったく別のツールで出す」と決めたチーム。

4章・Loops — メールが製品

4.1 ポジショニング

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

価格(2026年5月時点):

Free: 1,000コンタクト・月2,000通。
Pro: 月 $49 から — 5,000コンタクト・25,000通。
Business: 月 $249 から — 25,000コンタクト・100,000通。
追加コンタクト・送信量は段階別に増える。

// 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 強み

トランザクション+マーケを1つのツールで 見る。コンタクト1人のトランザクションイベントとキャンペーン送信が同じタイムラインに積もる。
Loops(ループ) — 分岐・遅延・条件を組み込んだシーケンスビルダー。シンプルなケースに十分強力。
イベントベース — userSignedUp、subscriptionPaid などのイベントから自動シーケンス開始。
インディー陣営との親和性 — Stripe・PostHog・Segment統合がきれい。

4.3 弱み

本格マーケツールとしては単純。多段分岐、A/Bテスト、ユーザースコアリングはCustomer.io・HubSpotと比べると薄い。
高ボリュームでは効率が悪い。10万コンタクト超で価格が急速に上がる。
ドメイン認証・到達率統計はPostmark・Resendより情報が少ない。

4.4 いつ使うか

月 $1k ~ $50k MRR のインディーSaaS — マーケ自動化ツールを別に置くには小さく、トランザクション一辺倒で済ますにはキャンペーンが必要な段階。
「マーケ担当を置いていないソロ創業者が、すべてのメールを一画面で管理する」。

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

5.1 ポジショニング

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

価格(2026年5月時点):

送信: 1,000通あたり $0.10(EC2から送ろうが外部から送ろうが同じ)。
受信: 1,000通あたり $0.10 + チャンクあたり $0.09。
専用IP: 月 $24.95/IP。
VDM(Virtual Deliverability Manager): 送信量に比例した追加費用。

// 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 強み

価格が圧倒的に安い。10万通で $10。Postmarkの同量で約 1/10。
AWSインフラ内 で動作 — EventBridge、SNS、Lambdaなどと自然に組み合わさる。
サンドボックス解除後は無制限 — 送信量の上限が事実上ない(APIクォータは別)。
VDM — 2023年導入の到達率管理ダッシュボード。評判モニタリング・送信推奨など。

5.3 弱み

サンドボックスモードがデフォルト。解除にはAWSサポートチケットでユースケースを説明 — 通常24 ~ 72時間。
UIが貧弱。テンプレートエディタ、シーケンス、セグメントなどはない。
到達率は利用者の役目。SPF・DKIM・DMARC、ウォームアップ、コンテンツ品質 — すべて自前。
苦情・バウンス処理 も自前 — SNSで受け取って自社の抑制リストを運用。

5.4 いつ使うか

月100万通以上の送信 — 価格差が明確に意味を持ち始める。
すでにAWS本陣を使っているチーム。
社内メールインフラチームがあり、到達率・ウォームアップを自前で運用できる場合。

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

6.1 ポジショニング

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

価格(2026年5月時点):

Free: 1日100通(月総量制限あり)。
Essentials: 月 $19.95 から — 月50,000通。
Pro: 月 $89.95 から — 月100,000通・専用IPオプション。
Premier: 交渉 — 数百万通以上。

// 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 強み

どこでも動く。SDKが30以上の言語。レガシーシステム・エンタープライズSIに入る比率が最も高い。
Twilio統合 — SMS・WhatsApp・Voiceを1アカウントで管理。
マーケキャンペーンツール — シーケンス・セグメント・A/Bテストが深い。
専用IP・ウォームアップ自動化 — Pro以上でIPプール管理が強力。

6.3 弱み

UIが古い。メニュー構造に13年分の継ぎ目が残る。
共有IP評判の変動性が大きい。大口顧客中心に管理され、小口は影響を受けやすい。
顧客サポートが価格帯で分かれる。Pro以下は応答が遅い。

6.4 いつ使うか

大企業・レガシーシステム — SAP・Oracleのような本陣からメールを送る必要がある場合。
すでにTwilio SMS/Voiceを使っており請求・管理を統合したい場合。
マーケ+トランザクションが同じツールで回る必要のあるグローバルチーム。

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

7.1 ポジショニング

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

価格(2026年5月時点):

Foundation: 月 $15 で月10,000通。
Growth: 月 $35 で50,000通。
Scale: 月 $90 で100,000通。
Enterprise: 交渉。

// 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 強み

EU region — api.eu.mailgun.net — データがEU内で処理される。GDPR・法要件が強いEU顧客に意味がある。
イベントログ7日保存がデフォルト、30日保存がオプション。デバッグに強い。
検証API(Email Validation) — 送信前にアドレスの有効性を直接コール。

7.3 弱み

2020年代に入って停滞した印象。新興ESPに比べUI・DXが見劣りする。
共有IP評判 が変動的という声が多い。
価格が中間 — Resend・SendGridほど安くもなく、Postmarkほどの到達率保証もない。

7.4 いつ使うか

EUデータレジデンシーが法的に必須の場合。
すでにMailgunに顧客データが蓄積されたレガシー運用。
新規導入ならResend・Postmark・SESのいずれかが先。

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 ~ $30`	SES依存	単純	SES依存	セルフホスト

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

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

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

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

サービス	月額(目安)	運用人件	総費用(人件含む)
AWS SES	`$100`	約0.3 FTE	人件 + `$100`
Resend	`$900 ~ $1,500`	0	`$900 ~ $1,500`
Postmark	`$1,200 ~`	0	`$1,200 ~`
SendGrid Pro/Premier	`$500 ~ $2,000`(交渉)	0 ~ 0.2 FTE	交渉
Customer.io	`$2,000 ~ $5,000`	0	`$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はほとんど使えない。

対策は二つ。

テーブルベースのレイアウト — 2003年風の <table><tr><td> ネスト。
インラインスタイル — <style> タグが剥がされても生き残るように。

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

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 どれを使うか

Next.js・React本陣: React Email。コンポーネント再利用、TypeScript補完。
多言語キャンペーン・デザイナー協業: Maizzle。Tailwindとの親和性。
PHP・Rubyレガシー: MJML。

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

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

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

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

delivered — SMTP 250応答。
bounce.hard — 永続的失敗(存在しないアドレス)。即座に抑制リスト登録。
bounce.soft — 一時的失敗(メールボックス満杯など)。再試行後、通常7日以内にhardへ昇格。
complaint / spam_report — ユーザーが「スパム報告」を押した。即座にそのアドレスへのマーケ送信を停止。
opened — トラッキングピクセル読み込み(ノイズ)。Apple Mail Privacy Protectionで2022年以降ほぼ信用できない。
clicked — リンククリック(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)は別世界だ。

特に:

キャリアメールは独自フィルタリングを持ち、海外IPからの送信に厳しい。
件名・本文の文字エンコーディング(UTF-8 vs ISO-2022-JP)に敏感な古いクライアントが残存。
モバイル受信トレイの容量制限で大きなHTMLメールが切り捨てられたり拒否されたりする。
絵文字・特殊記号で誤判定されるケースが2026年現在も残る。

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

DKIM・SPF・DMARCの3つすべてを通過 — グローバル基準と同じ。
From ドメインが日本語本文と整合する ようにする — noreply@mail.gmail-fake.tk のような怪しいドメインは即遮断。
日本のユーザー比率30%以上なら専用IP または別IPプールを検討。
キャリアメールのホワイトリスト登録 — 各キャリアの送信元登録ページを経由すれば一部のケースで助けになる。
初回送信時のウォームアップ — 日本のユーザー比率が高いキャンペーンは小さなバッチ(1日100通)で開始し、徐々に増やす。
HTML比率の最適化 — テキストパート同梱、画像は外部ホスト + 代替テキスト必須。

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

5%以下: グローバルESP単独で十分。Resend・Postmarkそのままで。
10 ~ 30%: グローバルESPにドメイン評判モニタリングを追加。Yahoo!Japan・docomo・auの受信を毎週サンプルでチェック。
30%以上: 日本のISP向け送信経路を検討 — 国内ESP(Cuenote、Customers Mail Cloud、配配メールなど)を併用。グローバル到達率は別途管理。

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

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

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

Postmark: 強制分離 — MessageStream: 'outbound' vs 'broadcast'。同じドメインでもIPが異なる。
SendGrid: IP Pools で分離。Pro以上で推奨。
Resend: ドメインまたはサブドメインを分離(mail.acme.com トランザクション、news.acme.com マーケ)。
SES: Configuration Set + Dedicated IP Poolで分離。

13.2 サブドメイン戦略

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

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

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

よく見る失敗。

コールドメーリングリスト購入後、初日に1万通一斉送信 — ドメイン評判が即座に崩壊。回復に通常3 ~ 6か月。
noreply@ 送信者 + 返信を読まない — ユーザーの返信が消える。CAN-SPAM準拠にも悪い。support@ で受けるか自動応答を置く。
DMARCを初日から p=reject — 間違ったSPF1行が正常メールを全部殺す。p=none → quarantine → reject の段階を踏む。
バウンスを無視して送信継続 — ハードバウンスが1%を超えるとISPがドメイン自体を遮断。
1クリック配信停止を入れない — 2024年からマーケメールに必須。入れないとGmailが迷惑メールフォルダへ。
トラッキングピクセル・短縮リンクに依存 — Apple Mail Privacy Protectionで opened イベントは2022年からほぼ信用できない。クリック率・実際の応答で測る。
メール送信を同期HTTPレスポンス内で実行 — 送信遅延がそのままユーザー応答遅延に。キュー(BullMQ・SQS)の後ろで非同期に。

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週間チェックリスト

1日目:送信サブドメインを決める。mail.acme.com(トランザクション)・news.acme.com(マーケ)。
1日目:ESPの第一選択(ResendまたはPostmark)。
2日目:SPF・DKIM TXTレコード3本を入力。DNS伝播待ち。
3日目:DMARC p=none + レポートメールアドレス設定。
4日目:バウンス・苦情Webhookハンドラを冪等に実装(event.id PK)。
5日目:初のトランザクションメール送信。Gmail・Outlook・Yahoo!Japan・docomoの4つの受信トレイで確認。
7日目:List-Unsubscribeヘッダー + 1クリック配信停止ページ。
14日目:DMARCレポートを確認後 p=quarantine へ。
30日目:送信量が1日5,000通に近づいたら専用IPまたはIPプール分離を検討。

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

コールドリストを買って初日にドメイン評判を崩す。
マーケとトランザクションを同じIPで混ぜて認証メールまで迷惑メールフォルダへ。
noreply@ 送信 + 返信を読まない + 1クリック配信停止なし。
バウンス処理を無視して1%を超え遮断される。
DMARCを初日に p=reject で正常メールまで拒否。
日本のユーザー比率が30%なのにグローバルESPだけ使い、Yahoo!Japan・docomoの到達率を測らない。

次回予告

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

参考 / References

Google Sender Guidelines (2024) — https://support.google.com/mail/answer/81126
Yahoo Sender Best Practices — https://senders.yahooinc.com/best-practices/
Microsoft 365 Email Authentication Requirements — https://techcommunity.microsoft.com/category/microsoft365
RFC 8058 — One-Click List-Unsubscribe — https://datatracker.ietf.org/doc/html/rfc8058
DMARC.org — https://dmarc.org/
MXToolbox — https://mxtoolbox.com/
Resend — https://resend.com/
Resend Pricing — https://resend.com/pricing
Resend Docs — https://resend.com/docs
React Email — https://react.email/
Postmark — https://postmarkapp.com/
Postmark Pricing — https://postmarkapp.com/pricing
Postmark Message Streams — https://postmarkapp.com/blog/message-streams
Postmark DMARC Digests — https://dmarcdigests.com/
ActiveCampaign — https://www.activecampaign.com/
Loops — https://loops.so/
Loops Pricing — https://loops.so/pricing
AWS SES — https://aws.amazon.com/ses/
AWS SES Pricing — https://aws.amazon.com/ses/pricing/
AWS SES Virtual Deliverability Manager — https://docs.aws.amazon.com/ses/latest/dg/vdm.html
SendGrid — https://sendgrid.com/
Twilio SendGrid Pricing — https://sendgrid.com/en-us/pricing
Mailgun — https://www.mailgun.com/
Mailgun Pricing — https://www.mailgun.com/pricing
Sinch Mailgun — https://www.sinch.com/
Brevo — https://www.brevo.com/
Mailtrap — https://mailtrap.io/
Customer.io — https://customer.io/
Plunk — https://www.useplunk.com/
MJML — https://mjml.io/
Maizzle — https://maizzle.com/
Cuenote (日本のESP) — https://www.cuenote.jp/
Customers Mail Cloud (日本のESP) — https://smtps.jp/
配配メール (日本のESP) — https://www.hai2mail.jp/
Apple Mail Privacy Protection — https://support.apple.com/guide/iphone/iph2c9f7bd6f/ios
Yahoo!Japan 送信ガイドライン — https://mail.yahoo.co.jp/
docomo メール送信ガイド — https://www.docomo.ne.jp/mydocomo/help/spmode/