Skip to main content
This page explains how Signup Risk API turns an email address and optional signup context into a decision. It covers product semantics — for endpoint schemas, see the API reference.

​
Deterministic scoring

For identical normalized inputs, applicable request context, scoring configuration, and component versions, Signup Risk API produces the same result. Scoring is deterministic: there is no randomness, sampling, or time-of-day variation, and the same evidence always maps to the same score. Results can still change over time when the underlying evidence changes:
  • DNS state — domain records (MX, SPF, DMARC, registration) are looked up live; a domain that changes its mail setup can score differently after the change
  • Intelligence data — check datasets are updated as providers and infrastructure change
  • Scoring and component versions — scoring-model improvements can change how the same evidence maps to a score
Repeat analyses of the same address may also be served from a short-lived server-side cache (up to 24 hours); when that happens, metadata.cache reports the hit, the age of the entry, and the scoring version that produced it.

​
Score, band, and action

The recommendation flows in one direction:
The action is a recommendation, and every integration should decide what the recommendation means in its own product. For example, review might mean:
  • require email confirmation before activating the account
  • present a CAPTCHA or additional verification step
  • delay access to sensitive features until a human approves the signup
  • route the signup into a manual review queue
  • add the signup to a watchlist for later review
These are examples only — Signup Risk API does not perform any of them. It returns the score, the evidence behind it, and the recommendation; enforcement is always your application’s responsibility.

​
The eight core checks

Every analysis evaluates eight checks. Each returns a verdict, the evidence behind it, and its contribution to the overall score (visible with options.include_checks — see Understanding the Response).

​
Disposable email (disposable_email)

  • Evaluates whether the domain belongs to a disposable or throwaway email provider, from curated datasets and heuristics. Results: confirmed, likely, suspicious, none, or unknown.
  • Does not prove malicious intent — disposable addresses are also used for privacy by legitimate people. A disposable classification contributes risk evidence, nothing more.

​
Domain infrastructure (domain_infrastructure)

  • Evaluates the domain’s DNS reality: whether the domain exists, its MX (mail), SPF, and DMARC records, whether it is a reserved/special-use name, and how long ago it was registered. Results: healthy, incomplete, suspicious, unavailable, or unknown; the check distinguishes an authoritative “domain does not exist” from a temporary lookup failure.
  • Does not prove fraud. A domain with a missing SPF or DMARC record alone should not be interpreted as fraudulent — plenty of legitimate domains lack them. A temporary DNS failure is reported as unavailable, never as a negative finding.

​
Provider (provider)

  • Evaluates what kind of mailbox provider the domain is: free provider, business, education, government, disposable, or unverified custom domain. Results include free_provider, business_domain, education_provider, government_provider, custom_domain_unverified, and unknown_provider.
  • Does not prove anything on its own — provider category is context that adjusts the weight of other evidence, not a standalone verdict.

​
Role address (role_address)

  • Evaluates whether the local part is a shared functional address rather than a personal one: support@, billing@, admin@, sales@, team@, no-reply@, and similar. Results: personal_like, functional_role, team_role, transactional_role, security_or_abuse_role, automated_or_no_reply, or unknown.
  • Does not prove abuse — legitimate businesses use role addresses constantly. Role addresses add a small amount of risk because they are not tied to one person; do not automatically block them.

​
Domain typo (domain_typo)

  • Evaluates whether the domain is a likely misspelling of a well-known provider domain (for example, a one-character edit of a popular mail provider), with a suggested correction when one is found. Results: probable_typo, suspicious_similarity, near_match, no_typo, or unknown.
  • Does not prove abuse — many typos are honest mistakes. Near-matches are reported conservatively and contribute less evidence than probable typos.

​
Synthetic identity (synthetic_identity)

  • Evaluates placeholder-style or synthetic registration characteristics: keyboard-mash local parts, machine-generated strings, and placeholder-style names submitted with the address.
  • Does not prove real-world identity fraud — it detects synthetic construction patterns in the address and submitted context, nothing broader.

​
Name match (name_match)

  • Evaluates how well a submitted name aligns with the email address: name/email alignment, local-part quality (personal-looking vs generic vs machine-like), and placeholder-name detection. Results: strong_match, weak_match, weak_mismatch, mismatch, none, or unknown.
  • Requires context — the optional name request field. Without a name, the check reports name_supplied: false and contributes nothing.
  • This is not KYC or identity verification. It compares two strings you supplied; it verifies no government identity, document, or real-world fact.

​
IP reputation (ip_reputation)

  • Evaluates the network properties and reputation of the signup IP: network classification (residential, mobile, business, datacenter, hosting, VPN, proxy, Tor) and reputation findings. Results: confirmed_bad, high_risk, suspicious, clean, or unknown.
  • Requires context and plan access — the optional ip request field (or the connection’s client IP) and a Growth plan or above. Below that, the check reports available: false.
  • Does not prove abuse — network classification alone does not; privacy tools have legitimate uses. The raw IP address is never returned in the response, only the derived classification and findings.

​
Industry profiles

The optional industry request field selects a scoring profile tuned to a signup context. Supported values: default, fintech, marketplace, saas, ecommerce, and community. An industry profile is scoring configuration, not a ninth check. It never appears in checks; instead it adjusts how the eight checks’ contributions are weighted — within bounded limits, so a profile can emphasize or de-emphasize evidence but never invent or hide it. Industry profiles require a Scale plan or above. The fallback behavior is always soft — the request still succeeds, scored with the default profile: Warnings ride in metadata.warnings — see Warnings & Quotas.

​
Evidence reconciliation

The eight checks overlap: a nonexistent domain also has no MX record, and a disposable provider domain also fails infrastructure expectations. The scoring engine reconciles overlapping findings under a dominance hierarchy so related evidence is counted once, not blindly stacked. Two examples of the principle:
  • Nonexistent domain + missing MX — when the domain authoritatively does not exist, its missing mail records are a consequence, not independent findings. The nonexistent-domain evidence dominates, and evidence that presupposes a real domain (local-part analysis, provider classification of an unverified custom domain) is reduced or suppressed.
  • Confirmed disposable + overlapping identity evidence — when the domain is a confirmed disposable provider, overlapping identity and synthetic-pattern evidence is suppressed; IP reputation remains independent and still counts.
Temporary failures are never escalated or suppressed — a DNS timeout reconciles as neutral.

​
Unavailable evidence

Signup Risk API is fail-honest: temporary DNS or enrichment failures remain unavailable or uncertain rather than being converted into fabricated positive or negative findings. A domain that could not be looked up is unavailable, not “suspicious”; a check with no evidence is unknown, not “clean”. This surfaces in three places:
  • Check state — the affected check reports unknown/unavailable with risk_contribution: 0
  • Assessment — decision.assessment widens (evidence_coverage drops, uncertainty rises) and limitations carries a code such as domain_intelligence_unavailable
  • Warnings — plan-related omissions (IP intelligence, industry profiles, explanations) additionally appear in metadata.warnings; transient lookup failures do not, because they are already represented in the check state and assessment
Treat high-uncertainty decisions as candidates for your own verification step rather than as weak or wrong results.

​
Privacy

Raw signup IPs are not returned in API responses — the ip_reputation check exposes only the derived network classification and reputation findings. Submitted names are likewise never echoed back; name_match returns only its verdicts and derived evidence. These boundaries hold regardless of plan.

​
Next steps

Warnings & Quotas

Non-fatal warnings, plan gates, usage quotas, rate limits, and retry behavior.