Resend 本番実装ガイド：ドメイン認証から冪等な送信・Webhook運用・到達率まで

「送信APIが200を返した」は「メールが届いた」ではありません。200が保証するのはResend がリクエストを受理したことだけで、そこから先には受信側MTAの判定、SPF/DKIMの検証、迷惑メールフォルダ、恒久バウンス、苦情による抑制リスト入りが待っています。逆に、200が返らなかったときに何も設計していなければ、その1通は永久に失われます——ユーザーには「送信に失敗しました」とだけ表示され、あなたは誰が何を送ろうとしたのかすら知りません。

本番のメールが満たすべき条件は3つです。届く（ドメイン認証と到達率）、追える（Webhookと構造化ログ）、二重に送らない（冪等キー）。この3つはバラバラの小技ではなく、1本の設計として通ります。

私はこのポートフォリオサイト自体を Resend で本番運用しています。問い合わせフォーム、資料請求（リードマグネット）、7通構成のメール講座（予約送信）、Stripe 決済後の納品メール——いずれも実際に稼働している経路です。そしてその過程で、Resend のドメイン認証レコードを apex（ルートドメイン）に誤配置し、/api/contact が502を返し続ける実障害を出しました。DNS の修正に加えて、送信者フォールバック・指数バックオフのリトライ・冪等キーを入れて根治しています。この記事は、その設計をそのまま地図にしたものです。

各テーマの深掘りは個別記事に分けました（本稿がクラスタの入口＝ピラーです）。コードはこのリポジトリが本番で使っている resend@6.4.1 の型定義に一致させています。

まず2026年の Resend に知識を更新する

2024〜2025年の記事や、その時期までの知識で書かれたAI生成コードには、いま実行すると壊れる内容が混ざっています。最初にここを直します。

数値はすべて 2026年8月6日時点の公式ページの記載です。仕様も価格も更新されるため、本番採用時は公式の該当ページで最新値を確認してください。

補足として、npm 上の resend は2026年8月6日時点で 6.18.1 が最新であり、そこでは suppressions や automations も SDK のリソースとして生えています。本記事が基準にしている 6.4.1 にはこの2つが無いので、その環境から抑制リストAPIを叩くなら resend.post() / resend.get() の汎用メソッドを使うか、SDK を上げてください。ここは「バージョンによって触り方が変わる」ことを正直に押さえておく価値があります。

全体アーキテクチャ：どこで何が壊れるか

メール配信の障害切り分けが難しいのは、壊れうる場所が5つあるのに、アプリから見えるのは最初の1つだけだからです。まず地図を頭に入れてください。

[あなたのアプリ]
    │  ① POST https://api.resend.com/emails
    │     Authorization: Bearer re_xxx  /  User-Agent: 必須  /  Idempotency-Key: 任意
    ▼
[Resend API]  ── 認証 → バリデーション → 冪等キー照合 → キュー投入 → 200 { id }
    │  ② SMTP 送出（SPF/DKIM 署名済みの封筒として送出）
    ▼
[受信側 MTA（Gmail / Outlook / 企業のメールサーバ）]
    │  ③ 受理 / 一時拒否（遅延） / 恒久拒否（バウンス） / 迷惑メール判定
    ▼
[受信箱 or 迷惑メールフォルダ or バウンス or 苦情（スパム報告）]
    │  ④ バウンス・苦情のフィードバック
    ▼
[Resend]  ── 抑制リスト（Suppressions）へ自動登録し、以後の送信をスキップ
    │  ⑤ Webhook POST（署名付き・at-least-once・順序保証なし）
    ▼
[あなたのアプリ /api/resend-webhook]  ── 生ボディで署名検証 → 200 を返す

各地点の壊れ方と、その症状は次のとおりです。

③はAPIの戻り値では絶対に検知できません。 だから⑤の Webhook が「あれば便利な機能」ではなく必須の可観測性になります。ここが、単発の送信スクリプトと本番システムの分かれ目です。

