Email validation · Use cases · Fraud teams
Use case
Email validation for fraud teams, as a standalone signal.
Fraud teams use email validation as a standalone signal to catch disposable, throwaway, and undeliverable addresses behind fake accounts. Trueguard's email validation API checks format, MX, SMTP validity, mailbox deliverability, disposable domains, catch-all, role-based, and free-mail in one call. It is a separate product you run yourself; it does not feed Trueguard's fraud-scoring pipeline.
As a risk input
One request, four possible answers.
Try one address.
The same check your risk rules would call. 10 free checks a day, no key and nothing sent to the address.
Or try
Why is email a useful fraud signal?
Fake accounts behind disposable addresses
Fabricated identities with no MX records
Blind spots in your risk model
Catch-all domains collapsed to unknown
How do you act on the result inside your own stack?
The API returns the verdict. What happens next lives in your code, your rules, and your risk thresholds.
Call the API at registration
Read the signals, not just the status
Combine it with your signals and decide
How do you read each status as a fraud signal?
The four statuses are risk inputs, not final verdicts. A fraud team reads them the way it reads any other signal, weighted against everything else it knows.
Status
What it means
Fraud team action
Format, MX, and SMTP confirm the mailbox accepts mail. Real-looking address with a live server.
Low risk on the email signal alone. Weigh against your other signals and decide.
Deliverable at the server but unconfirmed at the mailbox. Catch-all and disposable land here. Role-based and free-mail are separate flags and do not set this status.
Soft signal. Step up a challenge, apply velocity checks, or combine with your device and IP signals before deciding.
Bad format, no MX records, or the server rejected the address. The mailbox does not exist.
Strong risk signal. An undeliverable address at signup is a common fake-account pattern. Block or challenge.
The server blocked the probe or gave no clear answer. Not a verdict.
Inconclusive. Treat as risky in high-risk contexts. Do not auto-block real users because their provider rate-limited the probe.
What does the email validation API tell a fraud team?
Format and MX
SMTP deliverability
Disposable detection
Catch-all, role-based, free-mail
What does the API response look like?
One POST from your signup risk check. The per-signal detail lets your team weight each flag independently.
// in your signup risk check
const check = await fetch(
"https://api.trueguard.io/v2/email/validation",
{
method: "POST",
headers: {
"X-API-KEY": process.env.TRUEGUARD_KEY,
"Content-Type": "application/json"
},
body: JSON.stringify({ email })
}
).then((r) => r.json());
if (check.quality.isDisposable || check.deliverability.status === "invalid") {
return stepUpChallenge(account);
}{
"email": "name@gmail.com",
"rawEmail": "name@gmail.com",
"syntax": { "isValid": true },
"deliverability": {
"status": "safe",
"isSmtpValid": true,
"isMxValid": true,
"isCatchall": false,
"isInboxFull": false,
"isDeliverable": true,
"isDisabled": false,
"mxRecords": [
"gmail-smtp-in.l.google.com",
"alt1.gmail-smtp-in.l.google.com",
"alt2.gmail-smtp-in.l.google.com",
"alt3.gmail-smtp-in.l.google.com",
"alt4.gmail-smtp-in.l.google.com"
]
},
"domain": {
"name": "gmail.com",
"age": 11363,
"isLive": true,
"isRisky": false
},
"quality": {
"isDisposable": false,
"isFree": true,
"isRole": false,
"isSubaddress": false
}
}Frequently asked questions.
Still deciding? Contact support or read the API reference.
How do fraud teams use email validation?
Fraud teams use it as an early risk signal at the point of account creation. One API call returns whether the address is disposable, whether the domain has MX records, whether the mailbox accepts mail, and whether it is catch-all, role-based, or free-mail. The team weighs those flags against its own rules and decides whether to allow, challenge, or block. The email result is an input, not a final verdict.
Is Trueguard's email validation part of its fraud-detection or scoring product?
No. It is a standalone product you run yourself, and it does not feed the scoring pipeline. The email validation API has its own subscription, its own meter, and no connection to Trueguard's fraud-detection scoring product. They are two separate products with separate decisions. What they share is the team that builds them, not data flow between them.
Can I run this without using any other Trueguard product?
Yes. You sign up, get an API key, and call the email validation endpoint on its own. There is no dependency on Trueguard's fraud-detection product or any other service. It is a self-contained API with its own free tier and its own paid plan, designed to be run independently inside whatever stack you already have.
What email signals indicate fraud risk?
The strongest is disposable: a throwaway domain at signup correlates heavily with fake accounts. A brand-new domain, a domain with no MX records, and a known throwaway pattern are also flags. Catch-all is a softer one, returned as risky because the server confirms the domain but not the mailbox, unless a second check resolves it. None of these proves fraud alone. Each is a weight you apply alongside your other signals.
Does a catch-all result mean the account is fraud?
No. Catch-all means the domain accepts mail for every possible address, so the server cannot confirm the specific mailbox. We return it as risky, deliverable at the server but unconfirmed at the mailbox, unless a second check confirms or rules out the mailbox. It is a signal, not a verdict. Plenty of legitimate companies run catch-all domains. Treat it as a reason to look closer or step up a challenge, not as proof of fraud.
Who built this and why should a fraud team trust it?
The team behind Trueguard's fraud-detection platform built it. That platform has processed over 70 million verification events with a false positive rate under 1%. We frame that as the credibility of the team, not as a measured accuracy figure for email validation itself. The reason it matters is that the email signals are designed as risk inputs by people who read attacker behavior daily.
Does validating email replace device or IP signals?
No. Email is one signal. It does not replace device fingerprinting, IP reputation, velocity checks, or behavioral rules. A fraud team owns combining email with the rest of its stack and weighting each input for its own risk tolerance. Trueguard offers other standalone signals like VPN and proxy detection and IP location, but they are separate products you choose and wire in yourself, not an auto-combined pipeline.
Is there a free tier for evaluation?
Yes. The first 100 validations a month are free with no card, which is enough to run the signal against a sample of your own traffic and see how it scores. The paid plan is $49.99 a month for 50,000 validations, then $0.001 per validation over that, on its own meter. For a quick manual check of one address, the free email verifier at https://trueguard.io/email-verifier runs the same validation in the browser.
Add email to your risk signals.
100 validations a month, free, no card. Enough to test the signal against your own data before you commit.
Get your free API keyNo credit card required.
