An email-verification SaaS for clean, deliverable lists.
A platform that validates email lists, syntax, domain, and quality scoring, so campaigns reach real inboxes and sender reputation stays intact.
Visit Mail Avail ↗By the CapregSoft Engineering Team ·
The outcome.
verification accuracy across layered checks
batch processing for large lists
polyglot storage, each used where it fits
deliverability on cleaned lists
Figures shown are engineering targets and typical outcomes for work of this type, not audited per-client results. We'll share verified numbers for your specific context on a discovery call.
Key takeaways.
How CapregSoft approached Mail Avail — the short version.
- Layered checks, syntax, domain/MX, SMTP probing, plus disposable, role-based, and catch-all detection, yield a confidence score, not a blunt pass/fail.
- Polyglot persistence: SQL for the transactional core, NoSQL for high-volume verification results and flexible metadata.
- Go concurrency plus cached domain lookups keep large-list verification both fast and accurate.
Where it hurt.
Teams were sending to dirty lists, dragging down deliverability and damaging sender reputation, a cost that compounds with every send.
Verification had to be both fast and accurate across large lists, which is a genuine engineering tension: naive accuracy is slow, and naive speed is wrong.
What we did.
Built layered validation, syntax checks, domain and MX verification, SMTP mailbox probing, plus disposable, role-based, and catch-all detection, so each address gets a confidence rating, not just a pass/fail.
Engineered batch processing in Go so large lists verify concurrently instead of one address at a time, keeping turnaround fast at scale.
Used polyglot persistence, a SQL database for relational, transactional data and a NoSQL store for high-volume verification results and flexible per-check metadata, so each kind of data lives where it performs best.
Cached domain and MX lookups so repeated checks against the same domains don't re-pay the network cost, sharply cutting verification time on real-world lists.
Designed a clean export and API flow so verified results drop straight into the customer's existing campaign tooling.
How it actually came together.
The speed-vs-accuracy tension
Email verification looks simple until you scale it. Checking one address well means validating syntax, confirming the domain exists and accepts mail, and scoring how likely it is to be a real, active inbox. Doing that thoroughly is slow; doing it fast usually means cutting corners that produce false results, and a false 'valid' is worse than no answer at all.
We resolved the tension with concurrency rather than shortcuts. Go processes a large list as many addresses in parallel, each going through the full layered check, so accuracy stays high while total turnaround stays fast. The result is a confidence score per address, which is far more useful to a marketer than a blunt pass/fail.
Inside the verification pipeline
A single address runs a gauntlet, not one test. Syntax validation rejects malformed addresses cheaply up front. Domain and MX checks confirm the domain actually exists and is configured to receive mail. SMTP probing goes a step further, opening a conversation with the receiving mail server to gauge whether the specific mailbox would accept a message, without ever sending one.
On top of that sit the judgment checks that separate a serious verifier from a regex: disposable-domain detection (throwaway inboxes that bounce or churn), role-based detection (info@, support@ addresses that hurt engagement metrics), and catch-all detection (domains that accept everything, where a 'valid' result is genuinely uncertain). Each address ends with a confidence score and a reason, so the marketer can decide how aggressively to clean.
SQL and NoSQL, each where it earns its place
Mail Avail's data isn't one shape, so it isn't one database. We used polyglot persistence: a relational SQL database for the structured, transactional core, accounts, billing, jobs, and the relationships between them, where consistency and joins matter, and a NoSQL store for the high-volume verification results and the flexible per-check metadata, where write throughput and a schema that can evolve per check matter more than relational guarantees.
The payoff is that neither side is forced into a model it's bad at. The relational store stays clean and consistent for the parts of the product that bill and authenticate; the NoSQL store absorbs millions of result records and varied metadata without schema migrations every time a new check is added. Redis sits across both as a cache for hot domain and MX lookups so repeated checks stay fast.
Built to fit existing workflows
Verification only matters if the clean list actually gets used. We designed the export and API so results flow straight back into the customer's campaign tools, making the platform a step in an existing workflow rather than a detour out of it.
What powered it.
This was a High-Performance Backends engagement.
Questions teams ask before they call.
How does email verification improve deliverability?
Sending to invalid or low-quality addresses raises bounce rates and spam complaints, which mailbox providers use to lower your sender reputation, so even your good emails land in spam. Removing bad addresses before you send protects that reputation and keeps more of your campaign reaching real inboxes.
Why use both SQL and NoSQL in one platform?
Different data has different needs. The transactional core, accounts, billing, jobs, benefits from a relational SQL database's consistency and joins. The high-volume verification results and flexible per-check metadata benefit from a NoSQL store's write throughput and evolvable schema. Polyglot persistence lets each kind of data live where it performs best instead of forcing everything into one model.
What checks does the platform run on each address?
Syntax validation, domain and MX verification, SMTP mailbox probing, and judgment checks for disposable domains, role-based addresses, and catch-all servers. Each address ends with a confidence score and a reason rather than a blunt pass/fail.
Why does verification speed require concurrency?
A thorough check per address involves network calls (domain, MX, and SMTP lookups) that take time. Processing a large list one address at a time would be unacceptably slow, so the work is parallelized, Go's concurrency model lets many addresses be verified at once while keeping resource use predictable, and cached domain lookups avoid re-paying the network cost.