“Did you get my form submission?”

I checked. No form submission. No email. Nothing in spam. Just… nothing. “Let me try again.” They submitted the form again. Right in front of me on a Zoom call. Form said “Success!” Email never arrived. That’s when I learned that email delivery is way more fragile than anyone admits.

The Silent Failures

Email fails silently. That’s the terrifying part. When a form submission fails to save to a database, you get an error. When an API call fails, you get an error. When email fails? Nothing. No error. No warning. Just silence.

The SMTP server says “OK, I’ll deliver that.” Then it doesn’t. Or it does, but the recipient’s mail server rejects it. Or it accepts it, then puts it in spam. Or quarantines it. Or just drops it. And you have no idea any of this happened.

I spent a week debugging email delivery. Here’s what I found: about 2% of emails just vanish. They leave your server fine. They never arrive. No bounce. No error. Gone. Another 5% end up in spam folders. Even perfectly formatted, legitimate notification emails. Because spam filters are paranoid and err on the side of blocking. Another 1% get “greylisted” by the recipient’s server. Temporarily rejected to see if the sender will retry. If you don’t retry, the email is lost. So out of every 100 form submissions, roughly 8 people never get their notifications. Not because of bugs. Because email is fundamentally unreliable.

The Day My Email Service Went Down

I was using a third-party email service. Great service. 99.9% uptime. Until the day it wasn’t. The service had an outage. Three hours. During those three hours, my form got 47 submissions. Forty-seven people filled out my form, submitted it, and got a “Success!” message. Zero emails were sent.

I didn’t find out until the next day when someone called me: “I filled out your form yesterday. Did you see it?” I had to admit that no, I didn’t see it. Because my email service was down and I had no fallback. The submission data was in the database, but I hadn’t checked the database. I was waiting for email notifications that never came.

I manually sent emails to all 47 people. “Sorry for the delay.” Some had already moved on. One had chosen a competitor. That outage cost me actual money.

Rate Limits: The Hidden Killer

Free tiers have rate limits. Duh. Everyone knows this. What I didn’t realize is how easy it is to hit rate limits. Free tiers often limit you to 100 emails per day. Sounds like plenty for a contact form. Until you launch on Product Hunt and get 150 form submissions in one day.

The first 100 people got notifications. The other 50? Nothing. The form still worked. Submissions were still saved. But I didn’t know about them until I checked the dashboard 12 hours later. By then, those leads were cold. “Thanks for your submission yesterday.” Yeah, real timely response.

I upgraded to a paid plan. Problem solved, right? Except paid plans also have rate limits. They’re just higher. And if you ever hit them, same problem. Silent failures.

SMTP Is A Lie

SMTP (the protocol email uses) gives you three responses: 250 (email accepted), 4xx (temporary failure, retry later), and 5xx (permanent failure, don’t retry). In theory, this is great. You know immediately if the email was delivered, temporarily failed, or permanently failed.

In practice, every mail server lies. They say “250 OK” even if they’re going to put it in spam. They say “250 OK” even if they’re going to greylist it. They say “250 OK” even if they’re going to drop it entirely. Why? Because telling senders the truth helps spammers. If a mail server said “5xx User doesn’t exist,” spammers would know the email is invalid. So servers lie. They accept everything and handle it internally.

This makes SMTP nearly useless for determining actual delivery. The server said OK? Doesn’t mean the user got it.

What Reliable Email Looks Like

After dealing with all this, I finally understood what reliable email delivery actually requires: retry logic with exponential backoff (if sending fails, wait 2 seconds and try again, then 4 seconds, then 8 seconds, keep trying for at least an hour), a queue system so emails are never sent synchronously (form submits, submission is saved immediately, email goes into a queue, if email fails, submission is still saved), monitoring and alerting (track delivery rates, if success rate drops, get alerted immediately, don’t wait for users to tell you), and backup storage for every email sent (when debugging “I didn’t get your email,” you need logs: what was sent, when, to whom, what was the response).

This is not simple. This is a whole infrastructure project.

Why I Built StaticForm

Building reliable email delivery took me two weeks. Maintaining it took ongoing effort. Debugging failures consumed hours. And it still failed sometimes. Because email is fundamentally unreliable and there’s only so much you can do.

So I built StaticForm to solve this in a way I never could alone. StaticForm uses reliable AWS infrastructure for email delivery, with retry logic, built-in monitoring, and automatic queuing. If email fails, StaticForm keeps retrying. The AWS infrastructure is much more reliable than managing your own email service.

More importantly, submissions are always saved. Even if email delivery temporarily fails, the submission is in StaticForm’s database. You can see it. You can export it. It’s not lost. Since building StaticForm, I haven’t lost a single submission to email failures. Not one. StaticForm’s delivery rate is over 99.9%, and the 0.1% that temporarily fail are retried until they succeed.

I don’t wake up to “Why didn’t you respond to my submission?” messages anymore. I don’t debug SMTP failures. I don’t monitor delivery rates. Email just works. Finally.

Get 10 free credits to test your form at app.staticform.app. Pay as you go, or buy a plan to save money.