5分で送る：最小実装

1. APIキーを作る

ダッシュボード、API、CLI、MCP サーバのいずれからも作成できます。作成時に選ぶのは権限（full_access または sending_access）で、sending_access なら送信先ドメインをさらに絞り込めます。送信しかしないサービスに full_access を渡さないのが原則です。キー名は最大50文字、そして値は作成時に一度しか表示されません。

2. resend.dev の制約を理解する

検証済みドメインを持たない状態でも、共有送信元 onboarding@resend.dev を使って送信できます。ただしこれはテスト専用で、Resend アカウントに紐づく自分のメールアドレス宛にしか届きません。それ以外に送ると403で、こういう本文が返ります。

You can only send testing emails to your own email address (your-email-address@domain.com).
To send emails to other recipients, please verify a domain at resend.com/domains, and change
the `from` address to an email using this domain.

なお Resend にはサンドボックスも本番承認プロセスもありません。無料アカウントでもサインアップ直後から本番送信できます（AWS SES との明確な違いです）。

3. 最小コード

npm install resend

import { Resend } from "resend";

// 引数を省略すると process.env.RESEND_API_KEY を自動で読む。
// ただしキーが無いと「コンストラクタが throw する」ので、
// 本番コードではモジュールスコープで生成しないこと（後述）。
const resend = new Resend(process.env.RESEND_API_KEY);

const { data, error } = await resend.emails.send({
  from: "Acme <onboarding@resend.dev>",
  to: ["delivered@resend.dev"],
  subject: "hello world",
  html: "<p>it works!</p>",
});

// SDK は API エラーで throw しない。必ず error 側を分岐する。
if (error) {
  console.error(error.name, error.statusCode, error.message);
} else {
  console.log(data?.id);
}

テストで実在しないアドレスを使うとバウンス率を自分で悪化させます。Resend が用意している専用アドレスを使ってください：delivered@resend.dev（配信成功）、bounced@resend.dev（バウンス）、complained@resend.dev（苦情）、suppressed@resend.dev（抑制）。

送信本文は html / text / react のうち最低1つが必須です（型で強制されます）。text を省略すると HTML から自動生成され、空文字を渡すとその自動生成をオプトアウトできます。

本番までの7つの関門

ここからが本題です。「動いた」から「本番で任せられる」までに越える関門を7つに分けました。各関門の実装詳細は個別記事に委ねます。

関門①：ドメイン認証と到達率

独自ドメインの検証は避けて通れません。そして最も多い失敗は、レコードの置き場所を間違えることです。Resend が生成する SPF 関連レコード（feedback-smtp.<region>.amazonses.com の MX と v=spf1 include:amazonses.com ~all の TXT）は apex ではなく send サブドメインに置きます。DKIM の TXT は resend._domainkey、DMARC の TXT は _dmarc——この非対称性が事故のもとです。公式のトラブルシュートでも「レコードが正しい場所（ルートドメインではなく send サブドメイン）にあるか」が確認項目の2番目に挙がっています。

DNS プロバイダの入力欄には相対名（send.example.com ではなく send）を貼ります。また、MX の値の末尾にドメインを勝手に足すプロバイダがあり、feedback-smtp.eu-west-1.amazonses.com.example.com になって検証が失敗します。その場合は値の末尾にピリオドを付けて FQDN であることを明示します。

私が起こした障害はまさにこれで、DKIM・SPF・MX・DMARC の4件すべてを apex に置いていました。症状は「フォーム送信が毎回502」。ドメインが検証されていないので送信が403で拒否され、リトライも無かったため問い合わせがすべて消えていました。

なお Resend は 1024bit の DKIM 鍵で署名し、2048bit をサポートしません（RFC 8301 が検証側の最小サポート長として1024bitを定めていることを根拠に、方針として公開されています）。セキュリティ要件で2048bitを求められている場合は、事前に確認が必要です。

アカウント全体の閾値も押さえてください。バウンス率4%未満、苦情率0.08%未満——これを超えると送信が一時停止されることがあります。

