メールのしくみ 11：運用とつまずき

認証や招待のメールでは、リンクの追跡を切る

メール配信サービスの多くにはクリック追跡の機能があります。Resend にもあります。メールの中のリンクを、いったん計測用のドメインを経由する URL に書き換え、誰がいつクリックしたかを記録するものです。宣伝メールの効果を測るには便利ですが、登録確認や招待のメールでは切っておきます。

理由の1つは、書き換えでリンクの見た目と行き先のドメインが違う状態になることです。8本目で見たとおり、これはフィッシングメールの典型的な形で、迷惑メール判定で疑われやすくなります。受け取った人から見ても、「animemo.app のメールなのに、リンクは知らないドメイン」は不安を誘います。

もう1つは、経由先の都合で認証用のリンクが壊れることがあるためです。Supabase の資料も、認証メールではリンク追跡を無効にするよう勧めています。Animemo の手順書にも「リンク追跡は認証リンクを書き換えることがあるため無効にする」とあります。

開封の追跡も、認証のメールには要らない

もう1つの追跡の機能が、開封の追跡です。

仕組みは単純です。メールの本文に、目に見えない 1×1 の小さな画像を埋め込んでおきます。受け取った人がメールを開くと、メールソフトがその画像を取りに来るので、「開いた」と数えられます。

ただし、この数え方は正確ではありません。画像を自動で読み込まない設定の人は、開いても数えられません。逆に、プライバシー保護のために画像を先読みするメールソフトでは、開いていなくても数えられることがあります。

登録確認やパスワード再設定のメールで、開いたかどうかを知る必要はほとんどありません。必要のない追跡は切っておくのが、受け取る人にとっても親切です。

「送れたか分からない」ときのために、冪等キーを付ける

API で送るとき、通信が途中で切れて返事が来ないことがあります。このとき、Resend はメールを受け取ったのか、受け取っていないのか、こちらからは分かりません。

受け取っていなかったなら、送り直す必要があります。でも、実は受け取っていたなら、送り直すと太郎さんに同じ招待が2通届きます。

これを解くのが冪等キー（Idempotency Key）です。「冪等」は、同じ操作を何度繰り返しても結果が1回と同じ、という意味です。

Idempotency-Key: organization-invite/42

リクエストにこのヘッダーを付けておくと、Resend は同じキーのリクエストを覚えていて、2回目以降は新しく送らず、1回目の結果を返します。だから、返事が来なければ安心して同じキーで送り直せます。

キーには、招待の ID のようにそのメールに固有の値を使います。Animemo の手順書では organization-invite/{invitation-id} のような形が提案されています。冪等キーは、HTTP API だけでなく SMTP の入口でも使えます。

キーの記憶は24時間。だから DB にも記録を残す

Resend が冪等キーを覚えているのは 24時間です。それを過ぎると、同じキーでも新しいメールとして送られます。

そこで、Animemo の手順書では、招待の行に送信の記録も持たせる設計になっています。

この記録があれば、24時間を過ぎた後でも「もう送ったか」を自分で判断できます。また、次のページ以降で見る Webhook の知らせが届いたとき、provider_message_id で「どの招待のメールの話か」を照らし合わせられます。

外部のサービスが覚えていてくれることに頼り切らず、大事なことは自分の DB にも残す。外部サービスと組み合わせるときの基本です。

DB の保存とメール送信を、1つのトランザクションにしない

招待メールの処理は、「① 招待を DB に保存する」と「② メールを送る」の2段階です。ここで、「両方まとめて1つのトランザクションにして、メールが失敗したら DB も巻き戻そう」と考えたくなります。

これはやめておきます。メールは、一度送ったら取り消せないからです。

たとえば「メールは相手に届いたが、Resend からの返事が来る前に通信が切れた」とします。コードは失敗だと判断して DB を巻き戻します。すると太郎さんの手元には、DB に存在しない招待のリンクが届いていることになります。リンクを開いても「招待が見つかりません」になります。

そこで順番を分けます。招待は先に DB に確定させます。メールの送信に失敗したら、招待は残したまま「招待は作成したが、メールの送信に失敗しました。再送できます」と画面に出します。再送は冪等キーで安全に行えます。

DB は巻き戻せても、外の世界に出たものは巻き戻せません。これはメールに限らず、決済や外部 API を呼ぶ処理全般に当てはまる考え方です。

再送するときは、リンクの鍵（トークン）を新しくする

