Implemented startup mail‑provider validation across three providers (SendGrid, SMTP2GO, Azure ACS) with environment‑aware behaviour — logging in development, failing the boot in staging and production.

Situation. Email carries a lot of weight on NextMariner — verification, notifications, the things a user actually waits for. And a mail provider is exactly the kind of dependency that fails quietly: the config looks fine, the app boots, and you only find out something’s broken when a real person never gets the message they were promised. That’s the worst way to learn about it.

Task. The app needed to check, at startup, that mail actually worked, and to be loud about it in the environments where it matters, without turning a routine local run into a nuisance.

Action. So provider validation went into the boot sequence, behind a MAIL_VALIDATE_ON_START flag. It sends a real test through the provider stack — SendGrid as primary, with SMTP2GO and Azure Communication Services behind it as fallbacks — and how it reacts depends on where it’s running. In develop it just logs a warning and carries on; nobody wants their laptop refusing to start because a sandbox key expired. In staging and production a failure is fatal: the process exits rather than deploy a build that can’t send mail. The send itself goes through an SSRF‑protected client with a 30‑second timeout, and the async delivery path has its own retries and backoff so a momentary blip doesn’t drop a message.

Result. A whole category of silent failure moved from “a user notices days later” to “the deploy stops.” Where broken email is a real problem it can’t slip through; on a developer’s machine it stays out of the way. Same check, different volume depending on who’s watching.