
ParheliaWeb Email Validation API
Real-time email validation with transparent risk scoring.
Hey everyone,
I’m a solo founder based in the Netherlands, and I recently hit a wall with existing email validation tools. They were either too expensive, or they were "black boxes" that just spat out "valid" or "invalid" with zero context.
As any developer knows, Microsoft’s SMTP servers will accept almost anything during a handshake to prevent directory harvesting, while Gmail silently throttles you. A simple "valid" boolean doesn't protect your sender reputation when a catch-all domain bounces a week later.
So, building on some prior experience, I started working on a new project in May 2026: the ParheliaWeb Email Validation API.
Instead of guessing, it provides transparent, real-time SMTP verification with clear risk scoring.
Key things I focused on:
→ Real SMTP mailbox probing (no emails actually sent)
→ Catch-all domain detection
→ Transparent risk factors (e.g., explicitly telling you "Microsoft accepts everything, so we can't guarantee delivery" instead of faking a "valid" status)
→ Clean, developer-first JSON responses
I just published the product page here on Indie Hackers. It’s built for developers who want to protect their domain reputation without the black-box guesswork.
We have a generous free tier (100 checks/month) so you can test the transparency yourself.
I’d love to get some feedback from fellow builders here: What’s the biggest pain point you’ve faced with email deliverability or validation?
Check out the developer documentation and pricing here: https://parheliaweb.com/docs-email
Thanks for reading!
About
Building on years of prior experience, I started this in May 2026 to replace brittle scrapers and black-box tools with transparent, real-time SMTP verification and clear risk scoring.

4 Comments
I think the biggest strategic question isn't validation accuracy—it's decision usefulness. Most teams don't actually care whether an address is technically "valid"; they care whether sending to it is worth the risk. If your transparency consistently helps people make better send/don't-send decisions rather than just returning more diagnostics, that's a much stronger position than competing on validation accuracy alone.
Appreciate the context.
The shift from validation to decision support is the interesting part here.
Would be good to understand more about how you're seeing users apply those decisions in practice.
What's the best email to reach you on?
Email validation is the kind of API that customers quickly depend on for production workflows.
How are you planning to communicate service incidents, maintenance, or changes to validation logic and risk scoring? Are you using email, release notes, or a public changelog and status page?