The Saturday Reminder

The Banned Sender

Incident & fix · Email deliverability · Camellia / all properties · Sat Aug 16, 2026 · Fix shipped & live-verified — two 1-minute ops steps remain

In one paragraph. Clara's emails travel through SendGrid, and until tonight we sent from a shared address pool — many unrelated companies, one reputation. A stranger on that pool spammed; Microsoft banned two of the pool's addresses; and since the JP office's email runs on Microsoft, four of Clara's office-bound emails bounced (two signature reminders, one tour confirmation, one tour cancellation) — silently, because the system that should report bounces was never switched on. Tonight both problems were fixed: Clara now sends from her own dedicated address (verified: Microsoft accepted a test into the Camellia mailbox over the new address), and every future hard bounce will page #alerts in plain English instead of vanishing.

What failed, in order

  • Cause Shared SendGrid pool → a stranger's spam → Microsoft error 550 5.7.511 banned sender on two pool addresses (167.89.40.80, 50.31.49.42). Our own SendGrid reputation: 100/100 — this was not our behavior.
  • Blast radius Intermittent (SendGrid rotates addresses): some office email got through, four messages died — Warren + Guerra signature reminders, the Brownlee Tue Aug 18 1 PM tour confirmation, the Wetzel Sat tour cancellation.
  • Why silent SendGrid's event reporting (the channel that tells our app "this bounced") was never configured — zero webhooks on the account. Even our existing renewal bounce-handling code has never received an event in production. A signing key half-installed 3 months ago suggests the wiring was started and never finished.

What shipped tonight

ItemStatusProof
SendGrid Pro upgrade (Fede) + dedicated sending address 159.183.90.163, attached to the propflowai.co domain authLiveTest email to the Camellia mailbox delivered over the new address — Microsoft answered 250 … Queued mail for delivery; SendGrid log shows outbound_ip_type: dedicated
SendGrid event reporting switched on (bounce / dropped / blocked / spam-report → our app, cryptographically signed)DoneWebhook propflow-prod-delivery-failures on the account
Bounce alarm: any hard failure to a real recipient posts one plain-English #alerts message (batch-deduped, test traffic excluded, Slack-outage-proof)PR in reviewPR #5802, auto-merges on green
No real person stuck on SendGrid's "never email again" listVerifiedSuppression lists hold only smoke/test fixtures

Two 1-minute steps for Fede (agent is blocked on both by design)

1. Give production the webhook signing key

Paste in a terminal at the repo (key sits in the session scratchpad file sg_signed.json; or copy it from SendGrid → Settings → Mail Settings → Event Webhook → signature verification):

npx vercel env add SENDGRID_EVENT_WEBHOOK_PUBLIC_KEY production (then the same with preview). Next deploy picks it up; until then bounce events are rejected loudly, by design.

2. One DNS record in Cloudflare (reverse DNS — providers trust an address that answers with our name)

propflowai.co zone → add A record: name o1.o1.propflowai.co → 159.183.90.163, DNS-only (gray cloud). Then tell the agent — validation from our side takes one API call.

Still open (recommendation, not done)

  • Brownlee's Tuesday 1 PM tour — the office never got the confirmation; a human at JP should re-confirm it exists on their calendar.
  • DMARC is at the correct minimum (p=none, reports to Fede). Recommendation after 2–4 clean weeks on the dedicated address: tighten to quarantine. Not urgent, should be a deliberate step.
  • New addresses normally "warm up" over ~2 weeks; at our volume (~50 emails/day) we're inside day-one limits, but expect the occasional deferral (delayed, not lost) in week one — the new alarm makes any real loss visible.
PropFlow Docs