ParheliaWeb Email Validation API

Real-time email validation with transparent risk scoring.

Visit Website
July 16, 2026 I got tired of black-box email validation tools, so I built a transparent alternative

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!

4 Comments

  1. 2

    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.

    1. 1

      This is exactly the insight that shaped the product. Early on, I realized "valid/invalid" is the wrong question. The right question is: "Should I send to this address?"

      That's why we return risky and unknown as first-class statuses alongside valid and invalid. A Microsoft address that passes SMTP but comes from a provider known to lie? That's risky with an opaque_provider risk factor. A catch-all domain that accepts everything? That's risky with a catch_all_domain flag. A domain that blocks all probes? That's unknown.

      The confidence score isn't about how sure we are that the email exists, it's about how safe it is to send. An Outlook address with 250 OK gets a confidence of 50, not 90. The transparency isn't just more data, it's decision support.

      Really appreciate you putting this into words. This is the core thesis behind the product.

      1. 1

        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?

  2. 1

    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?

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.