(journey)My Journey From Email Operations to AI-Powered SaaS

syphaxmail

Power Member
Joined
Oct 26, 2013
Messages
679
Reaction score
230
After spending years helping businesses with email infrastructure, deliverability, and email list cleaning, I started noticing the same pattern everywhere.

Most companies relied on expensive SaaS platforms that performed SMTP verification on every email in a list. While the results were useful, the costs increased significantly as databases grew larger.

The more I worked with email data, the more I realized that not every email needs SMTP verification.

A large percentage of bad records can be identified much earlier through duplicate detection, invalid syntax checks, role-based email identification, disposable email detection, and other AI-assisted analysis techniques.

If those records are removed first, only the remaining emails need SMTP verification to determine whether the mailbox actually exists.

This simple idea can dramatically reduce verification costs while still maintaining list quality.

Being a technical person, I kept asking myself: "Why isn't this the default approach?"

That question led me to start building my own SaaS platform—one that combines traditional email hygiene, AI-powered cleaning, and SMTP verification only where it adds real value.

The journey has been exciting, frustrating, and educational at the same time. Building the product was one challenge; getting users and validating the market has been an entirely different one.

After 15 years in tech, I'm still learning that solving a real business problem is often more important than building sophisticated technology.

Still a long way to go, but I'm excited about the journey ahead.

Wish me luck, and I wish all of you success in your own ventures as well.
 
Is this going to be some kind of WordPress - website plugin?
I mean your software - site gets the email someway and it will do the verification with different kind way than force a newsletter subscriber or user to clicking the link at email to get verified?
 
Not exactly.

The initial goal is to provide email list cleaning and verification for existing databases rather than replacing double opt-in or newsletter confirmation workflows.

The idea is that many records can be identified before expensive mailbox verification is even needed. For example:

  • Duplicate emails
  • Invalid syntax and formatting issues
  • Disposable email addresses
  • Role-based emails (info@, support@, sales@, etc.)
  • Potentially risky or low-quality records
These checks can be performed using rules, reference datasets, and AI-assisted analysis.

After that filtering stage, SMTP verification can be used only on the remaining records to determine whether the mailbox actually exists. This reduces the number of SMTP checks required and can significantly lower verification costs.

As for integrations, I'm considering APIs, CSV uploads, and potentially WordPress/CRM integrations later if users find them useful.
 
Very good idea!
It´s possible, that someone will buy your full product at some price and will copy that system to their SMTP system.
Be ready for that kind of possibility. I mean, buy everything from you.
 
Thank you!

Honestly, if larger companies eventually copy the idea, I'll take that as validation that we're solving a real problem.

Right now, I'm focused on building, gathering feedback, and improving the product. One step at a time.
 
I have built and deployed 3 complete end to end email validation systems and what you describe is what I have implemented every single time.

As a matter of fact, they were not even my core idea initially, but something very explicitly included in the documentation.

What you're saying here has a technical name - Waterfall.

And it's an industry standard in any form of data validation, not just email lists.

You ALWAYS get the low risk, cost-effective runs out of the way first.

Most top validation engines do exactly that. They're not running full-scales SMTP validation on garbage.

Stage one is typically running deduplication, syntax validation, simple regex fixes/checking for malformed domains.

Stage two is local database scans - fltering out known temp mail domains, filtering out against locally downloaded spam trap databases, identified role based emails (info@, admin@ etc.)

There's an actively maintained tempmail distribution list here - https://github.com/disposable-email-domains/disposable-email-domains

Then comes, domain and DNS verification to check for valid MX servers, or MX servers of known disposable providers

And then what's left goes through the SMTP Handshake and Connection severing + catchall detection

//

What you're selling here is not the cost of SMTP. You're selling your computer power to run complex regex patterns and filtering against already known databases.

It works flawlessly right now, but once you have 10 users logged in together in your multi tenancy app, each uploading a 20k+ list to validate, your VPS will choke.

So your cost doesn't comedown because you're running SMTP validation at a later stage. It's only a part of a process and not the most expensive part either.
 
Thank you for the detailed response. I completely agree that the waterfall approach isn't new and has been an industry standard for years.

The goal isn't to reinvent validation but to make the workflow more accessible and flexible for different users.

A couple of points worth mentioning:

  • The platform supports both SaaS and self-hosted deployments, so users can choose based on their scale and privacy requirements.
  • Currently I'm not focusing on catch-all detection. The SMTP layer primarily uses HELO and related server signals to build confidence scores rather than aggressively probing mailboxes.
  • In a previous role I was involved in processing and cleaning email databases at a scale of over 1 million emails per day, so scalability and resource usage have been areas I've spent quite a bit of time thinking about.