招待メールを再送するときにも、気をつけることがあります。Animemo の手順書では、再送のたびにトークンを新しくし、古いトークンを無効にする方針になっています。

招待のリンク（/invite/:token）に含まれるトークンは、「このリンクを持っている人は招待を受けられる」という鍵です。再送のたびに同じトークンを使い回すと、1通目のメールがどこかに転送されていたり、誤った宛先に届いていたりした場合でも、そのリンクが有効なまま残ります。

新しいトークンにすれば、有効なリンクは常に最新の1つだけになります。

もう1つの約束として、DB にはトークンの平文を保存せず、SHA-256 のハッシュだけを置きます。6本目で見たハッシュの性質（ハッシュから元の値は作れない）のおかげで、万一 DB の中身が漏れても、そこからリンクを作ることはできません。

届かなかった・迷惑と言われた、を受け取る

送ったメールがその後どうなったかは、Resend が Webhook で知らせてくれます。Webhook は、何か起きたときに相手のサービスが、こちらの URL へ HTTP で通知を送ってくる仕組みです。

大事なのは下の2つです。8本目で見たとおり、存在しない宛先や、迷惑だと言った人に送り続けると、評判が下がり、他の人あてのメールまで届かなくなります。Animemo の手順書にも「恒久的なバウンスと苦情の宛先には自動で再送しない」とあります。

Webhook は、署名を確かめてから読む

Webhook を受け取る URL は、インターネットに公開されています。つまり、誰でもそこに偽の知らせを送れます。「このアドレスは bounced だった」という嘘の知らせで、正しい利用者へのメールを止めさせることもできてしまいます。

そこで、Resend は知らせに署名を付けて送ってきます（Resend は Svix という仕組みを使っていて、svix-id・svix-timestamp・svix-signature のヘッダーが付きます）。こちらは、Resend の管理画面で発行される秘密の値を使って署名を確かめ、合わないものは捨てます。

考え方は、6本目の DKIM や、Animemo の Stripe の Webhook とまったく同じです。そして、Stripe のときと同じ注意がここでも必要です。署名は、届いたままの本文（rawBody）に対して確かめます。 JSON として読み込んでから整形し直すと、1文字でも変われば署名は合わなくなります。

テストでは、でたらめなアドレスに送らない

動作確認のとき、[email protected] のような適当なアドレスに送りたくなります。でも、実在しない宛先に送ると、それは本物のバウンスとして数えられ、8本目の評判が下がります。

Resend には、試験用のアドレスが用意されています。

これらを使えば、評判を傷つけずに、この作品で見た Webhook の処理まで一通り試せます。

手元で Supabase を動かしているときは、Supabase CLI に付いている Mailpit で、送られたメールをブラウザで見られます。実際には外へ送られないので、何通送っても大丈夫です。

From を @gmail.com にはできない

ここからは、よくあるつまずきです。

「差出人を自分の @gmail.com のアドレスにして Resend から送りたい」は、できません。

まず Resend 自体が、DNS で確認済みのドメインからしか送らせてくれません。gmail.com の掲示板に書けるのは Google だけなので、あなたが確認を通すことはできません。

仮に別の方法で送れたとしても、7本目の DMARC で止まります。From: のドメインは gmail.com なのに、SPF も DKIM も gmail.com として合格させる手段がありません。一致が取れないので、迷惑メール行きか、拒否になります。

これは不便に見えますが、4〜7本目で作った仕組みが正しく働いている結果です。自分が持っていないドメインを名乗れないことこそが、なりすましを防いでいます。メールを送るなら、自分のドメインを持つのが出発点です。

迷惑メールに入ったら、まず判定結果を読む

設定したはずなのに迷惑メールフォルダに入る。そんなときに当て推量で設定をいじる前に、受け取った側の判定結果を見ます。

Gmail でそのメールを開き、メニューから「メッセージのソースを表示」を選ぶと、生のヘッダーの中に次のような行があります。

Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=send.mail.animemo.app;
  dkim=pass [email protected] header.s=resend;
  dmarc=pass (p=NONE) header.from=mail.animemo.app

3つとも pass なのに迷惑メールに入るなら、原因は8本目の評判か、本文の中身のほうです。

Animemo で確かめること

最後に、Animemo の手順書（docs/operations/smtp-and-invitation-email.md）にある受け入れ確認を、このシリーズの言葉で読み直します。

表の右側を見ると、どの確認も、このシリーズのどこかで「なぜそうするのか」を見てきたものだと分かります。