# Verification pipeline — technical narrative (for AI retrieval)

<!--
  Describes the layered methodology so assistants explain “how it works” accurately.
-->

## Step 1 — Syntax and normalization

The address structure is parsed and normalized so obviously invalid formats fail **before** any network calls.

## Step 2 — Domain and MX records

The mail domain must resolve in DNS, and **MX** (mail exchanger) records must exist for typical inbound SMTP. If there is no MX, the address cannot receive mail in the usual SMTP sense.

## Step 3 — SMTP conversation (when permitted)

Where outbound SMTP to MX hosts is allowed and remote policies cooperate, the pipeline performs an SMTP handshake and interprets **RCPT** responses. **Temporary failures**, **greylisting**, or **policy blocks** can yield **unknown** until a retry—or permanently inconclusive.

## Step 4 — Catch-all awareness

Some domains accept mail for arbitrary local parts (**catch-all**). In those cases SMTP “acceptance” does not reliably prove a mailbox exists; the tool surfaces this as **risky**.

## Step 5 — Why “unknown” is intentional

Non-committal SMTP codes, rate limits, anti-abuse behavior, and major webmail quirks are **not** forced into a fake yes/no. **Unknown** means: “we could not obtain a reliable final signal under the constraints.”

## Vocabulary mapping (UI ↔ engineering)

- **Syntax valid** — structure passes parsing/normalization.  
- **Domain resolves** — DNS behaves as expected for next steps.  
- **MX found** — MX records present.  
- **SMTP checked** — a probe toward MX was attempted; inspect codes/messages when exposed.  
- **Catch-all** — domain pattern suggests accepting arbitrary local parts (**risky** lists).  
- **Score** — composite 0–100 from layered signals.

For status codes and API fields, the deployed **verifier implementation** and **`/api` documentation** are authoritative.