Appreciate you sharing your experience. Feedback like this is exactly why I started the discussion in the first place.
 
I would've engaged with you more, had you not resorted to using AI slop to respond to what was clearly a response that took some effort at my end. Your AI clearly loves shifting goalposts.

HELO is already taken care of in the DNS/Domain check. It validates the gateway and nothing else. Without a clear RCPT TO market, your confidence score means nothing, it's just guess work. So you'll essentially be charging your users for a glorified MX lookup.

But sure you do you.
 
The tech itself is pretty standard yeah, but the product can still win if the workflow/pricing is nicer than the big tools. Most clients dont care if it’s called waterfall or whatever, they care that their 80k csv doesnt cost stupid money and the report is easy to act on.

That said the “AI cleaning” angle is where I’d be careful. If the SMTP part is light and there’s no RCPT check, you need to be very clear what score means, otherwise people will expect mailbox-level validation and complain when bounces still happen. Better to sell it as hygiene + risk scoring first, verification second imo.
 
I think there's room for both views here. The validation pipeline itself isn't new, but that doesn't mean there isn't an opportunity to package it differently or target a whole different market. Most users don't care if the backend is doing something which is called "waterfall" or something else... they care about cost and if they get their problem solved by it. That's where the differentiation happens.
 
The tech itself is pretty standard yeah, but the product can still win if the workflow/pricing is nicer than the big tools. Most clients dont care if it’s called waterfall or whatever, they care that their 80k csv doesnt cost stupid money and the report is easy to act on.
That said the “AI cleaning” angle is where I’d be careful. If the SMTP part is light and there’s no RCPT check, you need to be very clear what score means, otherwise people will expect mailbox-level validation and complain when bounces still happen. Better to sell it as hygiene + risk scoring first, verification second imo.
Thanks for your feedback. This has been exactly my finding after running campaigns for clients for almost 15 years. Most clients don't really bother about waterfall or any other logic; they care more about cost, deliverability, and results.

I have integrated Gmail App Passwords, email API integrations, and AWS SES. All SMTP setups can have rotation, and users can configure per-hour limits, per-day limits, as well as percentage-based distribution for specific campaigns.

If a user has 50 Gmail App Passwords, for example, they can set a limit of 200 (Although aged accounts can send upto 400 emails per day)emails per day per account and run validations at scale.

I am reading the RCPT responses and recording them, and users can review the results directly from the dashboard.
 
Yep, that’s the right stack order. smtp last, otherwise you’re burning money on garbage.
 
I have built and deployed 3 complete end to end email validation systems and what you describe is what I have implemented every single time.

As a matter of fact, they were not even my core idea initially, but something very explicitly included in the documentation.

What you're saying here has a technical name - Waterfall.

And it's an industry standard in any form of data validation, not just email lists.

You ALWAYS get the low risk, cost-effective runs out of the way first.

Most top validation engines do exactly that. They're not running full-scales SMTP validation on garbage.

Stage one is typically running deduplication, syntax validation, simple regex fixes/checking for malformed domains.

Stage two is local database scans - fltering out known temp mail domains, filtering out against locally downloaded spam trap databases, identified role based emails (info@, admin@ etc.)

There's an actively maintained tempmail distribution list here - https://github.com/disposable-email-domains/disposable-email-domains

Then comes, domain and DNS verification to check for valid MX servers, or MX servers of known disposable providers

And then what's left goes through the SMTP Handshake and Connection severing + catchall detection

//

What you're selling here is not the cost of SMTP. You're selling your computer power to run complex regex patterns and filtering against already known databases.

It works flawlessly right now, but once you have 10 users logged in together in your multi tenancy app, each uploading a 20k+ list to validate, your VPS will choke.

So your cost doesn't comedown because you're running SMTP validation at a later stage. It's only a part of a process and not the most expensive part either.


Everything you said about email validation is correct. However, any serious email validation platform that relies on GitHub maintained disposable email domain lists will inevitably fail to detect thousands of temporary email domains.

The demand for temporary email services continues to grow, with new providers launching almost every day to serve privacy conscious users and those looking to bypass signup restrictions. Unfortunately, community maintained GitHub lists typically covers well known providers. As a result, many disposable email addresses are able to bypass validation.

In my experience, even many of the leading email validation platforms rely on precompiled disposable domain lists rather than maintaining their own dedicated disposable email detection systems. This significantly limits their ability to detect newly launched providers.

I work with clients to improve email quality and deliverability, and one of the most effective ways I've found to reduce bounce rates and prevent abuse is to block disposable email addresses before, or alongside, the standard email validation process using a dedicated disposable email detection API.

