メールのしくみ 9：Resend と2つの入口

自分でメールサーバーを立てると

まず、Resend を使わずに自分でメールサーバーを立てた場合を考えます。

出口が塞がれています。 3本目で見たとおり、AWS や Google Cloud などの多くのクラウドは、25番ポートからの外向きの通信を最初から塞いでいます。相手のサーバーに直接渡すことができません。解除の申請ができる場合もありますが、審査があります。

評判がゼロです。 8本目で見たとおり、新しく借りた IP アドレスには実績がありません。実績が無いどころか、その番号を以前使っていた誰かが迷惑メールを送っていて、最初から点数が低いことさえあります。

作るものが山ほどあります。 DKIM の鍵を作って安全に保管し、1通ずつ署名する仕組み。相手のサーバーが一時的に受け取れないときに、数日にわたって再送する仕組み。戻ってきたバウンスを受け取って、どの宛先が存在しないかを記録する仕組み。

どれも、一人で作って保守し続けるには重すぎます。

Resend は、評判の良い送信網を APIキー1本で貸してくれる

Resend は、この大変な部分をまとめて引き受けてくれる、メール送信のサービスです。

中身は Amazon の SES（Simple Email Service）という大規模な送信基盤です。Resend はその上に、開発者が使いやすい API と管理画面を載せています。

借りられるものは次のとおりです。

こちらが用意するのは、Resend の API キーと、次の作品で説明する DNS の設定だけです。無料の枠もあり、少量の送信なら費用もかかりません。

「メールを送る」ために本当に難しいのは、SMTP を話すことではなく、身元と評判の問題を解くことでした。Resend を使う理由は、そこを借りられることにあります。

借りられないもの：自分のドメインと、その評判

Resend が何でも代わりにやってくれるわけではありません。借りられないものが2つあります。

1つ目は、DNS の設定です。SPF・DKIM・DMARC の宣言は、mail.animemo.app の掲示板に書かなければなりません。2本目で見たとおり、その掲示板に書けるのは持ち主だけです。Resend がどれほど親切でも、あなたのドメインの掲示板には書けません。だから Resend は「この値を DNS に入れてください」と案内するところまでしかできません。これは10本目で見ます。

2つ目は、ドメインの評判を守る運用です。8本目で見たとおり、共有の送信元の評判は Resend が守りますが、ドメインの評判は自分の送り方で決まります。存在しない宛先に送り続けたり、苦情が多いメールを送ったりすれば、評判は下がります。これは11本目で見ます。

逆に言えば、この2つさえきちんとやれば、残りは Resend に任せられます。

Resend には入口が2つある

Resend に「このメールを送って」と頼む方法は2つあります。

どちらの入口から入っても、その先で起きること（署名・配送・記録）は同じです。違うのは、頼み方だけです。

SMTP の入口があるのは、世の中には「SMTP の設定欄しか持っていないソフト」がたくさんあるからです。3本目で見たとおり、SMTP はメールの世界の共通語なので、SMTP さえ話せれば、どんなソフトからでも Resend を使えます。

次の2ページで、それぞれの入口を詳しく見ます。

入口①：HTTP API。JSON を1回 POST するだけ

HTTP API は、Web の API を呼ぶのと同じ形で使えます。

const res = await fetch("https://api.resend.com/emails", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.RESEND_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    from: "Animemo <[email protected]>",
    to: "[email protected]",
    subject: "招待が届いています",
    html: "<p>…</p>",
    text: "…",
  }),
});
const { id } = await res.json();

Authorization ヘッダーに API キーを載せることで、「この頼みは正当な持ち主から来た」ことを Resend に示します。

from には、Resend で確認済みのドメインのアドレスしか使えません。確認していないドメインを名乗れないことは、4〜7本目で見たなりすまし対策の考え方そのものです。

成功すると、送ったメールの `id` が返ってきます。この id は、後で Resend から「届いた」「戻ってきた」という知らせ（11本目の Webhook）が来たときに、どのメールの話かを照らし合わせるのに使います。DB に残しておきます。

入口②：SMTP。メールソフトと同じ設定欄に入れる

SMTP の入口は、メールソフトに送信サーバーを設定するのと同じ要領で使います。

