💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

プロローグ — 「メールは死んだはずなのに、なぜ毎年インフラは複雑になるのか」

毎年誰かが「メールは死んだ」と叫ぶ。Slack が社内コミュニケーションを奪い、WhatsApp と LINE と KakaoTalk が個人メッセージを奪い、Discord と Notion がコミュニティを奪った。しかし 2026 年現在、SaaS ビジネスの圧倒的多数は依然としてメールでサインアップ確認、決済レシート、パスワードリセット、マーケティングキャンペーン、通知を送っている。

それどころか、より複雑になった。2010 年代は SendGrid か Mailgun に SMTP をつなげば終わりだった。2026 年は次のような意思決定ツリーがある。

1. トランザクションか、マーケティングか、通知か — ツールが違う。

2. SPF・DKIM・DMARC・BIMI の設定とモニタリングは誰が担当するのか。

3. 送信ドメインをウォームアップするか、マネージド IP プールを借りるか。

4. Apple Mail Privacy Protection 以後、開封率追跡が壊れた。代わりにどの指標を使うか。

5. React Email でコンポーネントベースに組むか、MJML でマークアップで書くか、ビジュアルエディタ(Stripo・Beefree)を使うか。

6. 通知は Knock・Courier・Novu のようなオーケストレータに任せるか、自前で書くか。

本稿は 2026 年 5 月時点のメール基盤の全体地図を描く。Resend・Postmark・SendGrid・Mailgun・AWS SES に分かれたトランザクション、Loops・Customer.io・Mailchimp・Klaviyo・Kit・Beehiiv に分化したマーケティング、Knock・Courier・Novu の通知、React Email・MJML・Maizzle のビルダ、そして到達性・プライバシー・コンプライアンスまでをまとめて整理する。

1章 · トランザクション vs マーケティング vs 通知 — 3 領域を混ぜるな

メールを始めるチームが最初に犯すミスは「1 つのツールで全部送る」決定だ。トランザクション・マーケティング・通知は受信者の期待値も、送信ドメインの評判管理方法も異なる。

| カテゴリ | 例 | 特性 |

| --- | --- | --- |

| トランザクション | サインアップ確認・レシート・パスワードリセット・2FA コード | 1 対 1・即時送信・0 スパム許容度・高評判必須 |

| マーケティング(ブロードキャスト) | ニュースレター・プロモーション・キャンペーン | 1 対 N・予約送信・オプトイン必須・配信停止リンク義務 |

| 通知 | ダイジェスト・コメント通知・活動サマリ | 1 対 1 だが頻度が高い・チャネル選択権(メール・SMS・プッシュ) |

3 カテゴリを同じドメインの同じツールで送ると評判は急速に崩れる。マーケティングでスパム報告が集まると、レシートまでスパムフォルダに落ちる。運用チームは通常、送信サブドメインを分離する。

| 用途 | 推奨サブドメイン | 送信ツール例 |

| --- | --- | --- |

| トランザクション | tx.example.com、mail.example.com | Postmark、Resend、AWS SES |

| マーケティング | news.example.com、marketing.example.com | Loops、Mailchimp、Customer.io |

| 通知 | notify.example.com | Knock、Courier(裏は SES など) |

核となる原則は **評判の分離**。片方が壊れても、もう一方が安全でなければならない。

2章 · 到達性の基礎 — SPF · DKIM · DMARC · BIMI

メールがインボックスに届くか、スパムフォルダに落ちるかを決めるのは内容ではなく **認証体系** だ。2026 年現在、次の 4 つは選択肢ではなく必須である。

1. **SPF (Sender Policy Framework)** — ドメインの TXT レコードで「この IP から送られるメールだけが正当」と宣言。v=spf1 include:_spf.example.net ~all の形。

2. **DKIM (DomainKeys Identified Mail)** — メールヘッダに署名。受信者はドメインの公開鍵で検証。鍵長 2048 ビット推奨。

