Case study · Email validation API · Worldwide
VeriMailTwo people run an email validation API with 1M+ checks a day and 99.99% uptime, and no ops team
VeriMail is a real-time email validation API that stops sign-ups with disposable and invalid addresses before they reach a customer's database. Many companies check every email through it, more than 1 million checks a day, so for them it is critical infrastructure. I designed the architecture and keep improving it, and I built in the fault tolerance and the backups. That is why one engineer and I run the whole service on 2 to 3 servers, at 99.99% actual uptime against a 99.9% SLA and with p99 latency under 200 ms, with no operations team, where infrastructure this critical usually needs one.
- Client
- VeriMail
- Product
- Real-time email validation API
- Customers
- Businesses that check every sign-up through it
- My role
- Fractional CTO
- Team
- 1 engineer and me
- Load
- 1M+ checks a day on 2 to 3 servers
- Uptime
- 99.99% actual against a 99.9% SLA
- Website
- verimail.co

In numbers
- actual uptime against a 99.9% SLA, with two people and no ops team
- 99.99%
- email checks a day from businesses that put every sign-up through it
- 1M+
- average, p99 under 200 ms: fast enough to check as users type
- ~100 ms
- servers carry the whole load, so the service stays cheap to run
- 2–3
- emails validated before they reached a customer's database
- 50M+
- developers build on the API
- 10K+
The product
Validation while the user types, every check a sign-up needs, and a REST API that answers in about 100 ms. Images from verimail.co.
The starting point
Disposable and fake email addresses fill a product's database with sign-ups that never convert. They burn marketing money and damage the sender's reputation. VeriMail catches them on the sign-up form, before they get in.
Many businesses put VeriMail in front of every sign-up and checkout, so if it slows down or goes down, their sign-ups stop. That makes it critical infrastructure, and it has to hold heavy load and a strict SLA every minute of every day.
What we did
The architecture is mine
I designed the architecture of the whole service and keep improving it: the validation pipeline, the API and the infrastructure under them. It is built so two people can run it and 2 to 3 servers carry the whole load of more than 1 million checks a day, and that keeps the cost of running the service low.
About 100 ms on average, p99 under 200 ms
Under heavy load the system still answers in about 100 ms on average, and 99% of requests get their answer in under 200 ms. That is fast enough to validate an email while the user is still typing it, so customers add the check to their forms without slowing sign-up down.
99.99% uptime against a 99.9% SLA
Customers rely on VeriMail to check every sign-up, so the service runs to a 99.9% uptime SLA and actually delivers 99.99%, a level usually held by companies with a dedicated reliability team.
Fault tolerance and backups
I built fault tolerance into every layer and set up the backups, so a failure never stops a customer's sign-ups.
Every check a sign-up needs
Each email goes through RFC syntax, MX records over DNS-over-HTTPS, a database of more than 200,000 disposable domains, blocklists of spam traps and honeypots, and role-account detection, and comes back with a score. Customers can check one address or a whole list in bulk, and bad addresses never reach their database or their marketing budget.
Two people, no ops team
One engineer and I run the whole service, on modern technology throughout. A service that handles more than 1 million checks a day at this SLA usually needs a team of its own just to keep it up.
The result
More than 10,000 developers build on this API and it handles more than 1 million checks a day. It delivers 99.99% uptime against a 99.9% SLA with p99 latency under 200 ms, and two people run it on 2 to 3 servers, where infrastructure this critical usually needs a whole operations team.
Full case · PDF
VeriMail
Two people run an email validation API with 1M+ checks a day and 99.99% uptime, and no ops team
- 01The architecture of the service
- 02How it holds heavy load at about 100 ms
- 03Fault tolerance and backups
- 04The disposable-domain database and how it stays current
- 05Running to a 99.9% SLA with two people
- 06The stack, and why we chose it
The full VeriMail case
The public story stops here. The PDF has the rest: the architecture before and after, the migration plan, how the team works with AI agents, what it all costs to run and where the savings came from.
More case studies
All case studiesWant the next case study to be about your company?
In a 30-minute call we pick the first task to hand to AI and estimate what it will save you.