DNSレコードの完全な一覧、DMARC の p=none → quarantine → reject の進め方、トラッキングサブドメインの扱いは Resend ドメイン認証・到達率ガイド で詳説します。

関門②：型安全な送信経路

Resend API はブラウザから呼べません。 api.resend.com は Access-Control-Allow-Origin を返さないので、クライアントJSからの呼び出しは必ずCORSで失敗します。これはバグではなくガードレールです——もし成功していたら、あなたのAPIキーは全世界に公開されていたことになります。したがってキーは RESEND_API_KEY に置き、NEXT_PUBLIC_ を付けない（付けた瞬間クライアントバンドルに埋め込まれます）。

Next.js App Router では Route Handler にサーバー側の送信を閉じ込めます。実装上のポイントは3つ。

// app/api/contact/route.ts（このサイトの本番コードの抜粋）
export const dynamic = "force-dynamic";

let resendClient: Resend | null = null;

// ① 遅延初期化。モジュールスコープで new Resend(...) すると、
//    キー未設定時にコンストラクタが throw して「ビルド／レンダリングごと」落ちる。
function getResend(): Resend {
  if (!resendClient) {
    const apiKey = process.env.RESEND_API_KEY;
    if (!apiKey) throw new Error("RESEND_API_KEY is not configured");
    resendClient = new Resend(apiKey);
  }
  return resendClient;
}

② SDK のオプションは camelCase（replyTo / scheduledAt / topicId）です。REST は snake_case ですが、SDK 内部で変換されます。ホワイトリストに無いキーは黙って捨てられるので、reply_to と書くと型エラーにならないケースでも実際には送られません。

③ template と html / text / react は型レベルで排他です。テンプレート送信時のみ from と subject が任意になります。

そして例外が飛ぶ経路は2つだけ、という点も重要です。ひとつは上記のコンストラクタ。もうひとつは react: オプションを使ったときに @react-email/render（v5以降はオプショナルな peer 依存）が入っていないケースで、これは { error } ではなく素の Error が飛びます。公式の Next.js サンプルが try/catch を持っているのはこのためです。

Zod による入力検証、レート制限、スパムゲート、構造化ログまで含めた完成形は Next.js App Router × Resend 実装ガイド にまとめました。レート制限そのものの設計は Next.js サーバーレスのレート制限、フォーム側は React Hook Form と Server Actions を参照してください。

関門③：冪等性とリトライ

リトライしうる送信には必ず冪等キーを付けます。 Resend は POST /emails と POST /emails/batch で Idempotency-Key をサポートし、同じキーの再送は24時間以内なら実際には送らずに同じレスポンスを返します。キーは1〜256文字。推奨形式は <イベント種別>/<エンティティID>（例：welcome-user/123456789）です。

const { data, error } = await resend.emails.send(
  {
    from: "Acme <notifications@mail.example.com>",
    to: [order.email],
    subject: "ご注文ありがとうございます",
    html,
  },
  // 第2引数。ペイロード内のカスタムヘッダでは重複排除されない。
  // 決済イベントIDのような「決定的な値」から作ること。
  { idempotencyKey: `order-receipt/${order.id}` },
);

冪等キーを入れたら、次はリトライの判断基準です。ここでHTTPステータスではなくエラー名で分岐するのが要点になります。理由は単純で、同じ409に正反対の意味が2つあるからです。

invalid_idempotent_request が出たときは、ペイロードに Date.now() や Math.random() が混ざっていないかを疑ってください。「同じキーなのに中身が違う」のは、ほぼ常にアプリ側の非決定性です。

このサイトでは、この分類表をそのまま純粋関数に落としています。

