To validate email addresses, start with the syntax and then ask the mail server. A signup form that accepts any string will collect typos, disposable addresses and addresses that never existed. Sending to that list hurts your sender reputation. Rejecting too aggressively is also a problem: a mail server that refuses to answer does not prove the mailbox is missing.
To validate email addresses without guessing, the email checker validates the syntax, resolves the mail server and asks whether the mailbox exists.
curl "https://api2.globus.studio/v2/email?email=test@gmail.com&format=json"Three answers
When you validate email addresses, invalid means the address cannot be valid: bad syntax, no domain or no mail server. exists means the server accepted the mailbox. unknown means the server refused to answer, timed out or blocked the probe. Treat unknown as unknown, not as a rejection. A validate email addresses check that returns unknown is not a reason to discard a real customer.
How to validate email addresses at signup
When you validate email addresses, most bad input fails at the syntax step. Check for a local part, an at sign and a domain with a dot. Do not try to implement the full RFC by hand. A simple check catches the common typos, and the API handles the rest.
The SMTP probe
The endpoint connects to the mail server on port 25 and asks about the mailbox. Many servers accept the connection and then refuse the query. Some networks block port 25, and the endpoint returns unknown. That is a limit of the protocol, not a bug in the address.
What to do with the result
Reject invalid addresses at signup. Accept exists. For unknown, accept the address and mark it for a later check. Send a confirmation email. If the message bounces, remove the address. This keeps real users in the list and filters the obvious noise.
{
"email": "test@gmail.com",
"status": "exists",
"reason": "mailbox accepted"
}Do not use it as a gate
A mailbox can exist and still be abandoned. A catch-all domain accepts every address. A disposable service creates addresses on demand. The check is one signal. Combine it with a confirmation message and engagement data.
Privacy and limits
To validate email addresses, the endpoint sends the address to the mail server, which is how SMTP works. It does not store the address after the response. The probe has a timeout and a rate limit. Do not run it on a full list in a tight loop. Batch the work and handle unknown results separately.
Read the endpoint documentation for parameters and the full response shape.
Catch-all domains
A catch-all domain accepts every address at that domain. The SMTP probe returns exists for a random string. The address may still be unused. A confirmation message is the only reliable test for a catch-all domain.
Disposable addresses
A disposable service creates a mailbox for a few minutes. The address is valid at signup and gone later. Blocking every known disposable domain is a maintenance job. A confirmation message and an engagement check catch more of them over time.
When port 25 is blocked
Many hosts block outbound port 25. The probe cannot connect, and the result is unknown. Treat that as a network limit, not a bad address. Accept the signup and rely on the confirmation message. Read the endpoint documentation for the timeout and response fields.
Greylisting and temporary failures
A greylisting server may reject the first probe and accept a later one. A temporary DNS failure can make a valid domain look missing. Treat a network error as unknown, retry later, and keep the signup. The confirmation message is the reliable path.
Related reading
A signup form that has to validate email addresses often needs a second check. Read card number validation for payment fields and getting a visitor IP address for rate limits and abuse logs.
Further reading: RFC 5322, Internet Message Format.