Query the domain, not the whole address

Parse the address safely and extract its domain. Convert an internationalized domain to the DNS form required by your IDNA library. Query MX with bounded time, answer count, and retries. Record resolver, status, answer, TTL, and UTC time.

An MX answer contains preferences and hostnames. Lower numeric preference is tried first. Resolve those hostnames to usable addresses through the normal mail-routing algorithm; an MX name that has no address can make it unusable.

Distinguish routing states

Use explicit outcomes:

  • MX available: one or more usable exchanges were returned.
  • Null MX: a single MX with preference 0 and target . explicitly says the domain accepts no mail.
  • No MX but domain usable: RFC 5321 defines an implicit MX behavior using the domain itself when no MX records exist, subject to address availability.
  • Domain does not exist: authoritative negative result.
  • DNS unavailable/temporary error: timeout or SERVFAIL; keep the result unknown.
  • MX unusable: records exist but their targets cannot be used.

Do not convert every empty MX answer into “invalid domain” without checking the implicit rule. Do not treat a temporary resolver failure as a permanent negative.

Keep routing separate from mailbox existence

user@example.com and other@example.com share domain routing. MX tells you where SMTP delivery would be attempted, not whether either local part exists. Catch-all behavior, anti-enumeration responses, greylisting, policy rejection, and delayed acceptance make SMTP probing ambiguous.

Avoid using VRFY as a general verification mechanism; servers may disable it for security. Never send a message or issue bulk recipient probes without authorization, abuse controls, and a clear purpose.

Present bounded evidence

Return the observed routing state, hosts (if appropriate), observation time, and limitations. For product use, a null MX or authoritative nonexistent domain can support a clear negative domain result. Usable MX supports only “mail routing is advertised,” not “mailbox valid.”

Retest DNS on later submissions rather than storing a permanent verdict, because domain configuration changes. The result is trustworthy when unknowns remain unknown and the UI does not inflate domain-level evidence into certainty about a person’s mailbox.