ポートが 25 ではなく 465 や 587 なのは、3本目で見たとおり、これが「送信を頼むための入口」だからです。ログインと暗号化が付いています。

パスワード欄に API キーを入れる点に注意してください。HTTP API のときと同じキーで、同じように秘密です。

Animemo は、2つの入口を両方使う

Animemo が送るメールは2種類あり、入口を使い分けます。

Supabase Auth が送るメール（登録確認・パスワード再設定）は SMTP です。 これらのメールを送っているのは Supabase で、Animemo のコードではありません。Supabase は世の中のあらゆるメールサービスの API を知っているわけではないので、どこでも通じる共通語として SMTP の設定欄だけを用意しています。そこに Resend の SMTP を差し込みます。

Animemo 独自の招待メール（作品・組織への招待）は API です。 こちらは自分たちの Fastify から送るので、細かく扱える API を選びます（次のページ）。

Animemo の手順書（docs/operations/smtp-and-invitation-email.md）では、Resend を呼ぶ処理を server/src/lib/email.ts の1か所に閉じ込め、各ルートから直接呼ばない方針になっています。送信サービスを差し替えることになっても、直す場所が1つで済むようにするためです。

自前のメールで API を選ぶ理由

自分のコードから送るなら、SMTP ではなく API を選ぶ理由があります。

冪等キーを付けられる。 通信が途中で切れて「送れたか分からない」とき、同じキーで送り直せば二重に届きません（11本目）。

送ったメールの id が手に入る。 DB に記録しておけば、後から届いた「届いた」「戻ってきた」の知らせと照らし合わせられます。

失敗の理由が分かる。 確認していないドメインを from に使った、宛先の形がおかしい、などの失敗が、JSON で理由付きで返ってきます。

SMTP の会話を実装しなくていい。 SMTP のライブラリを入れて接続を管理する必要がなく、fetch 1回で済みます。

Resend は公式の SDK（resend パッケージ）も用意していますが、中でやっていることは前のページの fetch と同じです。

API キーはサーバーにだけ置く

API キーは、それを持っている人が、あなたのドメインの名前でメールを送れる鍵です。

もしブラウザ側のコード（Animemo なら client/）に書いてしまうと、ページを開いた誰もが開発者ツールでキーを読めます。読んだ人は、[email protected] を名乗って好きなメールを送れます。しかも SPF・DKIM・DMARC はすべて合格します。本物の送信網から送られるからです。

だから API キーは、サーバーの環境変数（`RESEND_API_KEY`）にだけ置きます。これは、CLAUDE.md の「SERVICE_KEY・STRIPE_SECRET_KEY は server/ のみ」と同じ考え方です。

Resend の API キーには、被害を小さくする工夫もあります。キーの権限を「送信だけ」に絞れます。さらに、送れるドメインを限定することもできます。万一漏れたときは、Resend の画面でそのキーを削除して作り直せば、古いキーは使えなくなります。

Supabase の組み込み送信のままではいけない理由

Supabase には、最初から組み込みのメール送信が付いています。何も設定しなくても登録確認メールが届くのはそのおかげです。ただし、これはお試し用です。

1時間に送れる数がごく少なく、送れる宛先もプロジェクトのチームメンバーのアドレスに限られます。開発中に自分で試すには十分ですが、本番で利用者が増えると、ある日突然、登録確認メールが届かなくなります。

しかも、組み込みの送信では、身元確認や評判について、こちらから何も手を打てません。Supabase のドメインから送られるので、利用者から見ても Animemo のメールだと分かりにくくなります。

Animemo のデプロイ手順書（docs/operations/deploy.md）にも、太字で「ここを飛ばすと、ある日突然メールが届かなくなる」と書いてあります。

Supabase に Resend の SMTP を登録する

対策は、Supabase の管理画面の Authentication → SMTP Settings で Custom SMTP を有効にし、Resend の SMTP を登録することです。

登録後に気をつけることが3つあります。

送信数の上限。 Custom SMTP にした直後も、Supabase 側の送信数の上限（Authentication → Rate Limits）は低い値から始まります。必要に応じて引き上げます。

メールの文面。 Authentication → Email Templates で、登録確認などの文面を Animemo 向けに書き換えます。

リンクの追跡。 認証用のリンクが書き換えられないよう、Resend 側でリンクの追跡を有効にしないでおきます（11本目）。