Guides
How to validate email addresses in a signup form
Check formatting in the browser, verify the address on your server and confirm mailbox control before granting access that depends on it. Keep uncertain results separate from clear address errors.
What to do with each answer
The same four verdicts every time. The instruction changes with the situation, because what a mistake costs changes with it.
| Verdict | What to do here |
|---|---|
| Deliverable | Continue the signup. If account access or recovery depends on the mailbox, ask the person to confirm it; a deliverable result does not establish who controls it. |
| Risky | Read the returned action and reasons. A catch-all or role address can be legitimate. Continue behind confirmation when appropriate; use a separate rule for disposable addresses if your trial policy requires it. |
| Undeliverable | Ask for a correction before completing an email-dependent signup. Explain the address problem and keep the entered value so the person can edit it. |
| Unknown | Keep signup possible behind mailbox confirmation. The service did not establish a clear answer; this is not evidence that the address is invalid. Recheck later if your workflow needs it. |
Start with format feedback in the browser
Use an email field with a visible label and an explanation next to any error. Browser validation can flag a missing @ or an incomplete domain, but it cannot tell whether a mailbox exists. Keep the address the person entered so a correction takes one edit.
Validate on submission. If you also check after the person leaves the field, avoid repeated API requests for each keystroke. When the value changes, discard a result for the old value: a delayed response must not mark a newly corrected address as invalid.
Make the verification decision on the server
Your signup endpoint sends the address to POST /v1/verifications with a bearer credential held on the server. Repeat the necessary input checks there, because a client can bypass browser validation. The email verification API page covers the request and full response.
Read status, action and reason_codes together. The actions are allow, allow_with_email_confirmation and reject. The verdict table above gives an example signup policy; it is not a fixed mapping from status to action.
Offer a typo suggestion without changing the address
INVALID_SYNTAX and DNS_NXDOMAIN can explain a clear format or domain problem. LIKELY_DOMAIN_TYPO means a correction may help. Show the suggestion beside the entered address and let the person accept it or keep the original. An unusual domain can be intentional.
After a correction, verify the new address and attach the result to that value. Do not silently rewrite a domain, remove a plus tag or treat a role mailbox as a typing mistake.
Handle pending work and unavailable answers
A full check can return pending with an id and retry_after_ms. Wait for the interval, then retrieve GET /v1/verifications/{id} with the same credential. Poll only while work is pending and set a deadline for your form. There are no callbacks.
When the deadline expires, apply your own fallback, such as continuing behind confirmation and finishing the check later. Do not label that local timeout as an API unknown result or as an invalid address. HTTP errors also describe a request or service problem, not an address verdict. The real-time verification page explains the waiting path.
Confirm control before relying on the mailbox
Emvero does not send a confirmation email. A full SMTP check stops before the message stage; even a positive server response cannot establish that the person signing up controls the mailbox. Send your own confirmation when access or recovery depends on that control, and enforce the requirement on the server.
For abuse prevention, add controls suited to repeated accounts and bot activity. DISPOSABLE_DOMAIN can inform an email policy, but it is not proof of fraud. The trial-abuse guide covers that decision.
Reason codes that decide something here
The API uses these identifiers to explain a check. The notes identify values that the current verification policy or probe does not return.
INVALID_SYNTAX | Address is not well formed |
LIKELY_DOMAIN_TYPO | Domain looks like a typo |
DNS_NXDOMAIN | Domain does not exist |
DISPOSABLE_DOMAIN | Disposable address provider |
Terms worth knowing first
Email address syntax
Address-format rules checked before network lookups. A valid format does not establish a working domain or mailbox.
Disposable email address
An address at a temporary-mail provider. The domain signal concerns durability and policy, rather than proving delivery failure.
Greylisting
A temporary SMTP refusal asks the sender to try again. A later attempt may provide more evidence.
The choice behind this
Try it on an address you already know.
The free checker returns the whole result - every stage, every reason code, nothing held back.