Comprobación DNS del correo

Whether mail for a domain arrives, and whether mail claiming to come from it is believed, is decided almost entirely by a handful of DNS records. This tool reads all of them in one go.

MX records name the servers that receive mail for the domain, in order of preference (lower numbers first). Each MX host must itself have an A or AAAA record; the tool resolves the first five. A single MX of 0 . is a null MX (RFC 7505): the domain says it accepts no mail at all.

SPF (RFC 7208) is a TXT record starting with v=spf1 that lists the servers allowed to send as the domain: address ranges (ip4:, ip6:), other domains’ lists (include:) and a final rule for everything else, normally -all (fail) or ~all (softfail). A domain may publish only one SPF record, and evaluating it may take at most ten DNS lookups, counting every include, a, mx, ptr, exists and redirect — including the ones inside included records. Past ten, receivers return a permanent error, which is how large lists of cloud senders quietly break SPF.

DMARC (RFC 7489), at _dmarc.<domain>, tells receivers what to do with mail that fails both SPF and DKIM alignment — nothing (p=none), spam folder (quarantine) or refuse (reject) — and where to send aggregate reports (rua=). Starting with p=none and reading the reports before tightening is the usual path.

MTA-STS (RFC 8461) and TLS reporting (RFC 8460) ask sending servers to require TLS and to report failures. The DNS record only announces that a policy exists; the policy itself is a file on mta-sts.<domain> that this tool does not fetch.

DKIM keys sit at <selector>._domainkey.<domain>. The selector is chosen by whoever signs the mail, so it cannot be discovered from DNS: find it as s= in a received message’s DKIM-Signature header and enter it above.

Everything here comes from public DNS through our resolver. No connection is made to the domain’s mail servers.