A DNS lookup is a question to the Domain Name System: which records of a given type are published at this name? The web and email run on such questions. A browser looks up the A or AAAA record of a host name to get its IP address; a mail server looks up the MX records of the recipient's domain to learn which servers accept its email.

This tool sends the question to a recursive resolver: a DNS server that does the work for the one asking, following referrals from name server to name server until it reaches the domain's own, and returns their answer or an error (RFC 1034 §2.4 and §4.3.1). Ours runs on the same server as this site and asks the domain's name servers itself, without a public resolver in between. The resolver that answered each query, and the raw answer, are in the Raw evidence panel under the result.

With the record type left on ALL, we look up eight common types, A, AAAA, CNAME, MX, NS, TXT, SOA and CAA, with one query per type sent at the same time. We never send the DNS “ANY” query instead: a server may answer it with only some of the records, and nothing in the answer says that the rest is missing (RFC 8482 §4.1). Choose a type in the menu, or write it before the name as in mx:example.com, to ask for just that type; this also reaches PTR, SRV, DS, DNSKEY, TLSA, HTTPS and SVCB.

One lookup covers one name. Records at www.example.com, _dmarc.example.com or selector._domainkey.example.com are separate names: look each of them up on its own.

DNS record types at a glance

The examples from A to PTR are answers we got on September 26, 2026 for example.com, www.github.com, gmail.com, google.com and 8.8.8.8; the SRV example is the one Microsoft gives for Microsoft Teams. Sources: RFC 1035 for the classic types, RFC 3596 (AAAA), RFC 8659 (CAA), RFC 2782 (SRV), RFC 4034 (DNSKEY, DS), RFC 6698 (TLSA) and RFC 9460 (HTTPS, SVCB).

The result opens with the verdict, a colored icon and a short label, together with the data that decided it. A DNS lookup ends in one of three verdicts: Pass, Warning or Could not check. There is no Fail: a lookup reports what DNS publishes, and whether that setup is right is for checks such as the DMARC checker or the email domain check.

Pass: records found

At least one query came back with records, no query failed, and none of the warnings below applies. With ALL, the types that have none are listed under Types without records, each with what the resolver said. That is normal: many domains publish no CAA or AAAA records, and the CNAME type is empty for every name that is not an alias. For an IP address, Pass means it has a reverse DNS name that points back to it (see below).

What each part of the result shows

