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 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.
The problem
Why is email a useful fraud signal?
Email is one of the few identity signals available at the moment of registration. A disposable or fabricated address carries fraud risk before a single transaction occurs.
Fake accounts behind disposable addresses
Throwaway email providers let bad actors spin up accounts with no identity. A disposable address at signup is the single highest-signal indicator of a fake-account attempt.
Fabricated identities with no MX records
A domain with no mail servers cannot receive email. An address at a domain with no MX is a hard tell for a thrown-together fake identity that was never meant to be real.
Blind spots in your risk model
Without an email signal, a risky address clears your signup flow carrying no flag. The gap stays invisible until the account commits fraud, at which point you are in remediation, not prevention.
Catch-all domains collapsed to unknown
Catch-all domains accept every address, so a naive check returns deliverable. Without correct handling, a catch-all clears as safe. The API returns risky, not unknown, so you can weight it correctly.
The signals
What does the email validation API tell a fraud team?
One call returns seven signals per address. A fraud team reads them as risk inputs, not as a single yes or no. The API gives you the verdict and the per-signal detail behind it. You decide what each one means in your context.
Format and MX
Format checks the address against RFC 5322. MX checks whether the domain publishes mail servers at all. A domain with no MX cannot receive mail, which is a hard tell for a thrown-together fake.
SMTP deliverability
A live handshake to the destination server that stops before any message is sent. It reads whether the mailbox would accept mail. An address that looks real but rejects mail is a common pattern in fabricated identities.
Disposable detection
The domain is checked against a continuously updated registry of throwaway providers. Disposable is the single highest-signal flag for fake-account creation, because real users rarely sign up from a ten-minute mailbox.
Catch-all, role-based, free-mail
Catch-all is returned as risky: deliverable at the server, unconfirmed at the mailbox, never proof on its own. Role-based (info@, admin@) and free-mail (Gmail, Outlook, Proton) are context flags. None is a verdict by itself; each is a weight you apply.
The response
What does the API response look like?
Safe, risky, and invalid shown below. Catch-all returns risky, not unknown. The per-signal detail lets your team weight each flag independently.
{
"email": "realemail@gmail.com",
"rawEmail": "realemail@gmail.com",
"syntax": {
"isValid": true
},
"deliverability": {
"status": "safe",
"isSmtpValid": true,
"isMxValid": true,
"isCatchall": false,
"isInboxFull": false,
"isDeliverable": true,
"isDisabled": false,
"mxRecords": [
"alt2.gmail-smtp-in.l.google.com",
"gmail-smtp-in.l.google.com",
"alt4.gmail-smtp-in.l.google.com",
"alt1.gmail-smtp-in.l.google.com",
"alt3.gmail-smtp-in.l.google.com"
]
},
"domain": {
"name": "gmail.com",
"age": 11263,
"isLive": true,
"isRisky": false
},
"quality": {
"isDisposable": false,
"isFree": true,
"isRole": false,
"isSubaddress": false
}
}Is this part of Trueguard's fraud-scoring product?
No. It is a separate product you run yourself; it does not feed the scoring pipeline.
Trueguard's email validation API is a standalone service. You get an API key, you call the endpoint, you read the verdict, and you act on it inside your own stack. It has its own subscription and its own meter. It does not connect to, send data into, or influence Trueguard's fraud-detection scoring product in any way. Two products, separate meters, separate decisions.
What carries over is the team, not the pipeline. The same people who build Trueguard's fraud-detection platform build this API. They know how attackers behave, which is why the email signals are framed as risk inputs rather than a generic deliverability utility. That is brand credibility, not an integration. If you use Trueguard's fraud-scoring product too, that is a separate decision and a separate product. This page is about the email validation API on its own, owned and run by you.
The decision
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.
| Result | What it means | Fraud team action |
|---|---|---|
| safe | 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. |
| risky | Deliverable at the server but unconfirmed at the mailbox. Catch-all, role-based, or free-mail flagged here. | Soft signal. Step up a challenge, apply velocity checks, or combine with your device and IP signals before deciding. |
| invalid | 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. |
| unknown | 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 it means
Format, MX, and SMTP confirm the mailbox accepts mail. Real-looking address with a live server.
Fraud team action
Low risk on the email signal alone. Weigh against your other signals and decide.
What it means
Deliverable at the server but unconfirmed at the mailbox. Catch-all, role-based, or free-mail flagged here.
Fraud team action
Soft signal. Step up a challenge, apply velocity checks, or combine with your device and IP signals before deciding.
What it means
Bad format, no MX records, or the server rejected the address. The mailbox does not exist.
Fraud team action
Strong risk signal. An undeliverable address at signup is a common fake-account pattern. Block or challenge.
What it means
The server blocked the probe or gave no clear answer. Not a verdict.
Fraud team action
Inconclusive. Treat as risky in high-risk contexts. Do not auto-block real users because their provider rate-limited the probe.
Why trust email validation built by a fraud team?
Email validation is easy to ship and hard to ship honestly. The hard part is the uncertainty: catch-all domains, probe-blocked servers, addresses that look real but are not. A team that has spent years reading attacker behavior builds for those edges instead of papering over them.
Platform track record
The team behind this API runs Trueguard's fraud-detection platform, which has processed over 70 million verification events with a false positive rate under 1%. That is the credibility of the team that built the email API, not a measured accuracy claim for email validation itself. It is why the email signals are tuned as risk inputs.
Honest verdicts, no false confidence
Where a result cannot be confirmed, the API says so. Catch-all returns risky, probe-blocked returns unknown, and neither is dressed up as a clean pass. A fraud team needs to know the difference between deliverable, unconfirmed, and rejected. We surface that difference instead of collapsing it into a single guess.
Your stack
How do you act on the result inside your own stack?
You own the decision. The API returns the verdict; what happens next lives in your code, your rules, and your risk thresholds. We do not score the account, gate the signup, or take any action on your behalf. That separation is deliberate: a fraud team needs the decision logic under its own control, not inside a vendor's black box.
In practice you combine the email verdict with the rest of your signals. Velocity checks, device and IP signals, behavioral rules, and your own allow and deny lists are yours to weigh. The email result is one input among them. A disposable address might be a hard block in one product and a step-up challenge in another, depending on your risk tolerance. You set that, not us.
Trueguard ships other standalone signals you can own the same way: VPN and proxy detection, an IP location checker, and a domain age checker. Each is a separate product you call and decide on yourself. They are not a bundled pipeline and they do not auto-combine. They are tools the same team built, available for you to wire into your own logic if you want them.
Pricing
Start free. The first 100 validations a month are free with no card, which is enough to test the signal against your own data before committing. The same check ships in the email verification API at $49.99 a month for 50,000 validations, then $0.001 per validation beyond that. It is a separate subscription with its own meter, independent of any other Trueguard product. To eyeball a single address first, use the free email verifier.
Pay for what you check. Cancel anytime. Overage is billed through Stripe at $0.001 per validation regardless of volume.
What counts as a validation? One request to the validation endpoint is one validation. Failed calls (4xx from your side) do not count.
Related use cases
Signup Form Email Validation
Validate email addresses in real time at registration, before you create the account.
Learn moreLead Form Email Verification
Verify email on lead capture forms before junk addresses sync to your CRM.
Learn moreHubSpot Email Validation
Validate emails for HubSpot forms and contacts via Trueguard's API, before they become contacts.
Learn moreFrequently asked questions.
About email validation for fraud teams.
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. 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, unconfirmed at 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.
