Know what happens to every address.

How the check works

1. Split the addressIdentify the local part and domain around one valid @ separator.
2. Apply structural rulesCheck length, characters, separators and required domain labels.
3. Route the resultStop impossible addresses early and pass plausible addresses to domain checks.

What the result cannot prove

Syntax rules cannot tell whether the domain exists, whether its mail servers work or whether a recipient mailbox has been created. A perfectly formatted fictional address can pass this step.

How to use the result

Keep the original value available for correction. Do not silently guess where punctuation or an @ sign belongs, because an automatic “fix” can create a different person’s address.

How the check works

1. Extract the domainNormalize the part after @ without changing the submitted mailbox name.
2. Compare provider intelligenceLook for a maintained classification of temporary and rotating inbox services.
3. Return a policy signalLabel the address as disposable so the customer can decide whether to accept it.

What the result cannot prove

Disposable providers appear, disappear and rotate domains. No database can promise instant knowledge of every new service, and a disposable classification says nothing about the intent of an individual user.

How to use the result

For important accounts, ask for a stable address or require an additional verification step. For newsletters, keep disposable addresses separate rather than presenting them as ordinary long-term subscribers.

How the check works

1. Normalize for matchingCompare a consistent address representation while preserving the source row.
2. Consult risk intelligenceCheck known address and domain classifications associated with trap risk.
3. Isolate recognized riskReturn a specific status instead of allowing a risky match into the deliverable export.

What the result cannot prove

Trap operators do not publish complete inventories, and some traps are indistinguishable from normal mailboxes. Claims to detect every spam trap should be treated with caution.

How to use the result

Suppress known matches, trace them back to their source and review how consent, imports and list aging are managed. Do not repeatedly reintroduce removed records from older exports.

How the check works

1. Create a consistent matchNormalize the address for a reliable lookup without changing the source record.
2. Check historical intelligenceLook for a known complaint-risk classification tied to the address.
3. Separate the outcomePrevent a known match from blending into the normal deliverable population.

What the result cannot prove

Historical intelligence cannot predict every future complaint and does not explain the context of every previous complaint. The absence of a match is not permission to send.

How to use the result

Honor existing suppressions, verify how the address was collected and improve sender identity, frequency and unsubscribe handling. Investigate clusters by acquisition source.

How the check works

1. Query DNSRequest the current MX records for the normalized domain.
2. Inspect the targetsEvaluate priorities and whether the advertised mail hosts resolve correctly.
3. Choose the next checkStop clear infrastructure failures or continue toward mailbox-level verification.

What the result cannot prove

DNS can change quickly, be temporarily unavailable or use unusual fallback behavior. An MX pass is a domain-level result only and cannot confirm the recipient mailbox.

How to use the result

Exclude permanent no-MX outcomes from a normal send. Retry only when the result indicates a temporary DNS or infrastructure problem rather than a confirmed absence.

How the check works

1. Normalize the domainApply domain-name rules and convert it to a consistent lookup form.
2. Resolve DNSCheck whether authoritative DNS answers and relevant records are available.
3. Classify domain healthSeparate unavailable domains from those ready for mail-routing and mailbox checks.

What the result cannot prove

A live domain does not prove that it accepts email, and a working website is neither required nor sufficient. Results also reflect DNS state at a particular moment.

How to use the result

Ask the data owner to confirm a likely misspelling instead of automatically changing it. Suppress confirmed unavailable domains and retry only genuinely temporary DNS outcomes.

How the check works

1. Confirm mail infrastructureEstablish that the domain can receive mail before evaluating recipient behavior.
2. Compare recipient responsesObserve whether the server distinguishes the submitted mailbox from an unlikely control recipient.
3. Preserve uncertaintyReturn a catch-all classification when recipient existence cannot be proven.

What the result cannot prove

Server security, greylisting, gateways and temporary policy responses can resemble catch-all behavior. The true delivery outcome may only become visible after a real send, which verification does not perform.

How to use the result

Segment catch-all results. Use source quality, consent, engagement value and controlled sending risk to decide whether to retain, test cautiously or suppress them.

How the check works

1. Collect prior evidenceUse syntax, domain, routing and internal status results already produced.
2. Evaluate mailbox signalsInterpret recipient-level responses without sending an actual message.
3. Separate permanent failureKeep confirmed non-deliverable addresses out of the normal deliverable result set.

What the result cannot prove

Mailbox state changes, providers can hide recipient information and SMTP responses can be temporary. Verification reduces risk but cannot guarantee that a future message will be accepted or reach the inbox.

How to use the result

Suppress permanent failures and retain the reason. Retry temporary outcomes according to a controlled policy rather than repeatedly mailing an address that has already hard bounced.

How the check works

1. Receive network contextUse the source IP only when it was lawfully collected and supplied to the relevant workflow.
2. Compare current intelligenceCheck whether the IP is classified as a known Tor exit node at that time.
3. Add—not replace—contextReturn the signal for a wider risk policy without changing mailbox deliverability by itself.

What the result cannot prove

Exit-node lists and IP assignments change. VPNs, proxies and shared networks are different signals, and network location cannot establish a person’s identity or intent.

How to use the result

Use the signal proportionately, disclose relevant data handling and combine it with account, consent, payment and behavioral evidence. Do not call the email address invalid because of network origin.