Advanced diagnosis of a domain's records

MXToolbox brings together DNS lookups and external email and network tests. It is useful for seeing what response a third party gets, but that response may come from a caching resolver and doesn't replace querying the authoritative DNS servers directly.

Before checking a record:

1. Identify which DNS servers are delegated for the domain.
2. Confirm that you are editing the zone served by those servers. If the domain uses Cloudflare or another DNS provider, changing only cPanel's Zone Editor doesn't change the public DNS.
3. Query the record on each authoritative server.
4. When the authoritative servers are consistent, use MXToolbox or other external resolvers to check what response they see from outside.

For example, moving email to Google Workspace means replacing the MX records in the authoritative DNS zone, not necessarily in cPanel. After copying the values Google gives you, you can run an external check by entering:

mx:dominio.com

mx is the type of check and dominio.com is the name to query. Compare the result with the values and priorities provided by the email provider.

If you have dig, you can query the delegation and the authoritative servers first:

dig dominio.com NS +trace
dig +nssearch dominio.com
dig @ns1.proveedor.com dominio.com MX +norecurse
dig @ns2.proveedor.com dominio.com MX +norecurse

Replace the servers, the domain and the MX type with the ones that apply. If the authoritative servers return different values or SOA serial numbers, fix that inconsistency first; it isn't a user cache.

If you don't have dig, IPeek's DNS check, a free external tool, shows the delegation published by the parent zone, whether each authoritative server answers authoritatively and whether their SOA serial numbers match. To compare the value of a specific record on each server you still need to query directly.

For a TXT record, use txt:dominio.com and compare the name and full value with those requested:

The checks available include:

a: Looks up the IPv4 address published in the A record
aaaa: Looks up the IPv6 address published in the AAAA record
mx: Looks up the mail servers and their priorities
txt: Looks up the TXT records published under the given name
spf: Checks the SPF policy published in a TXT record
dkim: Checks the DKIM record for the given selector
dmarc: Checks the DMARC policy published under _dmarc
cname: Shows the canonical name an alias points to
ptr: Runs a reverse DNS lookup for an IP address
soa: Gets the zone's start of authority record
dns: Checks the delegation and other problems detected by MXToolbox
smtp: Tests the server's SMTP response on port 25
http: Checks the HTTP response of a URL
https: Checks the HTTPS response of a URL
tcp: Tests a TCP connection to the given host and port
ping: Runs an ICMP test from MXToolbox's infrastructure
trace: Runs an ICMP trace from MXToolbox's infrastructure
blacklist: Checks the blocklists built into MXToolbox
asn: Looks up the autonomous system related to an IP address
arin: Looks up registration information for an IP address block
whois: Shows the registration lookup offered by MXToolbox

SPF is currently published in TXT records; you shouldn't create an SPF-type DNS record. blacklist only reports on the lists MXToolbox checks and doesn't establish a universal reputation.

For generic domains such as .com, .net or .org, use ICANN Lookup, based on RDAP, as the current source of registration data. Since 28 January 2025, RDAP has replaced WHOIS as the definitive source for gTLDs. Country-code domains, such as .es, may use the registration lookup service set up by their own registry.

Each test only confirms the observation it shows. A correct MX doesn't prove the mailbox exists, an SMTP check from MXToolbox doesn't reproduce the user's connection, and no response to ping doesn't prove the service is down. To attribute a cause, relate the DNS result to the service test and its exact response or log.

Query the exact name

A verification TXT at the root, a TXT at _dmarc.dominio.com and the DKIM at selector._domainkey.dominio.com are different queries. For DKIM you need the selector used by the sender; a lookup at the root doesn't prove the signature is missing.

If SERVFAIL appears, compare the authoritative response and DNSSEC validation before changing records again. Turning off validation on one computer doesn't fix a broken DNSSEC chain for everyone else. Keep the full output, including the status and the server queried; the SOA serial number alone doesn't prove that every record is identical either.