3. **DMARC (Domain-based Message Authentication, Reporting, and Conformance)** — SPF/DKIM 失敗時の方針(none / quarantine / reject)を宣言。レポートで偽装試行をモニタリング。

4. **BIMI (Brand Indicators for Message Identification)** — DMARC が reject かつ VMC(Verified Mark Certificate)を保有していれば、受信側 UI にブランドロゴが表示される。Gmail・Yahoo・Apple Mail がサポート。

2024 年 2 月、Gmail と Yahoo は「月 5,000 件以上の送信者は DMARC 必須」と方針を強化した。2026 年には事実上すべてのビジネス送信者が DMARC quarantine 以上を設定する必要がある。

; SPF

example.com. TXT "v=spf1 include:_spf.resend.com include:_spf.mailgun.org ~all"

; DKIM (Resend が提供するセレクタ)

resend._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIB..."

; DMARC

_dmarc.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100; aspf=s; adkim=s"

; BIMI (VMC 証明書を保有している場合)

default._bimi.example.com. TXT "v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/vmc.pem"

これに加えて **reverse DNS (PTR)** が正方向ドメインと一致しなければならず、**IP 評判(reputation)** が清潔である必要がある。自前 IP ではなくマネージド IP プールを借りる場合、プール内に誰が一緒にいるかが重要になる。

3章 · Resend — 2023 Y Combinator、開発者ファーストのトランザクション

Resend は 2023 年の Y Combinator W23 バッチで始まった。ワンライナーは「developer-first email API」で、API サーフェスが小さいことで急速にシェアを伸ばした。

主な特徴

- API サーフェスが小さい — POST /emails 1 つのエンドポイントから始められる。

- React Email との一級連携 — Resend が作ったオープンソース。JSX コンポーネントでメールを書き、そのまま送る。

- ドメイン認証フローが綺麗 — コンソールで SPF・DKIM・DMARC レコードを一度に提示。

- 価格 — 無料 100/日、Pro 20 USD/月で 50,000 件から。

- マルチリージョン(US・EU)でデータレジデンシのオプション。

弱点

- マーケティング(ブロードキャスト)機能は相対的に後追い。本格的なキャンペーンは Loops/Customer.io の組み合わせが強い。

- 非常に大量(月 1,000 万件以上)では AWS SES 直接運用に対するコスト優位が縮む。

// Resend SDK (Node.js)

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

await resend.emails.send({

from: 'YJ Blog <noreply@tx.example.com>',

to: ['user@example.com'],

subject: 'ご登録ありがとうございます',

react: WelcomeEmail({ name: 'Youngju' }),

})

4章 · Postmark — ActiveCampaign が買収、到達性の 1 位

Postmark は 2025 年 ActiveCampaign に買収されたがブランドは維持される。市場でのポジションは一貫していて、**「トランザクション専用、到達性の絶対 1 位」** である。

主な特徴

- マーケティング送信を方針として拒否。Stream を transactional / broadcast で明示分離。

- 平均インボックス到達時間が秒単位で安定 — レシート・コード送信に強い。

- **Postmark DMARC Digest** — DMARC レポートを可視化する無料サービス。ドメイン偽装モニタリングを簡単にオンにできる。

- テンプレートと変数置換が強力 — Mustache スタイル。

弱点

- 価格が高い — トランザクション 100K で約 50 USD/月。大量では SES との差が大きい。

- マーケティングキャンペーンには別ツールが必要。

curl -X POST "https://api.postmarkapp.com/email" \

-H "Accept: application/json" \

-H "Content-Type: application/json" \

-H "X-Postmark-Server-Token: YOUR_TOKEN" \

-d '{

"From": "noreply@tx.example.com",

"To": "user@example.com",

"Subject": "Welcome",

"HtmlBody": "<h1>Hello</h1>",

"MessageStream": "outbound"

5章 · SendGrid — Twilio 傘下、トランザクションとマーケティング両方

