Why this is a case study
Most case studies are about something hard that looked hard. This one is about something that looked trivial. “Set up email for the domain” is the kind of line item you don’t even estimate. But the moment we looked, the domain’s mail was being routed by a service we’d stopped using, the app’s contact address was a typo pointing at a domain that doesn’t exist, and every automated email the site sent was failing. None of it showed up as an error. That’s the point. The interesting systems failures aren’t the loud ones; they’re the ones engineered to stay quiet.
The task
The ask was simple: business email on bfl.design, run through Microsoft. A few DNS records, a mailbox, done by lunch. That’s genuinely all it should have been — if the ground underneath had been what everyone assumed it was.
What was actually broken
Setting up Microsoft is what surfaced all of it — these were latent issues caught during the migration, not a standing outage. The first DNS lookup told the real story: the domain’s mail was still being routed to Google — a leftover from a Workspace setup nobody used anymore, quietly intercepting anything sent to the domain. That was the visible problem. The invisible ones were worse.
By the numbers
0
verified send domains — every app email was failing
5
free role-based shared mailboxes, built to scale
2
email providers made to coexist on one domain
3/3
SPF · DKIM · DMARC passing on both senders
The app’s server code sent its lead notifications to an address held in an environment variable. That variable was a typo — appsupport@bigfreioghtlife.com, a domain that doesn’t exist. Every “new lead” notification the site generated had been addressed to nowhere and silently dropped.
Then the big one. The site sends real email through Resend — the lead-magnet PDF, newsletter confirmations, lead alerts. Resend had zero verified domains. A provider won’t send from a domain you haven’t proven you own, so every one of those sends had been failing at the door. And because the code was written fail-soft — return false, never throw, never break the user’s request — nothing surfaced. Slack pings and the database were the only channels actually working. The email half of the system was failing quietly behind a green light.
The system we built
Receiving and sending got split cleanly. Microsoft 365 owns receiving on the root domain. Resend owns sending, scoped to a send.bfl.design subdomain so two independent providers authenticate on the same domain without colliding — no shared SPF record to fight over. From there it was architecture, not patching.
Mailboxes were modeled by role, not by person: one licensed human inbox, plus five free shared mailboxes — hello@, support@, billing@, leads@, no-reply@. A solo operator doesn’t need five inboxes. A growing studio does, and adding a teammate to a role is a click instead of a re-architecture. The app’s routing was untangled to match: customer replies to hello@, internal lead alerts to leads@, automated sends from no-reply@.
Then authentication, all the way down: SPF, DKIM, and DMARC — on both senders. The same domain now passes every check whether the mail came from Outlook or from the app.
The landmine
Deploying the fix should have been the easy part. The production build failed on a remotion import that didn’t exist in the project — except it did, buried in a drafts/ folder: a half-finished video sub-project carrying its own node_modules. The local build skipped it. Production tried to compile it and died. It’s the rule this shop already lives by, paid in full: a working localhost is not proof the build is green. One .vercelignore later, the deploy went out clean.
What it proves
Doing this “right” instead of “working” is what surfaced every one of these. The takeaways aren’t about email.
Fail-soft is not failure-free
Code that never throws keeps the user’s path alive — and can hide that a whole channel is dead. The send pipeline reported “handled” while delivering nothing. Fail-soft must be paired with verification and alerting, or it just buries the outage.
Verify, don’t assume
The domain was wired into the app as if it could send. It never could — it was never verified with the provider. “It’s configured” and “it works” are different claims; only one of them you can prove with a query.
A working localhost is not a green build
The deploy died on a stray sub-project the local build happily skipped. The only proof a build is green is building it the way production will.
Build for the org you’re becoming
Mailboxes were modeled by role, not by person — five shared inboxes a one-person shop doesn’t need yet, so a future teammate is one click, not a migration.
Back to all case studies. Prefer the AI angle? Read how this same site’s lead bot was secure but unprotected.