// lib/email-delivery.ts（抜粋）— 表に無い名前は HTTP ステータスで判定にフォールバックし、
// ステータスが無い（fetch が例外を投げた等＝そもそも届いていない）ときだけ retryable に倒す
const RESEND_ERROR_KINDS: Readonly<Record<string, DeliveryErrorKind>> = Object.freeze({
  rate_limit_exceeded: "retryable",
  application_error: "retryable",
  internal_server_error: "retryable",
  concurrent_idempotent_requests: "retryable",
  invalid_from_address: "sender_rejected",
  validation_error: "sender_rejected",
});

sender_rejected という3つ目の分類があるのがポイントです。「同じものを再試行する」「違うものを再試行する」「諦める」は本質的に別の行動で、真ん中を潰すとリードが消えます。送信者が拒否されたときだけ一度だけ既知の有効な送信元へ切り替える——これが私の障害を「フォーム全滅」から「ログに警告が出るだけ」に変えた設計です。

補足として、公式のエラー一覧と SDK の定数で invalid_from_address のステータスが食い違っています（ドキュメントは422、SDK の定数は403）。どちらが正しいと断定はできませんが、名前で分類してステータスは補助情報にする設計にしておけば、この種の揺れに巻き込まれません。

なお冪等性そのものの効き目については、決済基盤の案件で本番の二重課金0件を維持できた実績があります。メールでも考え方は同じで、リトライの安全性は「送る側が決定的なキーを持てるか」に尽きます。テスト可能なリトライ関数の書き方、タイムアウト設計、バックオフの検証方法は Resend の冪等性・リトライ・エラー設計 に分けました。決済側の冪等性は Stripe 本番実装ガイド が対応します。

関門④：テンプレート

本文をコードに直書きしていると、文言修正のたびにデプロイが必要になります。Resend の Templates はダッシュボードまたはAPIで管理し、公開（publish）済みのテンプレートだけが送信に使えます（作成直後は下書き）。

// 作成と公開をチェーンで一度に行える（create() は PromiseLike で .publish() を持つ）
await resend.templates.create({ /* … */ }).publish();

送信時は template.id（IDまたはエイリアス）と variables を渡します。制約は明確です：1テンプレートあたり変数は最大50個（作成・更新のAPIリファレンスと「Working with Variables」ページの記載。ダッシュボードの Templates introduction ページだけが今も「20個」と書いていて公式内で食い違うので、API側の50を基準にしてください）、変数キーは ASCII 英数字とアンダースコアのみで最大50文字、値は文字列なら2,000文字まで。FIRST_NAME / LAST_NAME / EMAIL / UNSUBSCRIBE_URL は予約語で使えません。テンプレートが使う変数が1つでも欠けていると、送信はバリデーションエラーになります。

一方、型安全に本文をコンポーネントとして書きたいなら React Email（react: オプション）です。公式のルールとして、コンポーネントは JSX ではなく関数呼び出しで渡します（WelcomeEmail({ name: "John" })）。両者の使い分けとデザインの実務は Resend テンプレート・React Email 設計ガイド を参照してください。

関門⑤：一括送信・予約送信・購読管理

一括送信は resend.batch.send() で1リクエストにつき最大100通。しかもバッチ1回はレート制限上1リクエストとして数えられるので、スループットの最大のレバーになります。制約は2つ：添付ファイルは未対応、そして既定の batchValidation: 'strict' では1件でも不正なら全体が失敗します。'permissive' にすると通った分だけ送り、失敗を errors: { index, message }[] で返します。

予約送信は scheduledAt に ISO 8601 か自然言語（"in 1 hour"、"tomorrow at 9am" 等）を渡します。最大30日先まで。emails.update() で再スケジュール、emails.cancel() でキャンセルできますが、キャンセルは一方通行（再スケジュール不可）です。そして見落としやすい罠がひとつ——予約に使ったAPIキーを削除すると、その予約メールは送信されません。キーのローテーション手順に予約分の考慮を入れてください。

このサイトのメール講座は7通を予約送信で作成し、購読解除トークンに後続日のメールIDを埋め込んで、解除時に emails.cancel() でまとめて止めています。DBもcronも使っていません。

