What Is an Email Risk API?
An email risk API evaluates an email address beyond a simple valid/invalid check. It returns a numeric risk score, a confidence level for that score, and the specific signals that produced it — disposable domain, a randomly-generated-looking local part, a brand-new domain, missing SPF/DMARC, an SMTP-confirmed rejection — so a business can decide whether to allow, flag, or block a signup, lead, or transaction, and can see exactly why.
How this differs from plain email verification
A traditional email verification API answers one question: does this address look real and reachable? It checks syntax, resolves MX records, and sometimes attempts an SMTP handshake, then returns something close to valid, invalid, or unknown.
A risk API answers a different question: should I trust this specific submission? A syntactically perfect, deliverable address can still be a throwaway signup, a scraped lead, or a bot-generated account — verification alone can't tell you that, because "deliverable" and "trustworthy" are not the same property. A risk score exists specifically to close that gap.
What actually feeds into the score
In this API, risk is computed from six weighted categories, each contributing independently to a 0–100 score:
| Category | Examples of what it captures |
|---|---|
| email_quality | Invalid syntax, role-based prefixes (admin@, support@), typo'd domains, randomness in the local part |
| domain | Domain doesn't resolve, no MX record, missing SPF, missing DMARC |
| disposable | Domain is a known temporary/throwaway mailbox provider |
| provider | Address uses a free consumer provider (Gmail, Outlook, etc.) |
| deliverability | SMTP-confirmed rejection, catch-all domain, unresolved mailbox status |
| reputation | Composite domain reputation, and domain age when it's very new |
Each triggered signal has a fixed base weight (an invalid syntax or an SMTP-confirmed rejection weighs far more than a missing DMARC record), and the weights sum into the final score, capped at 100.
Score, confidence, and decision are three separate numbers
A risk API worth using never collapses everything into a single yes/no. This API returns three distinct values for every check:
- risk.score — 0 to 100, higher is riskier
- risk.confidence — 0 to 1, how much evidence backed the score (fast mode with no cached DNS data produces a lower-confidence score than a live full scan)
- decision — allow, review, or block, derived from which band the score falls into
| Score range | Level | Default decision |
|---|---|---|
| 0–29 | low | allow |
| 30–59 | medium | review |
| 60–79 | high | review |
| 80–100 | critical | block |
Confidence matters because a score by itself can be misleading. A score of 20 computed from live SMTP confirmation is a much stronger "this is fine" than the same score computed from a fast, cache-only check where the domain simply wasn't found in cache — the API separates "low risk" from "we're not sure yet," which is a distinction most validators don't expose at all.
The same address can score differently depending on why you're checking it
A role-based address like sales@company.com is barely a signal for a consumer signup form, but it's a much stronger signal on a B2B lead form where you specifically want a named contact. The API takes a context parameter — generic, signup, b2b_lead, crm, marketplace, or payment — and multiplies specific signal weights accordingly. In the b2b_lead context, a role-based address weighs 2.5× more than it does in the default generic context; in the signup context, randomness-in-local-part signals and new-domain signals are weighted up, because those matter more when the goal is stopping bot-created accounts.
What a response actually looks like
{
"email": "j.anderson1994@newly-registered-domain.io",
"decision": "review",
"risk": {
"score": 43,
"level": "medium",
"confidence": 0.65,
"breakdown": { "email_quality": 0, "domain": 0, "disposable": 0, "provider": 0, "deliverability": 5, "reputation": 38 }
},
"verification": { "status": "unknown", "domain": "verified", "mailbox": "unconfirmed", "confidence": 0.55 },
"deliverability": { "status": "likely_deliverable", "confidence": 0.6 },
"signals": [
{ "code": "NEW_DOMAIN", "severity": "medium", "impact": 18, "description": "The domain was registered recently - a risk signal, not proof of fraud." },
{ "code": "LOW_DOMAIN_REPUTATION", "severity": "medium", "impact": 20, "description": "The domain's composite reputation score is low." },
{ "code": "SMTP_UNKNOWN", "severity": "low", "impact": 5, "description": "Mailbox existence could not be confirmed." }
],
"suggestion": null,
"meta": { "mode": "standard", "context": "signup", "cached": false }
}Notice what's absent: nothing here claims this person is a fraudster. The signals are specific, falsifiable, and reference observable facts (domain age, reputation composite, unconfirmed mailbox) rather than a black-box "fraud probability." That's deliberate — a score without a reason attached isn't actionable, it's just a number to argue with.
Where risk scoring gets used
- SaaS signup forms — reduce free-trial abuse and bot accounts without hard-blocking every free email provider
- Marketplaces — screen buyer/seller signups where a bad actor has a direct financial incentive to use disposable addresses
- B2B lead generation — down-rank low-quality leads (role-based addresses, obviously generated local parts) before they hit a sales pipeline
- Fintech and payment flows — an extra evidence layer alongside identity verification, not a replacement for it
Common mistakes when adopting risk scoring
- Treating any non-zero score as proof of fraud — most real signups will have at least a small score
- Hard-blocking on "review" instead of routing it to manual review or a secondary check (e.g. email confirmation)
- Ignoring confidence and treating a low-confidence fast-mode score the same as a fully verified one
- Using the same context weighting for every form, when a B2B lead form and a consumer signup form have very different definitions of "risky"
FAQ
No. A high score means several independent signals were present — it's evidence to weigh, not a verdict. Legitimate addresses on brand-new domains or unusual local parts can still score in the review range.
Yes. Deliverability and risk measure different things. A perfectly valid, reachable mailbox on a disposable-email domain is fully deliverable and still high risk, because disposable domains are designed to receive mail temporarily.
No — it's built on top of it. Syntax, MX, SPF/DMARC, and optional SMTP verification all feed into the score as inputs. You still need the verification layer; risk scoring is what turns those individual checks into a single actionable decision.
No. Free providers (Gmail, Outlook, etc.) carry a small, low-severity weight because a small minority of abuse originates there, but the weight is intentionally low — most legitimate users sign up with a free provider address.