April 6, 2026 | 8 min read
We woke up on a Tuesday morning to find that every single email our products sent -- password resets, welcome messages, subscription confirmations, grading notifications -- was bouncing. Not some of them. All of them. Our email provider had permanently disabled our account overnight, with no warning and no appeal process. Just a single-line notification: "Your account has been suspended due to policy violations."
We are a small group of friends from Tennessee building SaaS products under our company, Obsidian Clad Labs. We run five live products, and every one of them depends on transactional email to function. This was not an inconvenience. It was a full-blown emergency. Here is what happened, what we did wrong, and what we learned so you do not make the same mistakes.
What Actually Happened
The root cause was embarrassingly simple. One of our team members had been doing outreach -- cold emails to potential users we thought might benefit from one of our products. The email list was not validated. Many addresses were outdated, misspelled, or simply did not exist. The result was a bounce rate above 15%, which is catastrophically high by any email provider's standards.
Most email providers have a hard limit around 5% bounce rate. Go above that and you trigger automated fraud detection systems. Go way above that, as we did, and your account gets flagged as a spam source and terminated. The provider does not care that your transactional emails are legitimate. They care about protecting their sending reputation and their other customers. From their perspective, they made the right call.
The problem was that we were sending marketing outreach through the same account we used for transactional email. When the outreach emails bounced, the entire account got flagged, and our perfectly legitimate password resets and welcome emails went down with it.
The Emergency Migration
We had about three hours between discovering the problem and our first users reporting that they could not reset their passwords. The fix was straightforward but stressful: sign up with a new email provider, verify our domains, update the API keys across all five backends, test delivery, and deploy.
Because we had built our email sending through a thin abstraction layer rather than calling the provider's API directly everywhere, the actual code changes were minimal. We updated the API key and endpoint in our environment variables, verified that the new provider accepted our domain's DNS records (SPF, DKIM, and DMARC were already properly configured from our original setup), and redeployed each backend service.
The entire migration took about four hours from discovery to full restoration. It could have been much worse. If we had hardcoded our email provider's SDK throughout the codebase instead of using a wrapper, we would have been rewriting email logic across five separate codebases under pressure.
Lesson 1: Always Validate Email Addresses Before Sending
This is the most basic rule we broke. Before sending any batch of emails, especially cold outreach, you need to verify that the addresses actually exist. There are email validation services that check MX records, detect disposable addresses, and identify addresses that are likely to bounce. They cost a few dollars per thousand addresses.
We now validate every email address before it enters any sending queue. For user-submitted emails (signups, contact forms), we verify the domain has valid MX records before accepting it. For outreach lists, we run the entire list through a validation service and remove anything that does not pass. A five-minute validation step would have prevented our entire crisis.
Lesson 2: Separate Transactional from Marketing Email
This was our biggest architectural mistake. Transactional emails (password resets, welcome messages, receipt confirmations) are critical infrastructure. They have open rates above 80% and near-zero bounce rates because they are sent to addresses that just performed an action on your site. Marketing emails (newsletters, outreach, promotional campaigns) have inherently higher bounce rates, lower engagement, and carry reputation risk.
These two types of email should never share the same sending account, the same domain, or ideally even the same provider. We now use one provider exclusively for transactional email and handle any marketing or outreach through a completely separate service with a different subdomain. If outreach goes wrong again, our transactional email keeps working.
Lesson 3: Implement Rate Limiting and Monitoring
We had no monitoring on our email sending. No alerts for bounce rate spikes. No daily limits on outbound volume. No dashboards showing delivery health. We were flying blind, and we did not even know it until the account was already dead.
Now we track bounce rate, delivery rate, and complaint rate in real time. We have alerts that fire if the bounce rate exceeds 2% on any given day. We have hard daily sending limits that cannot be overridden without a manual review. These guardrails exist specifically to prevent a repeat of what happened. If something starts going wrong, we know within hours, not after the provider has already pulled the plug.
Lesson 4: Have a Migration Plan Ready
The reason we survived this incident in four hours instead of four days is that we had (somewhat accidentally) built our email integration in a way that made switching providers easy. The API key and endpoint were environment variables. The email sending logic was behind an abstraction. Our DNS records were already configured correctly with SPF, DKIM, and DMARC.
We now treat email provider migration as a documented runbook. We know exactly which environment variables to update, which DNS records to verify, and which test emails to send to confirm delivery. We even have a backup provider account pre-configured and ready to activate. If our current provider goes down or bans us again tomorrow, we can switch in under an hour.
Lesson 5: Your Email Reputation Is Fragile
Email deliverability is not something most developers think about until it breaks. But your sending reputation -- which is tied to your domain, your IP address, and your provider account -- is one of the most fragile assets in your infrastructure. A single bad batch of emails can destroy months of built-up reputation in minutes.
Treat your email sending reputation the way you treat your production database: with extreme caution, proper monitoring, and a healthy fear of doing anything that might corrupt it. Never send emails to unvalidated addresses. Never mix marketing with transactional. Never skip the monitoring. Your users depend on receiving your emails, even if they do not think about it until they cannot.
The Silver Lining
Losing our email provider was one of the most stressful days we have had building this company. But it forced us to build better infrastructure than we had before. Our email setup is now more resilient, better monitored, and properly separated by purpose. We have a migration plan that we have actually tested. We validate every address before sending.
If you are building a SaaS product and you have not thought about what happens when your email provider disappears overnight, think about it now. Set up the monitoring. Separate your sending accounts. Validate your addresses. Build the abstraction layer. Do it while it is a calm Tuesday afternoon, not while your users are locked out of their accounts.
Built by Obsidian Clad Labs -- a group of friends from Tennessee building software that protects people.
tags: saas, startup, webdev, beginners
Originally published at TeachShield Blog
Built by Obsidian Clad Labs — a group of friends from Tennessee building software that protects people.