Resend
定義
Resendは、アプリケーションからメールを送るためのAPIサービス。公式は「Email API for developers」と位置づけている。注文確認やパスワードリセットのようなイベント駆動の個別メール（トランザクションメール）と、連絡先リストへの一斉配信（マーケティング配信）の両方を扱う。
使い始めるまで
自分が所有するドメインをResendに登録して検証し、APIキーを発行する。共有ドメインからの送信はできず、最低1つの検証済みドメインが要る。
送信ドメインまわりでできること
- DMARCとBIMIの設定
- 開封・クリックのトラッキング
- 暗号化された経路にのみ送る Enforced TLS
- Return-Path 用のサブドメイン指定
- 送信元リージョンの選択（北バージニア／アイルランド／サンパウロ／東京）
公式は、ルートドメインではなく updates.example.com のようなサブドメインからの送信を勧めている。用途ごとに送信レピュテーションを切り分け、受信側に何のメールかを伝えるため。用途別に複数のサブドメインを検証して使い分けることもできる。
開発者向けの間口
Node.js、Next.js、Python、Ruby、Rails、Go、PHP、Laravel、Rust、Elixir、Java、.NET といったSDKに加え、CLIとMCPサーバーを提供する。配信結果はWebhookでアプリに通知でき、受信（inbound）にも対応する。
Reactのコンポーネントでメールのテンプレートを組むOSSの React Email（resend/react-email）も、同じチームが開発している。
背景
三つめの選択肢として
ECやSaaSのトランザクションメールでは、長らくSendGridとAmazon SESが事実上の二択だった。SendGridは機能と実績が厚い一方で設定の階層が深く、Amazon SESは安価で堅牢だがドメイン認証もバウンス処理も自前で組む前提が強い。
Resendはそこに、API、SDK、ダッシュボード、ドキュメントの体験を前面に置いた選択肢として現れた。決済で言えば、従来のPSPに対してStripeが登場したときの印象に近い。機能を並べ替えたというより、開発者が最初の1通を送るまでの距離を縮めることを設計の軸に置いている。
何が評価されているのか
採用が伸びている理由は、機能の数ではなくメールを作って送るまでの開発のしかたそのものを置き換えた点にある。
メールをReactコンポーネントとして書ける
従来のメール制作は、レイアウトを崩さないためにHTMLのテーブルタグを入れ子で組み、HandlebarsのようなテンプレートDSLで値を差し込むのが定番だった。React Emailを使うと、この部分をJSXのコンポーネントとして書ける。Tailwind CSSでのスタイル指定に対応し、ローカルでリアルタイムにプレビューできる。Web画面と同じ道具立てと同じ書き方でメールを作れるため、コンポーネントの再利用もレビューも通常のフロント開発と地続きになる。
TypeScript前提のSDK
SDKがTypeScriptを前提に設計されているため、テンプレートに渡す値の型がエディタ上で検査される。変数の入れ忘れや型違いを、本番で「メールの一部が空欄だった」と気づく前に、コンパイルの段階で止められる。
サーバーレスとエッジで動かしやすい
APIとSDKが軽量なので、Next.jsのServer Actions、Vercelのエッジ関数、Cloudflare Workersといった実行環境にそのまま載る。送信リージョンも選べるため、エッジから送る構成でも送信元を利用者に近づけられる。東京リージョンがあるのは国内案件では実利がある。
コードファーストな観測性
マーケター向けのドラッグ＆ドロップエディタのような機能は持たず、代わりにログとイベントの扱いに寄せている。1通ごとの内容と状態をダッシュボードで追え、送信・到達・バウンス・苦情・開封といった状態はWebhookでアプリ側のイベントとして受け取れる。「メールが届いていない」という問い合わせの調査が、ログを追うだけで完結しやすい。
導入までの手数が少ない
ドメインを検証してAPIキーを発行すれば送れる。この手軽さは、従来サービスへの不満の裏返しでもある。機能の肥大化、古いダッシュボード、アカウント審査の厳しさといった摩擦が開発者の間で語られるようになり、Resendはその受け皿として広がった側面がある。
送信基盤を選んでも、ドメインの責任は残る
どのサービスを選んでも、到達性の土台になるのは送信ドメイン側の設定になる。SPFとDKIMを整え、DMARC のポリシー配下に収める作業は、Resendを使っても消えない。Resend自身がDMARCとBIMIの設定項目をダッシュボードに持っているのも、そこが避けて通れないからだ。
同じドメインから送る経路が複数あるときは、さらに注意が要る。MAツール、課金サービス、そしてResendのような送信基盤が並存すると、それぞれのSPF／DKIMをそろえて一本のポリシーに収める設計が必要になる。
Shopifyストアで使う場合の位置づけ
Shopifyストアの注文確認メールや通知メールは、Shopify自身が送る。したがってResendが担うのはその外側になる。カスタムのバックオフィス、自社アプリ、問い合わせフォームからの通知といった領域だ。
つまりShopify案件でResendを入れると、ストアのドメインから送る経路が1本増える形になる。Shopify側の送信ドメイン認証とResend側のドメイン検証を、同じDMARCポリシーの下で成立させる必要がある。
Flagshipでの関わり
自社プロダクトの通知メール送信にResendを採用している。クライアント案件ではこれまでSendGridを中心に構成してきたが、新規の構築では選択肢として検討する対象になっている。
選択肢を広げたい動機は、開発体験だけではなかった。メール配信サービスの新規アカウント利用申請が、明確な理由が示されないまま通らないことが当社でも複数回あり、立ち上げが足踏みした経験がある。審査の基準は各社の内部にあり、こちらから確実に満たす方法がない。そのため送信基盤は単一の前提に寄せず、複数の選択肢を実際に使える状態にしておくこと自体を、運用上のリスク管理として扱っている。
外部の送信基盤を使う場合は、経路ごとのSPF／DKIMアラインメントと、迷惑メール判定の事前テストを、DMARC整備とセットで確認する。