購読管理では、{{{RESEND_UNSUBSCRIBE_URL}}}（三重波括弧）が Broadcasts と Automations の解除リンク用マージタグです。トランザクションメールに解除リンクを付ける場合は自分で List-Unsubscribe ヘッダを付けます。RFC 8058 のワンクリック解除には List-Unsubscribe-Post: List-Unsubscribe=One-Click も必要で、POST に対して空の200または202を返し、48時間以内に送信を止める必要があります。Gmail と Yahoo は1日5,000通超の一括送信者にこの準拠を求めています。

await resend.emails.send({
  from: "Acme <news@mail.example.com>",
  to: [contact.email],
  subject: "今週のアップデート",
  html,
  headers: {
    "List-Unsubscribe": `<https://example.com/unsubscribe?t=${token}>`,
    // 公式のコードサンプルには載っていないが、RFC 8058 準拠には必須
    "List-Unsubscribe-Post": "List-Unsubscribe=One-Click",
  },
});

バッチの分割戦略、予約のロールバック、Segments と Topics を使った購読管理の実装は Resend の一括・予約送信と購読管理ガイド にまとめました。

関門⑥：Webhook で結果を知る

前述のとおり、受信側でどうなったかはAPIの戻り値では分かりません。Webhook を受けて初めて、配信・バウンス・苦情・遅延・抑制が見えます。

実装の要点は「生ボディ」です。

import { Resend } from "resend";
import { type NextRequest, NextResponse } from "next/server";

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

export async function POST(req: NextRequest) {
  const secret = process.env.RESEND_WEBHOOK_SECRET;
  if (!secret) return new NextResponse("Not configured", { status: 500 });

  // 生のボディ文字列。req.json() でパースしてから stringify すると署名が壊れる。
  const payload = await req.text();

  try {
    // verify は同期関数で、検証失敗時は例外を投げる（{ data, error } ではない）
    const event = resend.webhooks.verify({
      payload,
      headers: {
        id: req.headers.get("svix-id") ?? "",
        timestamp: req.headers.get("svix-timestamp") ?? "",
        signature: req.headers.get("svix-signature") ?? "",
      },
      webhookSecret: secret,
    });

    // ここで event.type によって分岐する
    return new NextResponse(null, { status: 200 });
  } catch {
    return new NextResponse("Invalid webhook", { status: 400 });
  }
}

公式ドキュメントのサンプルはそのままでは動きません。 NextRequest の headers は Headers インスタンスなので、req.headers['svix-id'] は undefined になります（.get() が必要）。さらに別のページのサンプルは payload: JSON.stringify(req.body) と書いていて、これは同じドキュメントが「やってはいけない」と警告している当のアンチパターンです。上のコードは両方を修正した版です。

運用面で押さえるべき性質は3つ。

• at-least-once：同じイベントが複数回届きうる。svix-id ヘッダを保存して重複をスキップする。
• 順序保証なし：email.opened が email.delivered より先に届くことがある。並べ替えるならペイロードの created_at を使う。
• 失敗すると自動無効化される：エンドポイントが失敗し続けるとメール通知が来て、最終的にエンドポイントが自動で無効化される。復旧後はダッシュボードから再有効化する。

再送スケジュールについては、公式の3ページが3通りの記述をしています（6段階、8段階、そして「最大24時間」）。ここは断定を避け、「数時間から24時間程度の再送窓がある」前提で設計するのが安全です。

イベント種別ごとの data の中身、バウンス種別（恒久/一時）の扱い、苦情から抑制リストへの流れは Resend Webhook・署名検証・バウンス処理ガイド に分けました。エンドポイントを守るヘッダ設計は Next.js のセキュリティヘッダとCSP が参考になります。

関門⑦：可観測性とコスト

resend@6 のレスポンスには headers が含まれるので、レート制限と消費枠をコードから読めます。

これらは IETF のレート制限ヘッダのドラフト第6版に準拠しています。retry-after を無視した固定間隔のリトライは、429を429で塗り重ねるだけなので避けてください。

