How it works

A transparent description of exactly what the Email Verifier does on the network.

The verification process

  1. An authorized staff member submits addresses

    our staff sign in to the internal portal and submit addresses that we already hold for a business purpose. Addresses are kept in memory only.

  2. Syntax and domain checks

    Each address is checked for valid syntax. The verifier then performs a DNS lookup of the domain's MX records to find the mail servers responsible for it. Domains without working mail servers are reported without any SMTP connection being made.

  3. A short SMTP conversation

    The verifier connects to the domain's mail server on port 25, identifies itself as lgpteam.com in the HELO/EHLO greeting, issues MAIL FROM and a single RCPT TO for the address, and records the server's reply.

  4. Disconnect — nothing is sent

    The DATA command is never issued. Immediately after the RCPT TO response the verifier sends QUIT and closes the connection. No message, headers, subject or content is transmitted, and nothing is delivered to the mailbox.

  5. Results returned and purged

    The result for each address (good, bad, risky or unknown) is made available to the staff member who submitted it. Once results are fetched, the addresses are purged from memory.

What a session looks like

From the receiving mail server's point of view, a typical session consists only of the following commands:

-- connect to MX host, port 25
EHLO lgpteam.com
MAIL FROM:<…>
RCPT TO:<recipient address being checked>
-- server replies, e.g. 250 (accepted) or 550 (no such user)
DATA   ← never sent
QUIT
-- connection closed

Rate limits

The verifier is deliberately slow and gentle. The following limits are enforced by the service itself and cannot be overridden by users:

Enforced limits
ScopeLimit
Overall throughputAbout 60 checks per minute across all users
Per recipient domainAt most 10 checks per 10 minutes
Per mailbox providerAt most 40 checks per 10 minutes (domains hosted by the same provider are counted together)

How results are interpreted

  • Good – the mail server accepted the recipient at the RCPT TO stage.
  • Bad – the mail server permanently refused the recipient (for example, “no such user”), or the domain has no mail servers.
  • Risky – the server accepts all recipients (catch-all) or the address is otherwise of uncertain quality. Unknown – the server returned a temporary error, used greylisting, or could not be reached. These are reported as-is rather than forced into a yes/no answer.

What the verifier does not do

  • It does not send email, newsletters, notifications or any other message.
  • It does not guess, generate or enumerate addresses, and is not used to harvest addresses.
  • It does not store address lists on disk or share them with anyone.
  • It does not check domains whose administrators have asked to be excluded.

Questions or concerns?

Mail administrators can report problems or request exclusion at abuse@lgpteam.com. See Abuse & opt-out.

Last updated: October 2026