While dedicated disposable email detection services generally perform much better than traditional email validation platforms in detecting temp mails, they still have one major limitation they are often slow to identify new providers. Many temporary email services remain undetected for months despite being actively used.

Because the demand for temporary email services is so high, new providers appear almost daily. To address this problem, I developed my own detection platform. Instead of relying on static lists, I built a system that continuously discovers new providers as they become indexed by search engines. Once a provider is identified, it is added to an automated monitoring system that runs 24/7. Whenever a new domain is discovered from that provider, my platform database is updated automatically, ensuring detection remains accurate and up to date.

I wrote about the weaknesses of disposable email detection in this thread:
https://www.blackhatworld.com/seo/h...-online-services-vulnerable-to-abuse.1834352/

You can also check a few of these providers yourself. During my most recent testing a few weeks ago, they were still not detected by many email validation systems. If you'd like more examples, feel free to send me a private message and I'll share alot more providers so you can test them yourself.

Code:
temp-mail.abhi.at
tempmailq.com
mail.aitre.cc
temp-mail.co
tembox.xyz
disposableemailgenerator.com
wetempmail.com
30mintempmail.com
inboxflip.com
theburnermail.com
inboxnow.eu
tmpkit.com
burneremail24.com
temp-emailbox.com
tempmail0.com
tempmy.com
inboxphantom.com
24hrtempmail.com
tempmail.ninja
mails.org

Use the email addresses generated from the temporary email providers listed above and test them against the email validation services listed below. Compare the results and see for yourself.
Code:
https://debounce.com/free-disposable-check-api/

https://emailverification.whoisxmlapi.com/disposable-email-checker

https://mailtester.com/

https://hunter.io/verify

https://www.zerobounce.net/
 
Last edited:
Everything you said about email validation is correct. However, any serious email validation platform that relies on GitHub maintained disposable email domain lists will inevitably fail to detect thousands of temporary email domains.

The demand for temporary email services continues to grow, with new providers launching almost every day to serve privacy conscious users and those looking to bypass signup restrictions. Unfortunately, community maintained GitHub lists typically covers well known providers. As a result, many disposable email addresses are able to bypass validation.

In my experience, even many of the leading email validation platforms rely on precompiled disposable domain lists rather than maintaining their own dedicated disposable email detection systems. This significantly limits their ability to detect newly launched providers.

I work with clients to improve email quality and deliverability, and one of the most effective ways I've found to reduce bounce rates and prevent abuse is to block disposable email addresses before, or alongside, the standard email validation process using a dedicated disposable email detection API.

While dedicated disposable email detection services generally perform much better than traditional email validation platforms in detecting temp mails, they still have one major limitation they are often slow to identify new providers. Many temporary email services remain undetected for months despite being actively used.

Because the demand for temporary email services is so high, new providers appear almost daily. To address this problem, I developed my own detection platform. Instead of relying on static lists, I built a system that continuously discovers new providers as they become indexed by search engines. Once a provider is identified, it is added to an automated monitoring system that runs 24/7. Whenever a new domain is discovered from that provider, my platform database is updated automatically, ensuring detection remains accurate and up to date.

I wrote about the weaknesses of disposable email detection in this thread:
https://www.blackhatworld.com/seo/h...-online-services-vulnerable-to-abuse.1834352/

You can also check a few of these providers yourself. During my most recent testing a few weeks ago, they were still not detected by many email validation systems. If you'd like more examples, feel free to send me a private message and I'll share alot more providers so you can test them yourself.

Code:
temp-mail.abhi.at
tempmailq.com
mail.aitre.cc
temp-mail.co
tembox.xyz
disposableemailgenerator.com
wetempmail.com
30mintempmail.com
inboxflip.com
theburnermail.com
inboxnow.eu
tmpkit.com
burneremail24.com
temp-emailbox.com
tempmail0.com
tempmy.com
inboxphantom.com
24hrtempmail.com
tempmail.ninja
mails.org

Use the email addresses generated from the temporary email providers listed above and test them against the email validation services listed below. Compare the results and see for yourself.
Code:
https://debounce.com/free-disposable-check-api/

https://emailverification.whoisxmlapi.com/disposable-email-checker

https://mailtester.com/

https://hunter.io/verify

https://www.zerobounce.net/

LOL

Part of me just wishes I'd never looked into this in the first place! It's a real rabbit hole...

From that list I'm guessing the most effective means of list cleaning is to build our own cleaner, as it's always going to be impossible to keep up with the lists and lists of burner domains if we use a paid service. Unless we know for sure that the service in question always keeps their lists up-to-date.

I love what OP is attempting, this looks like a real challenge.
 
Back
Top