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.
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 eight 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
}
}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.
Try one address
The same check your risk rules would call. Paste any address and see the verdict, plus the per-signal detail behind it.
Paste an address above. Or try one of the examples below.
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.
Pricing
Start free. The first 100 validations a month need no card, which is enough to test the signal against your own data before committing. The same check ships in the email verification API, on its own subscription with its own meter, independent of any other Trueguard product. To check a single address by hand 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.
