Email checker

curl -s "https://api2.globus.studio/v2/email?email=user@example.com&format=json"

The email validator checks the syntax, resolves the MX records and asks the first mail server whether the mailbox exists. No message is sent. The SMTP conversation stops at RCPT TO, so the mailbox gets no email and the list stays clean.

What the email validator returns

The response has a status and a short message. The status is exists, not_exists, unknown or invalid. Treat unknown as unknown, not as a rejection.

{
  "status": "exists",
  "message": "Email exists"
}

How the statuses differ

exists means the MX answered and accepted the recipient. not_exists means there is no MX record or the server clearly rejected the mailbox. unknown means a timeout, a blocked port, a policy rejection or a server that will not confirm. invalid means the address cannot be valid, usually because of syntax.

Syntax and MX records

Most bad input fails at the syntax step. Check for a local part, an at sign and a domain with a dot before you call the API. Then the MX lookup shows whether the domain can receive mail at all. A domain without MX records is a strong reason to reject, even before the SMTP probe.

The SMTP probe

The email validator connects to the mail server on port 25 and asks about the mailbox. Many hosts block outbound port 25. In that case the answer is unknown, and the address is not proven bad. The service inspects up to three MX hosts with a five-second timeout per step.

What it cannot tell you

The email validator does not detect catch-all domains and does not prove that a person reads the mailbox. A catch-all domain accepts every address, including a random string. A disposable service creates a mailbox for a few minutes. The status is one signal, not a guarantee.

Some servers answer differently on a second attempt. 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.

What to do with the result

Reject invalid at the form. Accept exists. For unknown, accept the address and send a confirmation message. If the message bounces, remove the address. That flow keeps real users and filters the obvious noise without guessing.

Confirmation and list hygiene

A confirmation message is the only check that proves a person can read the mailbox. Send it once, keep the token short-lived and expire it after a day. If the message bounces, mark the address and stop sending. If the person never confirms, remove the address after a reasonable period instead of mailing it again.

Keep the email validator result in the record with a date. A mailbox can disappear, and an address that existed last year may be gone today. Re-check before a large send, not on every page view. The status and the confirmation together give a clean list without guessing.

Rate limits and privacy

The endpoint is rate-limited as a heavy operation because it waits for a remote server. Do not run it on a full list in a tight loop; batch the work and handle unknown results separately. The address is sent to the mail server, which is how SMTP works, and the email validator does not keep it after the response.

Related endpoints

A signup form often needs a second check. The PAN validator covers card fields, and the public IP address API helps with rate limits and abuse logs. The email validation guide covers confirmation flows.

Further reading: RFC 5322, Internet Message Format.