Learn how to detect burner domains, temporary inboxes, and disposable email providers before fake users create accounts or abuse your product.
In this tutorial, you will send a signup risk request, review the disposable email finding, and use the risk recommendation to decide whether to allow, review, or block a signup attempt. By the end, you will know how to:
Disposable email domains and temporary inboxes are commonly used to create fake accounts, repeat trials, spam registrations, promotion abuse, and low-quality submissions. They are not always malicious by themselves, but they are a strong reason to review the signup before granting normal access.
Fake accounts Burner inboxes make it easy to create accounts without long-term accountability.
Trial and promo abuse Users can rotate disposable emails to repeatedly access trials, discounts, coupons, or referral incentives.
Low-quality data Temporary inboxes can pollute CRM records, onboarding queues, community registrations, and product analytics.
New to the API? Start with the Quickstart: Score your first signup or the docs quickstart.
Send the email address from your backend and ask the API to include the check breakdown and explanation.
curl https://api.signuprisk.com/v1/analyze-email \
-H "Authorization: Bearer $SIGNUPRISK_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"email": "trial.user@mailinator.com",
"name": "Trial User",
"options": {
"include_checks": true,
"include_explanation": true
}
}'name is optional and works on every plan. You can also send ip (Growth and above) for IP reputation and network type, and industry (Scale and above) for an industry scoring profile. On lower plans, the request still succeeds: IP evidence is omitted, or the default profile is used, with a warning in metadata.warnings.
Test with a real address. Documentation-reserved domains such as example.com, example.org, and example.net can never receive email, so the API always returns block with a risk score of 100 for them. That makes them useless for testing disposable-email handling.
The response tells you whether the email appears to use a disposable or burner domain. The full risk score and recommendation help you decide whether to allow, review, or block the signup.
Illustrative response excerpt, not a real API result.
{
"checks": {
"disposable_email": {
"result": "confirmed",
"is_disposable": true,
"confidence": "high",
"method": "dataset_exact",
"matched_domain": "mailinator.com"
}
}
}| Field | Values | How to use it |
|---|---|---|
checks.disposable_email.result | confirmed, likely, suspicious, none, unknown | How strong the disposable finding is. confirmed is the strongest; likely and suspicious are weaker; none means no disposable evidence was found |
checks.disposable_email.confidence | high, medium, low, unknown, none | How strongly the check supports its own result |
checks.disposable_email.is_disposable | true / false | A simple yes/no for routing |
checks.disposable_email.matched_domain | domain or null | The domain that matched, for logs and support |
checks.disposable_email.risk_contribution | integer | How much this check added to decision.risk_score |
decision.action | allow, review, block | The overall recommendation, after all eight checks |
explanation.top_reasons | array of objects | Each item has reason (plain language), check (for example disposable_email), and contribution |
unknown means the check could not be evaluated. It contributes 0 to the score and should be treated as its own case, not as clean and not as a burner. The score maps to a band and a recommended action:
| Risk score | risk_band | decision.action |
|---|---|---|
| 0–24 | low | allow |
| 25–49 | moderate | review |
| 50–74 | high | review |
| 75–100 | very_high | block |
A disposable email matters, but it should not always be an automatic block. Where a disposable address lands depends on the rest of the evidence in the request. Some products may block disposable signups immediately. Others may require email verification, add a CAPTCHA, limit trial access, or send the signup to review. Signup Risk API returns the recommendation and the evidence; it never blocks or challenges anyone itself, so these steps are yours to choose. ALLOW — Use for low-risk signups where the email is not disposable and no major risk checks failed. REVIEW — Use when the email is disposable or other findings are uncertain, but you do not want to block the user immediately. BLOCK — Use when a disposable email is combined with a very high risk score, suspicious infrastructure, weak account details, or repeated abuse patterns in your own records.
This example uses both the disposable email result and the action recommendation. It blocks only when the API recommends block, reviews disposable emails, allows signups the API recommends allowing, and holds anything it can't read for review.
function routeSignup(result) {
const isDisposable = result?.checks?.disposable_email?.is_disposable === true;
const recommendation = result?.decision?.action;
if (recommendation === "block") {
return {
action: "deny_signup",
reason: "Signup blocked due to high-risk findings."
};
}
if (isDisposable || recommendation === "review") {
return {
action: "hold_for_review",
reason: "Signup requires additional verification."
};
}
if (recommendation === "allow") {
return {
action: "create_account",
reason: "Signup allowed."
};
}
// No usable result (failed call or unexpected value). Choose this default on purpose.
return {
action: "hold_for_review",
reason: "No risk result. Review manually."
};
}Optional stricter rule. If your product wants every confirmed burner rejected, make that explicit in your own code instead of assuming the recommendation will do it. Put this at the top of routeSignup, before the other checks:
const disposable = result?.checks?.disposable_email;
if (disposable?.result === "confirmed" && disposable?.confidence === "high") {
return { action: "deny_signup", reason: "Please sign up with a permanent email address." };
}If the call fails (timeout, quota, or outage), decide on purpose. For a newsletter form, letting the signup through may be fine. For a free trial with real costs, create the account but hold back the costly part until you can score it again. Signup Risk API checks the address and its domain. It does not send email or verify mailboxes over SMTP, so keep your email-confirmation step if you need proof that the user owns the inbox.
POST /v1/analyze-email/batch scores up to 50 emails per request, on every plan. Each email uses one request from your monthly allowance and counts as one unit against your per-minute rate limit. A full 50-email batch needs at least 50 requests per minute (Growth and above), so on Free (5 per minute) or Developer (30 per minute), keep each batch within your plan's per-minute limit. See Analyze up to 50 emails.SaaS trials — Reduce repeated free-trial abuse and fake account creation. Lead forms — Keep burner emails and low-quality submissions out of CRM. Communities — Stop spam accounts before they reach posting or messaging permissions. Promotions and checkout — Reduce repeat accounts created to abuse coupons, discounts, or referral incentives.
Use Signup Risk API to check disposable emails in real time and route each signup with an allow, review, or block recommendation.