Email flags the inbox, not just the syntax
Email format, domain mail setup, and a role name such as admin or support are separate checks. Here is what each field tells you.
An email address can be spelled correctly and still be a poor fit for what your form needs. It might use a domain without mail servers, or it might be a shared address like admin@ when you were expecting someone's individual address.
/email keeps those checks separate. These responses are shortened to the relevant fields:
GET /email/admin@example.com
{ "email": "admin@example.com", "valid": true, "domain": "example.com", "domain_valid": false, "role": true }
GET /email/jsmith847@gmail.com
{ "email": "jsmith847@gmail.com", "valid": true, "domain": "gmail.com", "domain_valid": true, "role": false }
Both pass valid because their format is correct. domain_valid checks for mail routing: MX records, or an address record when no MX exists. An explicit null MX means the domain does not accept mail. That is a check on the domain's mail setup, not proof that a particular inbox accepts mail.
role looks at the part before the @. Names such as admin and support flag the address as a likely role inbox. A false result means the name did not match that list. It does not establish that there is a person on the other end.
What you do with that information depends on the form. A support contact may be exactly what you want for a company record. An individual account signup may need a different check. Keeping the fields separate lets you make that choice without treating every concern as an invalid email address.