> ## Documentation Index > Fetch the complete documentation index at: https://docs.signuprisk.com/llms.txt > Use this file to discover all available pages before exploring further. # Core Concepts > Learn how signup-risk scoring, recommendations, checks, context, and uncertainty work. 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](/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: ```text theme={null} risk_score → risk_band → recommended action ``` | Risk score | Risk band | Recommended action | | ---------- | ----------- | ------------------ | | 0–24 | `low` | `allow` | | 25–49 | `moderate` | `review` | | 50–74 | `high` | `review` | | 75–100 | `very_high` | `block` | 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](/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: | Request | Result | | --------------------------------- | ------------------------------------------------- | | `industry` omitted or `default` | Default profile, no warning | | Unrecognized value | Default profile, `UNKNOWN_INDUSTRY` warning | | Supported value, plan below Scale | Default profile, `INDUSTRY_NOT_AVAILABLE` warning | Warnings ride in `metadata.warnings` — see [Warnings & Quotas](/warnings-and-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 Non-fatal warnings, plan gates, usage quotas, rate limits, and retry behavior.