Email verification evaluates multiple technical signals before an address is classified. A typical process starts with syntax and domain checks, continues through DNS and MX validation, and then uses mail-server and mailbox-level signals when the receiving system allows them.
For Example:
- Syntax - a simple check to ensure the email address conforms to common standards.
- Domain - a lookup on the domain element of the email address to ensure it is configured to accept emails.
- SMTP check - the really clever bit, where we check that the user mailbox exists. By checking with a would-be recipient’s email server via SMTP, we can often see whether a user for a given email address actually exists.
Important:
We do not physically send emails, so email verification is a safe process for your recipients.
The exact sequence varies by provider and server response, but the verification process can be understood in three main layers:
Verification starts by checking whether the address is structurally valid before any mailbox-level request is made.
- Syntax rules catch malformed addresses, missing characters, and invalid formatting.
- The domain portion is normalized and prepared for DNS and mail-routing checks.
- Addresses that fail basic checks can be classified before unnecessary mailbox-level verification is attempted.
Next, the verifier checks whether the domain can receive email and whether its mail infrastructure is configured correctly.
- DNS and MX lookups confirm that the domain exists and publishes mail-exchange records.
- Domain-level signals help separate broken or misconfigured domains from addresses that are ready for mailbox checks.
- These checks happen without sending a message to the address being verified.
When the domain supports further verification, Proofy evaluates mailbox and mail-server signals to determine how confidently the address can be classified.
- SMTP and related server responses can help confirm a mailbox or show that the result is uncertain.
Catch-all and restricted mail servers may accept requests without confirming whether a specific mailbox exists. In those cases, a verifier should return a Risky or Unknown result rather than force a false Valid classification. Additional signals such as disposable or role-based detection help teams understand why an address may need separate handling.