• Alias chain. When the name is an alias, the chain is drawn once above the records, for example www.github.com to github.com. The records under it belong to the name at the end of the chain, and the result shows that name next to them.
• A and AAAA. Several addresses at one name are normal. Records of one type at one name form a set that is always returned together (RFC 2181 §5.1), and each address in it is a valid answer.
• MX. Each mail server has a preference; lower values are preferred (RFC 1035 §3.3.9). A single record 0 . is a null MX: the domain accepts no email (RFC 7505). The MX lookup also shows each mail server's addresses and reverse DNS.
• NS. The name servers that answer for the zone. Only the top of a zone has NS records, so a subdomain that is not a zone of its own shows none.
• TXT. Each record as published, in quotes, with a label when we recognize it, such as SPF, DMARC, DKIM or a verification token. The TXT record lookup explains the labels.
• SOA. We name each field. The primary server (MNAME). The contact mailbox (RNAME), which DNS writes with a dot in place of the @, so dns.cloudflare.com means dns@cloudflare.com (RFC 1034 §3.3). The serial, which goes up with every change to the zone, and the refresh, retry and expire timers that secondary name servers follow (RFC 1034 §4.3.5). Minimum limits how long resolvers may keep a “no such record” answer from the zone; the SOA record's own TTL can make that shorter (RFC 2308 §5).
• CAA. Flags, tag and value. issue names a certificate authority that may issue certificates for the name, issuewild does the same for wildcard certificates, and iodef says where to report requests that break these rules; 0 issue ";" allows no authority to issue certificates, unless another issue record names one, because authorizations add up; wildcard certificates follow the issuewild records when there are any (RFC 8659 §4.2 to §4.4). When a name has no CAA records, certificate authorities look at its parent names in turn (RFC 8659 §3), so an empty CAA answer for www.example.com can still mean that the records of example.com apply. Cloudflare says the CAA records it adds for its Universal SSL certificates do not appear in its dashboard, so a lookup can show CAA records you never added yourself.
• DNSSEC and newer types. DS and DNSKEY records are shown with their fields. TLSA, HTTPS and SVCB records are shown in the generic form of RFC 3597 (\#, the length, then the data in hex), exactly as received.

TTL: the time left in the resolver's cache

Next to every record is its TTL in seconds, the time a resolver may keep the record before asking again (RFC 1035 §3.2.1). We show what is left at the resolver we asked, so the number is often lower than the TTL set at your DNS host and shrinks from one lookup to the next. After you change a record, resolvers that cached the old one can keep serving it until their copy runs out. This page also reuses a result for 60 seconds, except a Could not check result, which is never reused, so you can try again right away.

Warning: no records found

The resolver answered, and there were no records: for one type, none of that type; with ALL, none of the eight types. The result says which answer came back. NXDOMAIN means the name does not exist. NODATA (NOERROR with an empty answer) means no records of that type; it does not prove that the name exists, because some DNSSEC-signed zones give this answer for names that do not exist (RFC 9824). We saw it on September 26, 2026: an A query for a made-up name under example.com came back NOERROR with no records. The usual reasons for a missing record:

• a typo in the name, or a missing prefix such as _dmarc. or www.;
• the record was added at a DNS host the domain does not use. Look up ns: with your domain, such as ns:example.com, to see which one it uses;
• the name was doubled. Some dashboards add your domain to whatever you type in the name field, so a full name typed there ends up as www.example.com.example.com;
• the record is new, and the resolver still remembers the earlier “no record” answer (negative caching). The result shows how much longer the resolver we asked may keep it. Other resolvers count their own time, up to the limit in the zone's SOA record.

Warning: the alias leads to a name that does not exist

The name has a CNAME record, DNS follows it, and the name at the end of the chain does not exist. When an alias chain ends in an error, the error is about the last name of the chain, not the name you typed (RFC 6604 §3), so the fix belongs to whoever owns that last CNAME: point it at a name that exists, or delete it when the service it pointed to is gone. With the type on ALL, the result still lists the CNAME record itself, and every other type comes back as NXDOMAIN at the end of the chain; that is this warning too, not a Pass. We can tell only from an NXDOMAIN answer. Some DNS hosts answer NODATA even for names that do not exist (see above), and then such an alias shows up with no records at its target instead of this warning.

Warning: a CNAME at the top of the zone

The name is the top (apex) of its DNS zone, such as example.com itself, and it has a CNAME record. The apex must hold the zone's SOA and NS records (RFC 1034 §4.2.1), and a name with a CNAME may hold nothing else (RFC 2181 §10.1). Some DNS servers then refuse the other records, and MX and TXT records at the apex go with them (RFC 1912 §2.4 describes BIND doing this). Put A and AAAA records at the apex instead, or use your DNS host's apex alias feature, such as Cloudflare's CNAME flattening.

Warning: a CNAME next to other records

A server returned a CNAME at this name together with records of other types. A CNAME turns the name into an alias, and an alias may hold no other records (RFC 1034 §3.6.2, RFC 2181 §10.1), so resolvers can disagree about what the name holds. Keep either the CNAME or the other records. Records shown under an alias chain are not such a conflict: they belong to the name the alias leads to.

IP addresses: reverse DNS (PTR)

Enter an IP address and we look up its reverse DNS: the PTR record at the address's name under in-addr.arpa (IPv4) or ip6.arpa (IPv6). For 8.8.8.8 that name is 8.8.8.8.in-addr.arpa, and its PTR record is dns.google. This works with the type on ALL or PTR; other types are refused for an address, because an address has no MX or TXT records of its own. Warning means there is no PTR record, or it holds something that is not a usable host name. Reverse DNS is published by whoever controls the address block, usually the hosting provider or ISP, not in your domain's zone (RFC 1035 §3.5), so ask them to set it.

Forward-confirmed reverse DNS

For each PTR name we look up its A record (AAAA for an IPv6 address) and check that it includes the address you entered. Pass: at least one name points back. Warning: none of the names we checked points back. Could not check: a forward lookup got no usable answer, or the address has more than 10 PTR names and none of the first 10 points back; we check only those, because a checker must limit the names it follows (RFC 8601 §3). Receiving mail servers can run this test on the servers that connect to them, and RFC 8601 §3 notes that a connection that fails it is often simply rejected.

Could not check

At least one query got no usable answer: it timed out, the resolver reported a server failure (SERVFAIL) or refused the query, or the answer could not be decoded safely. That says nothing about whether the records exist, and we never count it as a pass or a warning. With ALL, one failed type is enough for Could not check, because the picture is incomplete; the types that answered are still shown, and the failed ones are listed with the reason. SERVFAIL covers many errors (RFC 8914 §1). One of them is DNSSEC: a resolver that validates signatures answers SERVFAIL when they do not validate (RFC 4035 §5.5), for example after a DNS host change that left an old DS record at the registrar. The DNS propagation checker asks several public resolvers, which shows whether the failure is everywhere.

Could not check: a fault on our side

Rarely, the result says the check could not be completed because of an internal error. That is a fault in our software, not a finding about your domain and not a network problem, so trying again will most likely give the same result. Please write to support@mxverdict.com with the address of the result page, and we will fix it.

A lookup shows what is published. To change it, edit the records at your DNS host:

1. Find your DNS host. It is the provider your NS records name, which is not always the company you bought the domain from. Records added anywhere else have no effect.
2. Enter the name the way your DNS host expects it. At Cloudflare, GoDaddy and Namecheap that is the name without your domain: @ for the domain itself, www for www.example.com, _dmarc for _dmarc.example.com. Other hosts can differ; Amazon's SES guide warns that some add your domain to the name without saying so.
3. Pick the type, then fill in what that type holds: an address for A and AAAA, a target name for CNAME, a priority and a mail server for MX, the text for TXT, and a flag, a tag and a certificate authority for CAA.
4. Mind the TTL before a planned change. Resolvers may keep the old record for as long as its TTL allows, so lower the TTL in advance, at least one old TTL before the switch (a day ahead if it was 86,400 seconds), and raise it again afterward.
5. Look the name up again here. If the old value still shows, the TTL next to it says how much longer, at most, the resolver we asked may keep it.

Cloudflare

1. In the Cloudflare dashboard, open your domain and go to the DNS Records page.
2. Select Add record and choose the Type.
3. Fill in the fields of that type. For the domain itself, use @ as the Name. The Proxy status setting exists only for A, AAAA and CNAME records.
4. Select Save. To change a record later, select Edit next to it, change it and save; Delete is there as well.

Cloudflare creates the SOA record itself, so you do not add one. For a CAA record, choose a Tag and enter the CA domain name, one record per certificate authority. When you use Universal SSL and add any CAA record, Cloudflare adds CAA records of its own, and those do not appear in the dashboard.

GoDaddy

1. Sign in to your GoDaddy Domain Portfolio and select the domain to open its Domain Settings.
2. Select DNS, then Add New Record, and choose the type in the Type menu.
3. In Name, enter @ for the root domain or a prefix such as blog; fill in the value and the TTL. A CAA record also asks for a Flag (0 or 128), a Tag (issue, issuewild or iodef) and the certificate authority, or a semicolon to allow none.
4. Select Save (Save All Records when you added several). To change a record, select Edit next to it.

These records are used only while the domain uses GoDaddy's nameservers.

Namecheap

1. Sign in, open Domain List, and select Manage next to your domain.
2. Open the Advanced DNS tab and, under Host Records, select Add New Record.
3. Choose the type and enter the Host: @ for the domain itself, or only the subdomain part. Fill in the value (for CAA, the Tag issue, issuewild or iodef and the certificate authority) and save the record.

Host records there work only while the domain uses Namecheap BasicDNS, PremiumDNS or FreeDNS; the nameservers themselves are chosen in the Nameservers section of the domain's Manage page and saved with the green check mark.

Records that email services ask for

Email services give you their records to add at your DNS host. Copy the exact values from their admin pages; this is the form their documentation shows (checked September 26, 2026):

Check each record with a typed lookup, such as mx:example.com or cname:selector1._domainkey.example.com. Keep a single SPF record, as Microsoft's guide also asks: add a new service's include: to it rather than a second record. The MX lookup, TXT record lookup and CNAME lookup explain those records in depth.

1. Enter the domain in the form at the top of this page, for example example.com. A pasted web address or email address works too: we take the domain out of it.
2. Leave the record type on ALL to view the eight common types at once, or choose one. You can also type the type before the name: mx:example.com, txt:_dmarc.example.com, caa:example.com.
3. Select Check. The records come grouped by type, each with its TTL; types without records say what the resolver answered.

Every result has its own address that you can send to someone; opening it looks the name up again, so they see the records as they are then. The record type is part of the address: /dns-lookup/mx:example.com is the MX lookup of example.com (the colon may appear as %3A), and /dns-lookup/example.com, with no type, looks up all eight common types.

A lookup shows the view of one resolver. If a change shows here but not for someone else, their resolver may still hold the old answer; the DNS propagation checker asks several public resolvers at once.

On macOS and Linux, dig asks for one type per command, and +short prints only the values; -x does the reverse lookup of an address:

dig example.com A +short
dig example.com SOA +short
dig google.com CAA +short
dig -x 8.8.8.8 +short

On September 26, 2026 they printed:

172.66.147.243
104.20.23.154
elliott.ns.cloudflare.com. dns.cloudflare.com. 2415729022 10000 2400 604800 1800
0 issue "pki.goog"
dns.google.

The dot at the end of a name is the root of DNS; this page leaves it out. Put a resolver before the name, as in dig @1.1.1.1 example.com TXT +short, to ask that resolver instead of your network's.

nslookup works on Windows, macOS and Linux; a resolver address at the end picks the server. For an SOA record it names the fields, with different labels: on macOS origin, mail addr, serial, refresh, retry, expire and minimum; on Windows primary name server, responsible mail addr, serial, refresh, retry, expire and default TTL.

nslookup -type=SOA example.com
nslookup -type=NS example.com 1.1.1.1

In Windows PowerShell:

Resolve-DnsName -Name example.com -Type SOA
Resolve-DnsName -Name example.com -Type MX -Server 1.1.1.1

Microsoft's documentation lists the values -Type accepts: CAA is not among them, and -Type ALL there is the single ANY query (type 255), not the eight separate queries this page makes.