Resend bounce/complaint webhook: the email half of #311

[Jolah1]

Split out of #311, which landed the Twilio half in #321.

What's missing

#321 records delivery verdicts for SMS and WhatsApp via Twilio's StatusCallback. Email has no equivalent wired up, so a hard bounce or a spam complaint is still invisible: the row reads status='sent' forever.

This matters as much as the Twilio half. Resend accepts at SMTP, bounces later, and then adds the address to its account-level suppression list — after which every subsequent send to that address is silently dropped. An owner or heir can go permanently unreachable while the dashboard reports every message as sent.

Why it wasn't done in #321

Two unknowns that need checking against the live account rather than guessing:

1. Correlation. We send over SMTP, so we have no Resend message id at handoff. fix(server): record what the provider says happened, not just handoff #321 now stores the SMTP 250 reply in provider_message_id on the theory that Resend puts a queue id there, but that is unverified. Needs one real send inspected to confirm the format, and whether it matches data.email_id in the webhook payload.

   If it doesn't match, the fallback is matching on recipient — which is awkward because recipient_ciphertext is AEAD-sealed with a random nonce, so it isn't searchable. That would need a deterministic lookup column (e.g. an HMAC of the address under the master key), which is a design decision, not a patch.

2. Secret. Resend signs webhooks with Svix (svix-id, svix-timestamp, svix-signature, HMAC-SHA256 over a base64 secret). That's a new RESEND_WEBHOOK_SECRET env var and a Resend dashboard endpoint configuration — unlike the Twilio path, this one is not zero-config.

Scope

• POST /webhooks/resend with Svix signature verification, including the timestamp tolerance check (replay protection)
• handle email.bounced and email.complained; optionally email.delivered
• reuse delivery::record_delivery, which is already provider-agnostic
• document the secret and the dashboard step in DEPLOY.md

Blocks

#311 shouldn't close until this lands — half the channels reporting delivery is not the same as knowing whether messages arrive.

[Jolah1]

I checked current main at 8be9293fe9d2c416ae6df13082eccece2f69c277. There is a cleaner correlation path to test before adding a recipient HMAC or assuming the SMTP 250 text equals Resend's data.email_id:

1. send_email currently stores response.message(). Keep that as an SMTP queue reply, but do not make it the webhook foreign key unless the live canary proves exact equality. Since 2026-07-08, Resend includes data.message_id in every email.* webhook specifically for cross-system correlation: https://resend.com/changelog/message-id-for-sent-emails. Lettre 0.11 can set MessageBuilder::message_id. I would generate and persist one stable RFC 5322 Message-ID per notification before handoff, reuse it on retries, and make the canary prove that Resend preserves it. This avoids searching encrypted recipients.
2. record_delivery currently updates unconditionally and appends a new owner event for each negative callback. Resend delivery is at-least-once and events may arrive out of order. Persist svix-id under a unique constraint, plus provider created_at/terminal precedence, before calling the shared recorder. Otherwise a replay can duplicate notification_undelivered, and a late email.delivered can overwrite a prior bounce.
3. Map email.bounced, email.failed, email.suppressed, and email.complained explicitly into the internal negative-verdict model. Passing literal bounced/complained into the current is_negative_verdict would not surface an owner alarm.

A bounded proof sequence is email.sent first, then Resend's bounced+ghostkey@resend.dev and complained+ghostkey@resend.dev test recipients. Verify the signature against the raw body, replay the same svix-id, then deliver events in reverse order. That covers correlation, authenticity, idempotency, and ordering without using a real heir address.

If useful, I can deliver the endpoint, migration, fixtures/tests, and DEPLOY.md checklist as a reviewable PR for 29 USDC on Base. No dashboard or SMTP credential would be posted or handed over; the signing secret stays operator-side. Scope/private checkout: https://mailcheck.agentcartai.com/tools/verification-email-triage/?utm_source=github&utm_medium=issue_comment&utm_campaign=ghostkey_resend_webhook_322

Thanks, all three were right and all three are fixed.

Correlation: the SMTP reply is gone. We now set our own Message-ID before handoff and store that, derived from the row id so it's stable across retries, opaque so it leaks nothing. Falls back to email_id if Resend ever omits it. #325

Idempotency and ordering: worse than you framed it. Twilio is at-least-once too, so a retried undelivered was already writing the owner's activity feed twice on mainnet. Fixed separately in #324: provider event ids claimed under a primary key (svix-id for Resend, MessageSid:MessageStatus for Twilio), plus a rank so a late email.sent can't bury a bounce.

Verdict mapping: the migration and /health both listed bounced/complained, and is_negative_verdict didn't. Two lists with nothing pinning them. Fixed, with a test that fails if they drift again.

On the paid PR, I'll pass. Not about the price, but the correlation-key choice is one I want to own. The review itself was genuinely useful.