Email Domain Reputation API: Detect Signup Fraud with WHOIS and DNS

Introduction

A signup form usually treats an email address as a delivery channel: send a verification link, wait for the click, then create the account. That proves the user controls an inbox. It does not prove the domain behind the inbox represents a legitimate company, a stable customer, or a low-risk identity.

Trial abuse, fake B2B accounts, coupon abuse, affiliate fraud, and low-quality lead capture often hide behind domains that look plausible at first glance. The pattern is familiar: a custom domain registered yesterday, privacy-shielded WHOIS data, no meaningful mail infrastructure, and just enough DNS to receive a verification email. A human reviewer can spot this after investigation. A product team needs the signal at signup time.

This is where an email domain reputation workflow helps. Extract the domain after the@ sign, query public domain intelligence, and turn the result into a risk score. WhoisJSON provides this through the dedicated Email Domain Intelligence API — one call that combines WHOIS/RDAP age, registrar and EPP status, MX, SPF, DMARC, disposable detection, and routing actions. You can also use the underlying WHOIS API and DNS Lookup API separately if you need full control.

What Is Email Domain Reputation?

Email domain reputation is a risk assessment of the domain part of an email address, not the mailbox itself. For [email protected], the domain to inspect is example.com. The goal is not to decide whether the user is good or bad from one field. The goal is to separate normal business domains from domains that deserve more friction, review, or lower trust.

A real company domain usually has history. It was registered months or years ago, has stable nameservers, receives email through MX records, publishes at least some TXT-based mail policy, and does not carry suspicious EPP states. A disposable abuse domain often has the opposite profile: very recent creation, minimal DNS, hidden or missing ownership data, and no operational footprint beyond account creation.

Signals That Matter at Signup

The useful signals are simple, public, and fast enough to compute before or immediately after account creation.

The Swagger definition for/nslookup documents A, AAAA, CAA, CNAME, MX, NS, SOA, TXT, DMARC, BIMI, MTASTS, and TLSRPT in one response. That makes it practical to inspect mail posture without chaining many DNS calls yourself. For routing-specific interpretation, provider checks, and MX priority examples, see the MX record lookup API guide.

The API Contract You Need

WhoisJSON API requests use theAuthorization header with aTOKEN= prefix. The production base URL is:

https://whoisjson.com/api/v1

For signup scoring, two endpoints usually cover the first version of the workflow.

curl "https://whoisjson.com/api/v1/whois?domain=example.com" \
  -H "Authorization: TOKEN=YOUR_API_KEY"

curl "https://whoisjson.com/api/v1/nslookup?domain=example.com" \
  -H "Authorization: TOKEN=YOUR_API_KEY"

Every API response includes aRemaining-Requests header according to the OpenAPI documentation. Track it in production, especially if signup scoring runs on the critical path. For retry behavior, see the guide on WHOIS API rate limits and 429 errors.

A Practical Signup Risk Score

Start with a transparent model that your support, sales, and security teams can understand. You can tune the weights later from your own abuse outcomes.

The exact thresholds depend on your business. A developer tool with a generous free tier may tolerate less risk than an enterprise demo form where every lead is reviewed by sales anyway.

Python Example: Score an Email Domain

Pass an email address to the dedicated a(href="/email-domain-intelligence-api") Email Domain Intelligence | endpoint. The API returns a risk score, recommendation, routing action, and individual signals — no manual WHOIS/DNS stitching required.

import requests

API_KEY = "YOUR_API_KEY"
BASE_URL = "https://whoisjson.com/api/v1"
HEADERS = {"Authorization": f"TOKEN={API_KEY}"}


def check_signup_email(email: str) -> dict:
    response = requests.get(
        f"{BASE_URL}/domain/email-intelligence",
        headers=HEADERS,
        params={"email": email},
        timeout=10,
    )
    response.raise_for_status()
    data = response.json()
    routing = data.get("routing") or {}

    return {
        "email": email,
        "domain": data.get("domain"),
        "domain_category": data.get("domainCategory"),
        "risk_score": data.get("riskScore"),
        "risk_level": data.get("riskLevel"),
        "decision": routing.get("suggestedAction"),
        "signals": [signal.get("code") for signal in data.get("signals") or []],
        "remaining_requests": response.headers.get("Remaining-Requests"),
    }


print(check_signup_email("[email protected]"))

Node.js Example: Signup Middleware

In a real SaaS app, call the Email Domain Intelligence endpoint with a timeout, store the score on the account, and route users into the right onboarding path based on code routing.suggestedAction | .

const API_KEY = process.env.WHOISJSON_API_KEY;
const BASE_URL = 'https://whoisjson.com/api/v1';

function parseRemainingRequests(value) {
  if (value === null) return null;
  const parsed = Number.parseInt(value, 10);
  return Number.isNaN(parsed) ? null : parsed;
}

async function scoreSignupEmail(email) {
  const url = new URL(`${BASE_URL}/domain/email-intelligence`);
  url.searchParams.set('email', email);

  const controller = new AbortController();
  const timeout = setTimeout(() => controller.abort(), 10000);

  try {
    const response = await fetch(url, {
      headers: { Authorization: `TOKEN=${API_KEY}` },
      signal: controller.signal
    });

    if (!response.ok) {
      return {
        email,
        score: null,
        decision: 'allow_with_monitoring',
        reasons: [`lookup failed: HTTP ${response.status}`],
        remaining_requests: null
      };
    }

    const data = await response.json();
    const routing = data.routing || {};

    return {
      email,
      domain: data.domain,
      domain_category: data.domainCategory,
      score: data.riskScore,
      risk_level: data.riskLevel,
      decision: routing.suggestedAction || data.recommendation,
      reasons: (data.signals || []).map((signal) => signal.code),
      remaining_requests: parseRemainingRequests(response.headers.get('Remaining-Requests'))
    };
  } finally {
    clearTimeout(timeout);
  }
}

module.exports = { scoreSignupEmail };

Avoiding False Positives

The most expensive mistake is treating a single technical signal as proof of fraud. New startups register new domains. Small businesses misconfigure DMARC. Some legitimate companies hide WHOIS contacts for privacy. A good onboarding model uses domain intelligence to decide the next step, not to replace judgment entirely.

• Do not block only because a domain is new. Combine age with MX, DMARC, user behavior, payment risk, IP reputation, and account velocity.
• Separate consumer email from business email. Gmail, Outlook, Yahoo and similar domains need a different policy than custom company domains.
• Keep an unknown state. If an API call times out or returns 429, mark the domain as unknown and retry later. Do not convert lookup failure into "safe" or "fraud".
• Review outcomes. Feed confirmed abuse and false positives back into your scoring weights.

If your workflow involves high-volume batches, use the patterns from the Bulk WHOIS lookup guide and avoid uncontrolled concurrency.

Where This Fits in Your Stack

Email domain reputation is not a replacement for email verification, CAPTCHA, device fingerprinting, payment risk, or abuse monitoring. It is a low-friction signal that arrives early enough to change the onboarding path.

For security-heavy workflows, connect this article with phishing domain detection and newly registered domain detection. For customer-domain onboarding, the DNS Lookup API guide explains broader DNS record handling.

FAQ

Conclusion

Signup fraud often looks like a normal email verification problem until you inspect the domain behind the address. WHOIS and DNS data give you a practical way to tell the difference between an established business domain and a newly registered, minimally configured identity.

The best first version is intentionally simple: extract the email domain, query WHOIS and DNS, compute a transparent score, and route users to allow, monitoring, step-up verification, manual review, or block. The score will improve as your own abuse data teaches you which signals matter most.