アプリ側のログについては、単一行のJSONで出すことを強く勧めます。ホスティング環境のログビューアは複数引数の console.* を丸めてしまうことがあり、障害の最中に肝心の詳細が消えます。そしてフォーム送信の中身（PII）はログに出さない——出すのは列挙値・ステータスコード・件数だけです。

// 1イベント1行。フィールドは enum / status / count に限定する。
function log(level: "info" | "warn" | "error", phase: string, fields: Record<string, unknown> = {}) {
  console[level](JSON.stringify({ route: "contact", phase, ...fields }));
}

データ保持は Free / Pro / Scale とも 30日（Enterprise は柔軟）。既定ではメッセージ本文が Resend 側に保存されます。本文保存を無効化するのは有料の追加オプション（月額$50）で、対象は3条件すべてを満たすチームだけです：Pro または Scale を1か月以上契約している、稼働中のWebサイトを持つドメインから送信している、3,000通以上をバウンス率5%未満で送信済み。医療・金融など機微な内容を送るなら、設計段階から前提に入れてください。

トランザクションとマーケティングを分ける

同じドメインから「パスワードリセット」と「ニュースレター」を送ってはいけません。苦情はコンテンツ単位ではなくドメイン単位で効いてくるからです。ニュースレターの苦情率が上がると、パスワードリセットの到達率が巻き添えで落ちます。逆は起きません（誰もパスワードリセットをスパム報告しないので）。つまりこれは一方向のリスクであり、分離しない理由がありません。

Resend も公式に、ルートドメインではなくサブドメインからの送信を推奨しています。account.example.com（トランザクション）と updates.example.com（マーケティング）のように用途で分ければ、レピュテーションが独立します。ただしサブドメインはそれぞれ独立したドメインオブジェクトとして追加・検証する必要があるため、無料プラン（独自ドメイン1つ）では両立できません。ここは有料プランを選ぶ実務上の分岐点です。

開封・クリック追跡も分離の対象です。既定では無効で、有効化には専用のトラッキングサブドメイン（CNAME）の検証が必要ですが、公式は「トランザクションメールでは無効のままにする」ことを勧めています。トラッキングによるリンク書き換えは認証リンクを壊す原因としても知られています（Supabase は自社ドキュメントで、リンクトラッキングは検証リンクを壊すことで知られていると明記しています）。ニュースレターだけ追跡を有効にする、というのが健全な形です。

購読管理のモデルも整理しておきます。2026年の Resend は3つの概念で構成されています。

公式の言い方が的確です——「Segments はターゲティングのため、Topics は設定を守るため」。Broadcast に Topic を付けずに送ると、受信者が解除したときにあなたからの全メールが解除されます。Topic の既定購読（opt-in / opt-out）は作成後に変更できない点にも注意してください。

なお、バウンスや苦情で抑制リストに入った宛先はチーム全体・全ドメインで送信がスキップされます。そして重要なのは、抑制は自動でも、Contact の unsubscribed フラグは自動では立たないことです。そこはあなたのアプリの仕事です。

コストの考え方

2026年8月6日時点の公式料金ページの値です（Scale は段が他にもあり、判断に効く段だけを抜粋しています）。送信量（トランザクション）とコンタクト数（マーケティング）は別建てで、それぞれ独立にプランを選べます。

同じ100,000通/月でも Pro は$35、Scale は$90 です。差額が買っているのは送信量ではなく、Slack サポート・ドメイン1,000個・AIクレジット500・専用IPの適格性です。ここを取り違えると素直に損をします。

コストの軸は送信量だけではありません。

