DEV Community: nProejct

How I Built an Explainable Signup Email Risk Checker with Node.js

nProejct — Thu, 10 Sep 2026 12:58:31 +0000

A valid-looking email address is not always a trustworthy signup.

Basic email validation usually answers only one question:

Does this string look like an email address?

That is useful, but it does not tell us whether the address uses a disposable domain, whether the domain can receive mail, or whether the result is reliable enough to accept automatically.

I wanted a small server-side check that returns an explainable decision instead of a simple true or false.

Why a Boolean Result Is Not Enough

Consider these cases:

The email syntax is invalid.
The domain is a known disposable email provider.
The domain has no MX records.
The address appears to be a role account such as admin@ or support@.
The domain looks like a typo of a common provider.
A DNS request temporarily fails.

These situations should not all produce the same result.

A temporary DNS failure, for example, should not automatically cause a legitimate customer to be rejected.

For that reason, I use four decisions:

Decision	Recommended action
`ACCEPT`	Allow the signup to continue
`REVIEW`	Require additional verification
`REJECT`	Block because strong risk evidence was found
`UNKNOWN`	Retry later or use a fallback flow

The important part is that UNKNOWN remains separate from REJECT.

Signals Used for the Decision

The checker evaluates several signals together:

Email syntax
Disposable email domain evidence
MX mail-routing records
Free email provider detection
Role-based local parts
Common domain typo suggestions
Confidence and risk level

No single weak signal should decide the entire result.

For example, a role address such as support@example.com may be undesirable for a consumer signup but completely normal for a B2B contact form.

The final policy depends on the application.

Calling the API with Node.js

The following example requires Node.js 18 or later because it uses the built-in fetch function.

Create a file named check-email.mjs:

const email = process.argv[2];
const apiKey = process.env.RAPIDAPI_KEY;
const host =
  "riskbeacon-signup-email-domain-intelligence-api.p.rapidapi.com";

if (!email || !apiKey) {
  console.error(
    "Usage: RAPIDAPI_KEY=your_key node check-email.mjs user@example.com"
  );
  process.exit(1);
}

const response = await fetch(`https://${host}/email/v1/verify`, {
  method: "POST",
  headers: {
    "content-type": "application/json",
    "x-rapidapi-key": apiKey,
    "x-rapidapi-host": host
  },
  body: JSON.stringify({
    email,
    profile: "SIGNUP_BALANCED"
  })
});

const result = await response.json();

if (!response.ok) {
  console.error(`Request failed: ${response.status}`, result);
  process.exit(1);
}

console.log(JSON.stringify({
  decision: result.decision,
  confidence: result.confidence,
  riskLevel: result.riskLevel,
  disposable: result.disposable,
  roleAccount: result.roleAccount,
  reason: result.reason
}, null, 2));

Set your RapidAPI key and run the script.

macOS or Linux

RAPIDAPI_KEY="YOUR_RAPIDAPI_KEY" \
node check-email.mjs "new.user@gmail.com"

Windows PowerShell

$env:RAPIDAPI_KEY = "YOUR_RAPIDAPI_KEY"
node .\check-email.mjs "new.user@gmail.com"

A simplified result looks like this:

{
  "decision": "ACCEPT",
  "confidence": 90,
  "riskLevel": "LOW",
  "disposable": false,
  "roleAccount": false,
  "reason": "Email passed the selected validation policy"
}

Using the Decision in a Signup Flow

A simple application policy might look like this:

switch (result.decision) {
  case "ACCEPT":
    // Continue the normal signup flow.
    break;

  case "REVIEW":
    // Require an email OTP, magic link, or CAPTCHA.
    break;

  case "REJECT":
    // Stop the signup and show a neutral error message.
    break;

  case "UNKNOWN":
    // Retry later or use the normal email verification flow.
    break;
}

This lets the application add friction only when the available evidence justifies it.

What This Check Does Not Prove

An MX record proves that a domain is configured to receive mail. It does not prove that a specific mailbox exists.

This checker intentionally does not perform SMTP mailbox probing. SMTP probing can be unreliable, may expose user information, and is often blocked or intentionally obscured by mail providers.

The result should therefore be used as a risk signal before signup, not as a replacement for:

Email ownership verification
OTP or magic-link confirmation
Rate limiting
CAPTCHA
Device and IP abuse detection

Privacy Considerations

The verification service does not persist submitted email addresses.

Applications should still avoid logging full email addresses unnecessarily. If logging is required, consider masking the local part or storing a one-way hash.

Try the Example

I published the complete Node.js example under the MIT license:

GitHub: Signup Email Risk Checker

The underlying email and domain intelligence API is available here:

RiskBeacon on RapidAPI

Disclosure: I built both the example project and the RiskBeacon API. I would appreciate feedback about the response structure, decision model, and signals that would be most useful in a real signup flow.

How to Block Disposable Emails and Fake Signups in Node.js & Python

nProejct — Tue, 01 Sep 2026 14:52:09 +0000

If you offer free trials or starter credits on your SaaS, you've probably seen users abuse temporary emails to reset their limits endlessly.

The Problem with Static Lists

Most developers start with static disposable domain lists. However, new throwaway domains pop up every single day, making static blocklists outdated within weeks.

A Better Approach: Multi-Factor Risk Scoring

Instead of a simple black/white list, checking multiple domain signals at signup provides much better protection:

MX Record Validity: Ensures the domain can actually receive mail.
Domain Age: Identifies freshly registered throwaway domains.
Disposable Patterns: Matches heuristic fingerprints of temporary mail services.

