I got tired of fake signups ruining my SaaS database, so I built a drop-in React component to stop them (Open Source)
Hey everyone,
I'm a developer based in Morocco. Because I work a full-time job, I strictly have about 2 hours a night to build my side projects. I don't have time to deal with bad data.
Every time I launch something, my database gets filled with users signing up using temp-mail.org, yopmail.com, or people just fat-fingering their emails (like [email protected] instead of [email protected]).
Standard regex passes all of these as "valid." This leads to high bounce rates, which eventually kills email deliverability for the whole app.
Instead of paying for an expensive enterprise API (my budget is exactly $0), I spent my weekend building my own edge-optimized validator using Cloudflare Workers and wrapped it in a drop-in React component.
It automatically:
- Blocks thousands of burner domains.
- Pings live DNS/MX records to ensure the domain actually exists.
- Catches typos and prompts the user: "Did you mean [email protected]?"
Since we all deal with this headache, I decided to open-source the React component. You can literally copy-paste it into your Next.js/React forms today.
🌐 Website: https://emailguard.lazrek.net
🔗 GitHub Repo & Code: https://github.com/yahyalazrek/react-smart-email-input
(Note: The backend is running on a serverless API I set up. The GitHub Readme has a link to grab a free API key with 100 requests/mo so you can make the component work instantly).
Would love some feedback from other founders on the code! How do you guys currently handle fake signups? Do you use double opt-in, or do you block them at the form level?
Really cool project, thanks for open‑sourcing this! The combo of blocking burner domains, DNS/MX checks, and typo suggestions is super practical for indie builders who can’t afford expensive APIs. I especially like that it’s Cloud flare Workers + a drop‑in React component, makes it easy to test quickly. I’m going to try this on my next form and will share any feedback once I’ve played with it
Thanks so much! That was exactly my goal, indie builders shouldn't have to pay enterprise prices just to keep their databases clean.
Because it's just a single React component calling the Cloudflare Worker API, you can literally drop it into your project in about 2 minutes.
Definitely let me know when you test it out! If you run into any weird edge-case domains or if you have ideas for improving the typo suggestions, just open an issue on the GitHub repo or drop a comment here.
What kind of project are you building the next form for?
Hey Yahya,
I do release risk consulting (help teams prevent production release failures), and this kind of edge-side validation is exactly the sort of thing that keeps launch-day issues from turning into deliverability nightmares.
I’m planning to try your component on an upcoming form, and if I spot any edge cases from a release/production perspective, I’ll share feedback or open an issue on GitHub.
Thanks, that means a lot coming from your line of work! I'd love for you to test it out. Definitely feel free to open an issue or drop me a message if you spot any edge cases.
Just launched my first waitlist today and honestly hadn't even thought about fake signups until I saw this. Really glad I came across it now before it becomes a problem. Great work open sourcing this!
Huge congrats on launching the waitlist! That is a massive milestone.
Honestly, waitlists are the absolute worst for fake signups. People constantly type [email protected] or burner emails just to see what happens after they click submit.
The real nightmare happens on Launch Day: if you finally email your waitlist and 30% of them bounce, providers like Resend or SendGrid will flag your domain as spam. Then, your real users never even see your launch email.
Drop the link to your waitlist here! I'd love to check it out and support the launch.
This is a great problem to solve. Fake and typo emails are such a small thing, but they can really mess up deliverability for early-stage products.
I’ve also seen the "gmil" and "gnail" typos surprisingly often when people sign up quickly.
The DNS/MX check is a clever approach, especially if you're trying to avoid relying on expensive validation APIs early on.
Curious about one thing: have you noticed any impact on signup friction when users get the typo suggestion prompt? Do most people correct the email or abandon the form?
That is the exact right question to ask. If a security tool kills your conversion rate, it's not worth using.
What I've found is that it actually increases the number of usable signups because of how the prompt is designed.
The Friction Strategy:
If it's a known burner domain or dead MX record, it's a hard block. We don't care if they abandon the form because they were never going to be a real customer anyway.
If it's a typo (gmil.com), we use a soft prompt. The React component doesn't delete their input; it just shows a small text link below: "Did you mean [email protected]? (Click to fix)".
Because it's a 1-click autocorrect (and it triggers onBlur before they even hit the submit button), the friction is near zero. Users actually appreciate it because it means they won't miss their confirmation email or password reset link!
Have you tried implementing any autocorrect on your current projects, or do you mostly just catch them after they bounce?
That makes a lot of sense. The hard block vs soft correction approach seems like a really good balance between protecting deliverability and keeping the signup flow smooth.
I haven't implemented autocorrect yet in my current projects. Usually I only notice the issue later when emails start bouncing or users never confirm their accounts, which is obviously not ideal.
The onBlur suggestion is a really nice touch though — it fixes the problem before it even becomes one.
Out of curiosity, did you build the typo detection logic yourself or are you using a predefined list of common email typos?
Exactly! Catching them at the bounce stage is too late, and by then, your sender reputation with SendGrid/Resend has already taken a hit.
To answer your question: It's actually a hybrid approach!
Instead of trying to maintain a massive, hardcoded list of every possible misspelling (which is impossible), I built it using a Levenshtein distance algorithm running on the edge.
The API takes the user's inputted domain and compares it against a small, clean array of the major providers (gmail.com, outlook.com, yahoo.com, icloud.com). If the Levenshtein distance is 2 or less meaning the user is off by 1 or 2 keystrokes (like gmil.com or yaho.com) the API instantly flags is_typo: true and returns the matched major provider as the suggestion.
It's incredibly fast and catches almost every fat-finger mistake without needing a bloated database of typos.
Since you are dealing with bounces right now, what frontend stack are you currently using? If you're on React/Next.js, you can literally just copy-paste the component from the GitHub repo today and stop the bleeding!
That’s a really elegant solution. Using Levenshtein distance against a small list of major providers is a clever way to keep it lightweight while still catching most real-world typos.
And yes, our frontend stack is actually Next.js, so your component should fit in perfectly. I’ll definitely check out the repo and try integrating it to see how it behaves in practice.
Really appreciate you sharing the technical details as well. It’s always great learning how other builders approach these kinds of problems.
That's awesome to hear you're on Next.js, it should literally take less than 5 minutes to drop into your signup flow.
Especially when you're building tools where users need to receive important updates (like CV matches or job alerts), catching those typos upfront is critical for the UX.
Definitely let me know how it behaves in practice for you! If you run into any friction at all grabbing the API key or integrating the component, feel free to reach out directly.
Good luck with the MVP, I'll be following your progress! 🚀
The MX record validation is the move that most people miss. Regex catches common typos only if you've explicitly listed that pattern, but an MX lookup catches ANY domain that doesn't exist or isn't configured to receive email — including disposable domains that rotate faster than any blocklist can track.
One thing worth adding to the open-source version: detection for role-based addresses like info, support, admin, and noreply prefixes. These are technically valid addresses but they almost never belong to a real individual decision-maker and tend to have terrible engagement rates. Many email marketing tools block these for exactly this reason.
The Cloudflare Workers approach is smart for latency. Running DNS lookups at the edge rather than a centralized API means you're not introducing a noticeable delay in the signup flow. What's your p99 validation latency looking like in practice? That's often the tradeoff that determines whether the UX stays smooth.
Just wanted to drop back in and say: Your idea was so good I actually just built and deployed it. The API now detects 'is_role_based' prefixes and adjusts the trust score automatically. Thanks again for the feature request, you officially contributed to the product roadmap! 🙌
Spot on! The fast-rotating burner domains are exactly why static blocklists aren't enough anymore. The MX lookup is the only real source of truth.
I love the idea of flagging role-based addresses (admin@, info@). That is a brilliant addition to the JSON trust-score payload. I am actually going to add that to my backlog for this weekend. Thank you for the feature idea!
Regarding latency: Because it runs on Cloudflare Workers, the edge execution itself is sub-10ms. The external DNS query (Cloudflare/Google) usually resolves in 50-150ms depending on the user's nearest edge node. To protect the UX, I built a strict AbortController timeout at 2.5s. If the upstream DNS hangs, it fails gracefully (424 Failed Dependency) and allows the signup so the user isn't blocked by our network hiccup.
What stack are you currently using to handle your form validations?
Builder-to-builder respect here — building open source and shipping consistently is its own kind of validation.
One thing I've noticed with fake signups: a lot of them come through automated prompt-based bots that exploit vague form constraints. The more specific your form validation rules are (clear constraints on what's accepted), the fewer bots get through — similar to how a well-structured AI prompt filters bad outputs.
I work in that space — built flompt, a visual prompt builder that structures AI inputs using 12 semantic blocks. Open-source too. Would love to compare notes on the open-source growth side.
A ⭐ on github.com/Nyrok/flompt would mean a lot — solo open-source founder here 🙏
Thanks Nyrok, builder-to-builder respect right back at you! 🙌
You are 100% right about the automated bots. They look for the path of least resistance. By putting a live DNS check directly on the onBlur event of the form, it acts like a brick wall for those low-effort scripts before they even touch the backend.
I just went over and dropped a ⭐ on Flompt. Visual prompt building is a massive need right now, looks like a great project.
As for OSS growth, I am literally just starting this journey (relying mostly on Dev.to and communities like this). What has been your highest-converting channel for GitHub stars so far?
went a completely different direction on mine — passwordless OTP auth so I never have to deal with email validation at all. but that only works if you don't need email as a channel. for products where you actually email users, this kind of validation is way more practical than paying for an enterprise API. the DNS/MX check is the part most people skip and it's probably the most important one
Passwordless OTP is such a smooth UX! But you hit the nail on the head, it completely depends on whether you need to actually talk to your users later. For SaaS onboarding sequences, billing alerts, and churn recovery, email is still king.
There is also one hidden nightmare with email-based OTP that I built this to solve: The Magic Link Bounce.
If a user is trying to log in and accidentally types [email protected], the OTP email bounces. The user sits there refreshing their inbox thinking your app is broken, and they eventually abandon it. By running the Levenshtein typo-check on the frontend before firing the OTP request, it catches that friction point instantly!
I really appreciate the shoutout on the MX check. It took some tweaking to get the latency down on Cloudflare Workers, but it's the only real source of truth.
What auth provider are you using for your OTP setup? Supabase? Clerk? Or did you roll your own?