• 超過課金：有料プランは1,000通単位で従量課金され、月間枠の5倍で強制的に停止します（上限変更はサポート経由）。チーム設定の "Transactional Overages" で明示的に有効化する必要があります。
• Automation Runs：全プランに10,000実行/月が含まれ、超過分は有料プランで1実行$0.0015。
• AIクレジット：Free 5 / Pro 100 / Scale 500 / Enterprise 柔軟。繰り越し不可で毎月リセット。
• 専用IP：月$30のアドオン。ただし要件が厳しく、Scale プランかつ1日3,000通超の送信が必要です。しかも公式自身が「月9万通未満だとIPを温め続けられない」「送信が不安定だとかえってレピュテーションを損なう」「Resend は専用IPのアドレス一覧を開示しないのでIP許可リストには使えない」と、効かないケースを明記しています。到達率の銀の弾丸ではありません。

料金体系の注意点をもう1つ。公式の料金ページのFAQは「月額プランのみ」と書いていますが、ナレッジベースには「年額は Enterprise で提供」とあります。正しい理解はセルフサーブは月額のみ、年額は Enterprise の営業経由です。

SES・SendGrid・Postmark との比較、実際の送信量での損益分岐は メール配信サービスの技術選定 にまとめました。

本番リリース前チェックリスト

実際に私が Resend を本番に出すとき確認している項目です。

• 独自ドメインを検証済み（SPF の MX と TXT が send サブドメイン、DKIM が resend._domainkey、DMARC が _dmarc）
• トランザクションとマーケティングで送信サブドメインを分離し、追跡はトランザクション側で無効のまま
• APIキーは sending_access＋ドメイン限定を基本にし、full_access は必要な場所だけ
• RESEND_API_KEY はサーバー環境変数のみ。NEXT_PUBLIC_ を付けていない
• Resend クライアントは遅延初期化（モジュールスコープで new Resend(...) していない）
• リトライしうる送信すべてに決定的な idempotencyKey を付けた
• リトライ判断をステータスではなくエラー名で分岐している
• 送信失敗時にリードを失わない経路がある（送信者フォールバック、キュー、または再送導線）
• Webhook を 生ボディで署名検証し、svix-id で重複排除している
• Webhook は順序保証なしの前提で状態遷移を書いている
• バウンス・苦情イベントを受けて自アプリ側の購読状態も更新している
• 一括送信は100通/リクエストの上限と strict / permissive の違いを把握している
• 一斉配信に List-Unsubscribe と List-Unsubscribe-Post を付け、48時間以内に停止できる
• ログは単一行JSONで、PIIを含まない
• レート制限（チーム単位10 req/s）と枠消費をヘッダで監視している
• 無料枠の「送信＋受信の合計」「To/CC/BCC は宛先ごとに1通」を理解した上で見積もった

まとめ：3つの条件を1本の設計として通す

Resend は「5分で送れる」ところまでは本当に速い。本番との差は、そこから先の3つに集約されます。

• 届く：SPF は send サブドメイン、DKIM は resend._domainkey、DMARC は _dmarc。トランザクションとマーケティングを別ドメインに分ける。バウンス4%・苦情0.08%の閾値を監視する。
• 追える：Webhook を生ボディで検証し、svix-id で重複排除し、順序保証が無い前提で状態を進める。ログは単一行JSONでPIIを含めない。
• 二重に送らない：決定的な idempotencyKey を付け、リトライ判断はエラー名で行い、409の2つの意味を取り違えない。

そしてもう1つ。「送信に失敗した」で終わらせない経路を必ず用意してください。 私が502を出し続けた期間に失ったのは、技術的には「1つのDNSレコードの位置」でしたが、事業的には「届いていたはずの問い合わせ」でした。リトライも、送信者フォールバックも、構造化ログも、すべてはそのために書きます。

各テーマの実コードは本クラスタの個別記事に揃えました。まずは自分のドメインの DNS を開いて、SPF レコードが apex ではなく send に載っているかを確認するところから始めてください。

この記事は Resend 公式ドキュメント（Emails API / Domains / Webhooks / Segments・Topics / Pricing、2026年8月時点）と、インストール済み resend@6.4.1 の型定義に基づき、実運用の判断軸を加えて再構成したものです。仕様・価格は更新されるため、本番採用時は各公式ページで最新値をご確認ください。