Open-Source Starter Repo

I packaged this logic into a lightweight wrapper and published sample code for Node.js and Python.

Check out the full repository and implementation examples here:
👉 signup-email-risk-checker on GitHub

Feel free to star or fork the project if you find it helpful for your auth flows!

How to Block Disposable Email Signups Without SMTP Verification

nProejct — Sun, 23 Aug 2026 13:20:45 +0000

Disposable email services make it easy to create temporary addresses that disappear shortly after signup.

They can be useful for privacy, but they also create problems for applications that rely on email for account recovery, trial limits, community moderation, or fraud prevention.

In this article, I will show a lightweight way to screen an email address before accepting a signup.

What should we check?

A practical pre-signup check can answer a few separate questions:

Is the email address syntactically valid?
Does the domain belong to a disposable email provider?
Is it a common free email provider?
Does the domain publish DNS MX records?
Was the result conclusive?

These signals should remain separate. For example, a Gmail address is from a free provider, but that alone does not make it suspicious.

Why not verify the mailbox directly?

It is important to distinguish domain screening from mailbox verification.

An MX lookup can confirm that a domain advertises mail-handling infrastructure, but it cannot prove that:

The mailbox exists
The mailbox belongs to the user
The server will accept a message
The user can receive future messages

SMTP probing can also be slow, unreliable, and rejected by mail servers.

For account ownership, the correct solution is still a confirmation email or one-time code.

The checks in this article are intended as an early risk filter, not as proof of mailbox ownership.

A simple risk model

I use three possible risk levels:

LOW: The lightweight checks passed
HIGH: A definite validation problem was found
UNKNOWN: A DNS error or timeout prevented a reliable conclusion

This distinction matters because an infrastructure error should not automatically be treated as a fraudulent user.

A possible signup policy is:

function decideSignup(result) {
  switch (result.riskLevel) {
    case "LOW":
      return "ALLOW";

    case "HIGH":
      return "BLOCK";

    case "UNKNOWN":
      return "RETRY_OR_REVIEW";

    default:
      return "REVIEW";
  }
}

Calling the API from Node.js

The example below uses fetch, available in modern Node.js versions.

Keep the RapidAPI key on the server. Do not expose it in frontend JavaScript.

async function inspectEmail(email) {
  const response = await fetch(
    "https://disposable-email-validator2.p.rapidapi.com/email/v1/verify",
    {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
        "X-RapidAPI-Key": process.env.RAPIDAPI_KEY,
        "X-RapidAPI-Host":
          "disposable-email-validator2.p.rapidapi.com"
      },
      body: JSON.stringify({ email })
    }
  );

  if (!response.ok) {
    throw new Error(`Email inspection failed: ${response.status}`);
  }

  return response.json();
}

Usage:

const result = await inspectEmail("user@temp-mail.org");

console.log(result);

Example response:

{
  "email": "user@temp-mail.org",
  "validSyntax": true,
  "disposable": true,
  "freeProvider": false,
  "hasMxRecords": true,
  "riskLevel": "HIGH",
  "reason": "Disposable email detected"
}

Notice that the domain can have valid MX records and still be disposable. That is why MX lookup alone is not enough.

Connecting it to an Express signup route

Here is a simplified server-side integration:

import express from "express";

const app = express();

app.use(express.json());

app.post("/signup", async (request, response) => {
  const { email } = request.body;

  if (typeof email !== "string" || email.trim() === "") {
    return response.status(400).json({
      error: "Email is required"
    });
  }

  try {
    const inspection = await inspectEmail(email);

    if (inspection.riskLevel === "HIGH") {
      return response.status(422).json({
        error: "This email address cannot be accepted",
        reason: inspection.reason
      });
    }

    if (inspection.riskLevel === "UNKNOWN") {
      return response.status(503).json({
        error: "Email verification is temporarily unavailable",
        retryable: true
      });
    }

    // Continue with account creation.
    // A confirmation email should still be sent here.

    return response.status(201).json({
      message: "Signup accepted. Please confirm your email."
    });
  } catch (error) {
    console.error("Email inspection error:", error);

    return response.status(503).json({
      error: "Unable to inspect the email address",
      retryable: true
    });
  }
});

In a production application, you should decide whether a temporary verification failure should block signup, trigger a retry, or allow signup with additional restrictions.

Understanding the response

The API returns individual signals instead of only one boolean:

{
  "validSyntax": true,
  "disposable": false,
  "freeProvider": true,
  "hasMxRecords": true,
  "riskLevel": "LOW",
  "reason": "Valid email"
}

This allows the application to create its own policy.

For example:

A community site might allow all free providers
A B2B trial might request additional verification for free providers
A promotion system might block disposable domains
An inconclusive DNS result might be queued for retry

freeProvider should be treated as classification data, not proof of abuse.

Important limitations

This type of API should not be used as the only anti-fraud mechanism.

It does not replace:

Email ownership confirmation
Rate limiting
CAPTCHA or bot detection
IP reputation checks
Device or account-abuse monitoring
Application-specific fraud rules

Domain lists also change over time, so disposable-domain detection requires regular data updates.

Try it

I built the API used in this tutorial and published a free testing plan on RapidAPI:

https://rapidapi.com/cloud-partners-n-project/api/disposable-email-validator2

This is my first public API, and I would appreciate feedback on the response design.

In particular:

Is LOW, HIGH, and UNKNOWN clear enough?
Would a separate recommendedAction field be useful?
Should DNS timeouts return UNKNOWN, or would you handle them differently?
What additional signal would make this easier to integrate into a signup flow?