DNS email validation: MX, A, and TXT record checks

DNS email validation is the process of querying DNS servers for the domain part of an email address (everything after the @) to confirm that mail can actually be delivered there. The validator asks DNS: does this domain have mail infrastructure? No MX records and no A records means no delivery path. The address is invalid; no further checking is needed.

Where DNS fits in the validation pipeline

Full email validation runs in stages. First comes syntax: is the address format correct? Second is DNS validation: does the domain exist and can it receive mail? Third is SMTP verification: does that specific mailbox exist on the server?

DNS validation is the second stage. A DNS query takes milliseconds; an SMTP dialog takes seconds. Running DNS first discards addresses with no mail infrastructure before the validator spends resources on an SMTP connection that would fail anyway.

MX record lookup

An MX (Mail Exchange) record names the server that handles incoming mail for a domain. When a message goes to user@example.com, the sending mail server first queries example.com's MX records. They say: “deliver mail for this domain to mail.example.com at priority 10.”

If no MX records exist, that does not automatically mean the domain rejects mail. RFC 5321 says a sender may fall back to the domain's A record when MX is absent. In practice, missing MX is a strong signal: the domain probably was not set up to receive email.

A domain can publish multiple MX records at different priority numbers. Lower numbers get tried first; higher-numbered records act as backups. The validator only needs to confirm at least one record is present and the named host is reachable.

Fallback to the A record

An A record maps a domain name to an IP address. When MX records are absent, the validator checks for an A record. Its presence means the domain has a server that could theoretically accept mail on port 25.

In practice, this is a weak signal. Many domains have an A record (pointing at a web server) but no mail server listening on port 25. An A record without MX warrants an SMTP probe, not a pass or fail decision on its own.

Reading TXT records

TXT records store free-form text about a domain. Three TXT-based records matter for email: SPF, DKIM, and DMARC. Their presence is not required to receive mail, but gives the validator extra signal about how the domain is used.

An SPF record (starting with v=spf1) lists the servers authorized to send mail on the domain's behalf. A domain that publishes SPF has had its mail authentication configured by someone — indirect evidence that email is actively used.

A DMARC record (_dmarc.domain.com) defines how receivers should handle messages that fail authentication. Its presence indicates a mature mail setup.

Validators can use TXT records as a confidence signal. A domain with SPF, DKIM, and DMARC configured is almost certainly a legitimate business. A domain registered yesterday with no TXT records is worth treating with suspicion, even if MX exists.

What DNS validation does not check

DNS validation checks the domain, not the local part (the username before @). A domain can have perfect MX records while the specific mailbox nonexistent@example.com simply does not exist. Confirming that requires an SMTP check.

DNS also cannot detect catch-all configuration. A domain may accept mail addressed to any username, and nothing in DNS reveals that.

DNS results are cached according to each record's TTL. If a domain removed its MX records recently, a resolver's cache may still return the old data for a while. Production validators account for TTL when deciding whether to re-query.