SendGrid は 2019 年に Twilio に買収されて以降、トランザクションとマーケティングの両方を持つ総合プラットフォームになった。シェアで見ると依然として市場 1 位。

主な特徴

- API と SMTP の両方をサポート — レガシー互換に強い。

- Marketing Campaigns モジュール — セグメンテーション・オートメーション・A/B テストが可能。

- Twilio SendGrid Email Validation API — 送信前の有効性検証。

- グローバルインフラ — 米国・欧州・日本リージョン。

- IP ウォームアップの自動化 — 新規 IP を数日かけて段階的に温める。

弱点

- コンソール UX は総合プラットフォームらしく複雑。

- 送信ポリシーが厳しく新規アカウントのコールドスタートが面倒。

- 価格 — 無料 100/日、以降 Essentials 19.95 USD/月から。

SendGrid Python SDK

from sendgrid import SendGridAPIClient

from sendgrid.helpers.mail import Mail

message = Mail(

from_email='noreply@tx.example.com',

to_emails='user@example.com',

subject='Welcome',

html_content='<h1>Hello</h1>')

sg = SendGridAPIClient(os.environ.get('SENDGRID_API_KEY'))

response = sg.send(message)

6章 · Mailgun — Sinch 傘下、開発者フレンドリな API

Mailgun は 2021 年に Sinch に合流し、グローバル通信グループの一員になった。ポジションは「SendGrid より軽く、API が綺麗な開発者ツール」。

主な特徴

- HTTP API と SMTP の両方。ルーティングルール(受信メールの処理)も強力。

- MJML2HTML コンパイラをオープンソースで維持(Mailgun が後援)。

- 到達性ツール — Inbox Placement Testing、Send Time Optimization。

- マルチリージョン(US・EU)でデータ主権オプション。

- 価格 — Foundation 35 USD/月で 50K 件から。

弱点

- UI は SendGrid より貧弱。コンソールよりも API で運用するチームに合う。

- マーケティングキャンペーンツールは SendGrid/Mailchimp に比べて弱い。

curl -s --user 'api:YOUR_API_KEY' \

https://api.mailgun.net/v3/mail.example.com/messages \

-F from='Y. Kim <noreply@mail.example.com>' \

-F to=user@example.com \

-F subject='Welcome' \

-F html='<h1>Hello</h1>'

7章 · AWS SES — 大規模では最安

Amazon Simple Email Service は送信価格が 1,000 件あたり 0.10 USD で、大規模では比較対象がない。ただし評判管理・バウンス/苦情処理・UI などの付属品はすべて自前で組む必要がある。

主な特徴

- 価格 — 送信 1,000 件あたり 0.10 USD。EC2 から送信する場合は月 62,000 件まで無料の旧ポリシーが残るかは要確認。

- SNS/SQS でバウンス・苦情・送信イベントをほぼリアルタイムで受信。

- Configuration Set で送信ドメイン・イベントを分離。

- マルチリージョン — us-east-1、eu-west-1、ap-northeast-1 など。

- Dedicated IP、IP Pool、BYOIP(自前 IP 持ち込み)対応。

弱点

- 新規アカウントはサンドボックスモード(検証済み受信者のみ送信可能)で開始。本番昇格は別申請。

- 評判・バウンス・UI はすべて自前 — SaaS に比べた運用負担が小さくない。

- コンソールは AWS 平均の密度を持つ。

大量送信するチームの定番パターンは **「AWS SES + 自前キュー(SQS) + 自前ワーカー + Resend/Postmark を部分的バックアップ」**。

boto3 ses send_email

ses = boto3.client('ses', region_name='ap-northeast-1')

