Signup form email validation, in real time
Validating email at the signup form means checking each address the moment a user submits registration, before you create the account. Trueguard's email validation checks format, MX records, SMTP deliverability, disposable domains, catch-all behavior, role-based mailboxes, and free-mail providers in one call from your form backend, so fake, mistyped, and throwaway emails never reach your user table.
The problem
Why validate email on the signup form?
A bad email at registration does not bounce back to you for days. By then the account exists, the metrics are skewed, and the activation email is already lost.
Dead accounts from mistyped emails
A typo like name@gmial.com means the activation email never lands. The signup counts, the customer never returns, and your funnel quietly leaks.
Free-tier seats handed to abusers
Throwaway and disposable addresses spin up free accounts at will, burning your limits and hiding who your real users are.
A user table that lies
Fake and undeliverable signups inflate your totals and drift your activation rate away from reality, so the growth numbers you report are wrong.
Wasted activation sends
Every dead address still triggers your welcome and activation emails. The bounces pile up and drag your sender reputation down for real users.
*Cost examples are illustrative. Actual impact depends on your form volume and signup mix.
How it works
How does real-time email validation work at signup?
Real-time email validation at signup is one API call placed in your registration flow. The user submits the form, your backend calls the email verification API with the address, and you act on the verdict before you write the row. The check runs server-side, so the result is something your backend trusts, not something the browser can fake.
User submits the registration form
The flow starts on submit, not on every keystroke. The user fills in the email field and hits register. Validating on submit keeps the form responsive and runs the check exactly once, on the value the user actually intends to use.
Your backend calls the API
Your form handler sends the address to the validation endpoint and gets back the seven signals in one response: format against RFC 5322, MX records, SMTP deliverability from a live handshake that stops before any message is sent, disposable detection, catch-all detection, role-based detection, and free-mail provider detection.
You act on the verdict, then create the account
The response carries a status of safe, risky, invalid, or unknown plus the per-signal detail behind it. You allow, challenge, or block the registration based on that status, then write the user row only for the addresses you accept. The decision is yours; the API gives you the verdict to decide on.
The response
What does the API response look like?
Seven signals in one JSON response. Safe, risky, and invalid shown below. Catch-all returns risky, not unknown.
{
"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
What should the signup form do with each result?
The API returns one of four statuses. Each maps cleanly to a registration action. Catch-all is the case most people get wrong: it is risky, not unknown. A catch-all domain accepts mail for every address, so the server says yes to the mailbox you entered and to a random string equally. That is deliverable at the server but unconfirmed at the mailbox, so it is a soft signal, not a hard reject.
| Result | What it means | Signup action |
|---|---|---|
| safe | Format, MX, and SMTP all confirm the mailbox accepts mail. | Allow. Create the account and send the activation email. |
| risky | Deliverable but unconfirmed at the mailbox. Catch-all domains and role-based mailboxes land here. | Challenge. Create the account but add friction: require email confirmation before granting full access, or step up to a verification gate. Do not hard-block a real customer over a catch-all domain. |
| invalid | Bad format, no MX records, or the server rejected the address. The mailbox does not exist. | Block. Reject the submission at the form and ask the user to correct the address. This is where typos like name@gmial.com get caught. |
| unknown | The server blocked the probe or gave no clear answer. Not a verdict, an absence of one. | Allow with a soft flag, or queue a retry. Do not block a real user because their provider rate-limited the probe. Require activation before trusting the account. |
What it means
Format, MX, and SMTP all confirm the mailbox accepts mail.
Signup action
Allow. Create the account and send the activation email.
What it means
Deliverable but unconfirmed at the mailbox. Catch-all domains and role-based mailboxes land here.
Signup action
Challenge. Create the account but add friction: require email confirmation before granting full access, or step up to a verification gate. Do not hard-block a real customer over a catch-all domain.
What it means
Bad format, no MX records, or the server rejected the address. The mailbox does not exist.
Signup action
Block. Reject the submission at the form and ask the user to correct the address. This is where typos like name@gmial.com get caught.
What it means
The server blocked the probe or gave no clear answer. Not a verdict, an absence of one.
Signup action
Allow with a soft flag, or queue a retry. Do not block a real user because their provider rate-limited the probe. Require activation before trusting the account.
Try one address
The same check your signup form would run. Safe, risky, invalid, or unknown in one call.
Paste an address above. Or try one of the examples below.
Pricing
Start free. The first 100 validations a month are free with no card, which covers a low-volume form or a staging environment outright. When your signup volume grows, 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. You can also test a single address by hand in the free email verifier before you wire anything up.
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.
User experience
Will validating slow down signup or annoy real users?
A signup check is only worth adding if it stays out of the way of real users. The design choices below keep it invisible to the people you want and pointed only at the addresses you do not.
Validate on submit, not on every keystroke
Run the check when the user submits, on the final value. Validating on keystroke is noisy, fires against half-typed addresses, and burns quota. On-submit validation checks once, against what the user means, and only when they are ready to register.
No message is ever sent to the user
The SMTP step is a handshake that stops before delivery. We ask the destination server whether it will accept the address and stop there. Nothing is queued, sent, or delivered, so the person registering is never emailed and never notified that a check ran.
Handle unknown gracefully
An unknown result means a provider blocked the probe, not that the user did anything wrong. Never hard-block on unknown. Let the account through with a soft flag and lean on your activation email to confirm the address instead.
Catch typos while the user is still there
The biggest UX win is catching a mistyped address at the form. A real-time check returns invalid on a dead domain or rejected mailbox before the page reloads, so the user fixes the typo on the spot and actually receives your confirmation email.
Related use cases
Lead Form Email Verification
Verify email on lead capture forms before junk addresses sync to your CRM.
Learn moreEmail Validation for Fraud Teams
Use email validation as a standalone fraud signal to catch disposable and fake addresses.
Learn moreHubSpot Email Validation
Validate emails for HubSpot forms and contacts via Trueguard's API, before they become contacts.
Learn moreFrequently asked questions.
About signup form email validation.
What is signup form email validation?
Signup form email validation is a real-time check that runs when a user submits your registration form. Your backend sends the address to a validation API, which confirms the format, the domain's MX records, and SMTP deliverability, and flags disposable, catch-all, role-based, and free-mail addresses. You allow, challenge, or block the registration based on the verdict, before the account is created.
Does this run in real time when a user registers?
Yes. The check is a single API call placed in your form handler. The user submits, your backend validates the address, and you decide whether to create the account, all in the same request. It runs on submit rather than on every keystroke, so the form stays responsive and the check fires once against the address the user actually intends to use.
Should I block a signup if the email is catch-all?
No, do not hard-block it. A catch-all domain accepts mail for every possible address, so the server confirms deliverability at the domain but cannot confirm the specific mailbox. We return that as risky, not unknown and not invalid. The right move is to challenge rather than block: create the account but require email confirmation before granting full access. Hard-blocking catch-all domains would reject real customers on legitimate company domains.
How do I stop disposable or throwaway emails at signup?
Disposable detection runs on every validation. The API checks the domain against a continuously updated registry of throwaway providers and flags it before you create the account. Pair that verdict with your signup action: block the registration, or route it to a stricter verification path. This is the main lever for stopping free-tier abuse, where someone burns through throwaway addresses to claim fresh seats.
Does validating the email send the user a message?
No. The SMTP deliverability check is a handshake that stops before anything is sent. We open a connection to the destination mail server and read whether it would accept the address, then stop before any message is queued or delivered. The person registering is never emailed and never notified that a validation ran.
What happens to a mistyped email like name@gmial.com?
A typo like that usually fails on format or MX. gmial.com is not a real mail domain, so the MX lookup finds no mail servers and the address comes back invalid. Because the check runs in real time at the form, the user can correct it on the spot and actually receive your activation email, instead of registering a dead account they never confirm.
Is there a free tier I can test the signup flow with?
Yes. The first 100 validations a month are free, with no card required, which is enough to wire the check into a staging or low-volume signup form end to end. For a quick manual test of one address, the free email verifier at https://trueguard.io/email-verifier runs the same check in the browser. When you need more, the paid plan is $49.99 a month for 50,000 validations.