ses.send_email(

Source='noreply@tx.example.com',

Destination={'ToAddresses': ['user@example.com']},

Message={

'Subject': {'Data': 'Welcome'},

'Body': {'Html': {'Data': '<h1>Hello</h1>'}},

ConfigurationSetName='tx-config',

)

8章 · セルフホスティング — Postal · Listmonk · Plunk · Maileroo

自前インフラに行く選択肢も生きている。マネージドが使えない規制環境や、コストが大きいときに検討する。

| ツール | 特徴 | 適合 |

| --- | --- | --- |

| Postal | Ruby で書かれた自前 SMTP ゲートウェイ | 自前インフラ運用チーム |

| Listmonk | Go で書かれた単一バイナリのニュースレター | ニュースレター・マーケティング |

| Plunk | オープンソース SaaS 代替 | トランザクション + キャンペーン |

| Maileroo | マネージド + 自前のハイブリッド | 大量送信 |

| Maileon | 欧州データ主権優先 | EU 規制環境 |

| Notification Hub | 通知チャネル管理の自前ホスティング | コミュニティ・OSS |

セルフホスティングの本質的限界は **IP 評判**。新規 IP はビッグテックのメールサービスから自動で疑われる。自前で始めるとしても、外部のトランザクションサービスで評判が積まれた IP を借りるのが一般的だ。

9章 · マーケティング — Mailchimp · Loops · Customer.io

マーケティング(ブロードキャスト)市場はトランザクションとは完全に別のツール群が占める。

| ツール | ポジション | 強み | 価格(目安) |

| --- | --- | --- | --- |

2026 年の潮流は 2 つ。1 つは **「コードでキャンペーンを定義」** — Loops・Customer.io のように API とトリガで自動化をコードベースに結びつけること。もう 1 つは **「クリエイター経済」** — Beehiiv・Substack・Kit が取った領域。

// Loops API — イベントトリガキャンペーン

await fetch('https://app.loops.so/api/v1/events/send', {

method: 'POST',

headers: {

'Authorization': 'Bearer ' + process.env.LOOPS_KEY,

'Content-Type': 'application/json',

body: JSON.stringify({

email: 'user@example.com',

eventName: 'signup_completed',

eventProperties: { plan: 'pro' },

}),

})

10章 · 通知オーケストレーション — Knock · Courier · Novu

通知(notification)は単なるメールとは違う。ユーザごとのチャネル選択(メール・SMS・プッシュ・インアプリ)、頻度調整、ダイジェスト、タイムゾーン処理が必要だ。これを自前で組み始めると別のマイクロサービスになる。

| ツール | ポジション | 特徴 |

| --- | --- | --- |

| Knock | 通知オーケストレーション SaaS | ワークフロー・ダイジェスト・チャネル統合 |

| Courier | マルチチャネル通知 | チャネルルーティング・テンプレート統合 |

| Novu | オープンソース通知インフラ | セルフホスティング可能 |

| One Signal | プッシュ中心 + メール | モバイルプッシュが強い |

典型的な利用パターンは「バックエンドでイベント送信 → Knock ワークフロー → ユーザ選好に応じてメールは Resend、プッシュは FCM、SMS は Twilio へ分岐」。通知頻度コントロールとダイジェスト(複数イベントを 1 通にまとめる)が中核価値。

// Knock ワークフロートリガ

await knock.workflows.trigger('new-comment', {

recipients: ['user_123'],

data: {

comment: 'Great post!',

author: 'Alice',

post_title: 'Email Infra 2026',

})

11章 · メールビルダ — React Email · MJML · Maizzle

メール HTML は 2026 年も 1996 年の Outlook 互換性の荷物をそのまま背負う。この荷物を抽象化するビルダ 3 家族が定着した。

React Email (Resend 後援)

- React コンポーネントでメールを書く。

- @react-email/components パッケージに Button、Hr、Img、Container など。

- Resend SDK と一級統合 — `react: <Welcome />` オプションでそのまま送る。

- プレビューサーバ内蔵 — pnpm dev でローカルプレビュー。

MJML (Mailjet 後援)

- XML のようなマークアップ → 互換 HTML にコンパイル。

- レスポンシブが既定 — Outlook 2007/2010 まで自動対応。

- ビジュアルエディタ(Stripo・Topol)が内部で MJML を使うことも多い。

Maizzle

- Tailwind CSS でメールをスタイリング。

- ビルドタイムにインライン CSS に変換。

- コンポーネントスロットと環境別ビルドオプション。

ビジュアルエディタ

- Stripo、Beefree、Topol、Postcards — ドラッグアンドドロップで作り、HTML/MJML にエクスポート。

// React Email コンポーネント例

export function WelcomeEmail({ name }: { name: string }) {

return (

)

}

12章 · レンダリング検証 — Outlook の悪夢と Litmus · Email on Acid

メールクライアントの互換性の変動幅はウェブブラウザよりはるかに大きい。Gmail、Apple Mail、Outlook(特に Windows Outlook 2007/2010/2013/2016/2019)、Yahoo Mail、ProtonMail、モバイル Gmail、モバイル Outlook が同じ HTML をすべて違うように描画する。

| ツール | 特徴 | 価格 |

| --- | --- | --- |

| Litmus | 50+ クライアントのスクリーンショット | Plus 79 USD/月から |

| Email on Acid | 90+ クライアント + アクセシビリティ検査 | Basic 86 USD/月から |

| Hsoob Email Preview | コスパ代替 | 無料開始 |

| Mailtrap | 開発者向け SMTP サンドボックス + プレビュー | 無料開始 |

Outlook(Windows デスクトップ)は Word のレンダリングエンジンを使うため、CSS Flexbox・Grid・position などが効かない。メール HTML が表(table)ベースで組まれる理由がこれだ。MJML と React Email はこの表ベース構造を自動生成する。

13章 · DMARC モニタリング — Postmark Digest · DMARCian · EasyDMARC

DMARC 方針を quarantine または reject にすると、違反試行のレポートが毎日届く。これを人が XML で読むのはダメだ。可視化ツールを使う。

| ツール | 特徴 |

| --- | --- |

| Postmark DMARC Digest | 無料、週次サマリメール |

| DMARCian | 最古の SaaS、無料ティアあり |

| ValiMail | エンタープライズ、MTA-STS・BIMI も |

| EasyDMARC | コスパ、複数ドメイン管理 |

| OnDMARC (Red Sift) | 英国のセキュリティ会社、オートメーション |

中核となる運用原則は段階的強化 — 最初は p=none で 30 日間レポートだけ収集し、ドメイン違反がなければ p=quarantine に上げ、安定したら p=reject で締める。

14章 · Apple Mail Privacy Protection — 開封率の死

2021 年に Apple Mail Privacy Protection が登場して以降、追跡ピクセルは事実上無力化された。Apple Mail ユーザがメールを受け取った瞬間、バックグラウンドで自動プリフェッチされるため、開封率が 100% に見えるか、意味を失う。2026 年現在、Apple Mail のシェアはグローバル約 50%。

代替指標は次の通り。

| 廃止される指標 | 代替指標 |

| --- | --- |

| Open rate | Click-through rate、Reply rate |

| Time of open | Time of click |

| Device(open 基準) | Device(click 基準) |

| ピクセル基準 A/B | クリック・コンバージョン基準 A/B |

マーケティングツールもオプションを追加した — 「開封率の補正(Apple Mail を除外して計算)」。Customer.io・Loops・Mailchimp すべてサポートする。

15章 · 規制 — CAN-SPAM · GDPR · CASL · K-PIPA · APPI

メールはグローバル送信が基本なので、各国の規制を同時に満たす必要がある。

| 規制 | 地域 | 中核義務 |

| --- | --- | --- |

| CAN-SPAM | 米国 | 配信停止リンク・送信者住所・偽ヘッダ禁止 |

| GDPR | EU | 明示的オプトイン・同意記録・削除権 |

| CASL | カナダ | 明示的オプトイン・配信停止 10 日内処理 |

| K-PIPA | 韓国 | 広告性情報は「広告」表記、夜間(21-08)送信同意は別 |

| APPI | 日本 | オプトイン原則・訂正・利用停止対応 |

| LGPD | ブラジル | GDPR と類似 |

最も厳しい K-PIPA を基準に運用すれば、他の地域もほぼ通る。広告性情報の件名には「(広告)」表記、本文に送信者情報・受信拒否方法・夜間送信同意の可否を明記する。

16章 · ウォームアップ — 新規ドメインと IP の最初の 30 日

新ドメインや新 IP で送信を始めると、ビッグテックのメールサービスは自動的に疑う。最初の数日は送信量を段階的に増やすウォームアップが必要だ。

ウォームアップツール:

- Mailwarm — 自動送信・自動返信で評判を積む。

- Lemwarm — Lemlist 系。

- Mailflow — コスパオプション。

- SendGrid・Mailgun の IP ウォームアップ自動化。

典型的 30 日スケジュール:

- Day 1-3: 50 通/日。

- Day 4-7: 200 通/日。

- Day 8-14: 1,000 通/日。

- Day 15-30: 5,000-50,000 通/日。

ウォームアップ中は最もエンゲージメントの高いユーザ(直近 30 日のクリッカ)から送る。コールドリストでウォームアップすると評判はさらに壊れる。

17章 · 韓国市場 — KakaoTalk Biz Message · Naver Works

韓国ではメールだけでは足りない。通知は KakaoTalk、認証は SMS、マーケティングはメール + アラーム톡 の組み合わせが標準だ。

| チャネル | ツール | 特性 |

| --- | --- | --- |

| KakaoTalk アラーム톡 | Kakao Biz Message | 情報性メッセージ、無料/低価 |

| KakaoTalk 友達톡 | Kakao Biz Message | 広告性、オプトイン必須 |

| Naver Works | LINE WORKS Korea | 企業コラボ + メール |

| Daum カフェニュースレター | Kakao 傘下 | コミュニティニュースレター |

| Mailply、Stibee | 韓国ニュースレター SaaS | 韓国語 UI、K-PIPA 対応 |

アラーム톡は認証コード、決済通知のような情報性に非常に強い。ただし事前登録テンプレートのみ可能で、広告性と分類されると友達톡に降格される。

18章 · 日本市場 — SendGrid Japan · さくら · Mailgun JP

日本ではメール自体のシェアが韓国よりはるかに高く維持される。取引先コミュニケーション、社内通達、BtoB 営業はメール中心だ。

| ツール | 特性 |

| --- | --- |

| SendGrid Japan | 日本リージョン、日本語サポート、JCB 決済 |

| さくらインターネット | 日本国産クラウド + メールホスティング |

| さくらのメールボックス | ドメインメールボックス |

| Mailgun Japan | 日本拠点 |

| Cuenote FC | 日本のマーケティングメール SaaS |

| Benchmark Email Japan | 日本のマーケティング |

日本市場の特殊性: 携帯キャリア(docomo、KDDI、SoftBank)が運営するメールサービスが依然として生きており、独自のスパムフィルタを運用している。日本ドメイン送信時は docomo・au・SoftBank への到達率を別途モニタリングするのが標準。

19章 · コールドメール — Apollo · Instantly · Smartlead · lemlist

セールスのコールドメールは送信戦略がトランザクション・マーケティングと違う。非常に少量を、非常にパーソナライズして送る。ツールも分かれる。

| ツール | 特性 |

| --- | --- |

| Apollo.io | DB + シーケンス自動化 |

| Instantly | 複数 inbox ローテーション |

| Smartlead | ウォームアップ + シーケンス |

| lemlist | 画像パーソナライズ |

| Outreach.io | エンタープライズセールスシーケンス |

| Salesloft | エンタープライズセールス |

コールドメールにはオプトインがないため、GDPR/CASL/K-PIPA とは正面衝突する。EU/韓国/カナダ送信でコールドを使うのはリスクが高く、ドメイン自体の評判も急速に削れる。だからコールド用送信ドメインはメインドメインと必ず分離する。

20章 · アーキテクチャパターン — API → Queue → Worker → Gateway

大量送信システムの標準パターンは次のとおり。

[アプリケーション API]

| send_email(to, template, vars)

[メッセージキュー (SQS / Kafka / RabbitMQ)]

| 背圧調整・リトライ・優先度

[メールワーカープール]

| レンダリング・変数置換・送信制限の適用

[ゲートウェイ (SES / Resend / SendGrid)]

+-> 成功 -> [イベントログ / 分析]

+-> バウンス -> [SNS / Webhook -> 処理]

\-> 苦情 -> [ブロックリスト追加 / DLQ]

設計原則:

1. **キュー分離** — トランザクション・マーケティング・通知のキューを分ける。片方が詰まっても他方は流れる。

2. **ブロックリスト** — バウンス・苦情ユーザは自動除外。同じアドレスへ再送すると評判が壊れる。

3. **DLQ(Dead Letter Queue)** — 送信失敗メッセージは別キューへ送って分析する。

4. **レート制限** — ゲートウェイ別・ドメイン別の時間あたり送信上限をワーカーで適用。

5. **マルチゲートウェイのフェイルオーバ** — 主ゲートウェイが落ちたら副に切り替え。Resend ↔ SES のような組み合わせ。

6. **イベントログ** — すべての送信・開封・クリック・バウンスイベントは分析 DB に積む。

21章 · 私たちのチームは何を選ぶべきか

ワークロード別の推奨をもう一度圧縮する。

| 状況 | 推奨 |

| --- | --- |

| MVP のトランザクション | Resend か Postmark — どちらも素早く始められる |

| 月 100K 以下のトランザクション | Postmark(高い到達率)か Resend(React Email 統合) |

| 月 1,000 万件以上送信 | AWS SES + 自前キュー + 自前評判管理 |

| B2C マーケティング | Mailchimp か Klaviyo(E コマース)、Loops(SaaS) |

| 行動トリガキャンペーン | Customer.io |

| クリエイターニュースレター | Beehiiv か Substack |

| 通知マルチチャネル | Knock か Courier |

| オープンソース通知 | Novu |

| 韓国市場 | メール(Resend/SES) + KakaoTalk アラーム톡 + Stibee |

| 日本市場 | SendGrid Japan + さくら + キャリア別モニタリング |

結局、ツールを 1 つに統一しようとする試みはほぼすべて失敗する。トランザクション・マーケティング・通知を分離し、それぞれに合うツールを選んで組み合わせる — これが 2026 年の正解だ。

参考 / References

- Resend Docs — https://resend.com/docs

- Postmark Docs — https://postmarkapp.com/developer

- SendGrid Docs — https://docs.sendgrid.com/

- Mailgun Docs — https://documentation.mailgun.com/

- AWS SES Developer Guide — https://docs.aws.amazon.com/ses/

- Loops Docs — https://loops.so/docs

- Customer.io Docs — https://customer.io/docs/

- Knock Docs — https://docs.knock.app/

- Courier Docs — https://www.courier.com/docs/

- Novu Docs — https://docs.novu.co/

- React Email — https://react.email/

- MJML — https://mjml.io/

- Maizzle — https://maizzle.com/

- DMARC.org — https://dmarc.org/

- BIMI Group — https://bimigroup.org/

- Postmark DMARC Digest — https://dmarc.postmarkapp.com/

- DMARCian — https://dmarcian.com/

- EasyDMARC — https://easydmarc.com/

- Apple Mail Privacy Protection — https://support.apple.com/en-us/HT212614

- Gmail Sender Guidelines 2024 — https://support.google.com/mail/answer/81126

- Litmus — https://www.litmus.com/

- Email on Acid — https://www.emailonacid.com/

- KISA K-PIPA Guidelines — https://www.kisa.or.kr/

- Beehiiv — https://www.beehiiv.com/

- Substack — https://substack.com/

- Kit (旧 ConvertKit) — https://kit.com/

- Klaviyo — https://www.klaviyo.com/