What DNS Records Reveal About a Lookalike Domain: A, MX, NS

Why DNS comes first in a sweep

A lookalike check begins with thousands of candidate names, almost all of which do not exist. Registration lookups are far too expensive to run against that many, and most registries would rate-limit you long before you finished.

DNS is the opposite: fast, cheap, and answerable in parallel. Resolving every candidate reduces a list of thousands to the few dozen that exist, and only those need the expensive enquiries. A public resolver over DNS over HTTPS will answer thousands of queries in the time a single registry would take to answer a hundred.

So DNS is not just one source among several. It is the filter that makes the rest affordable, and the answers it gives along the way are evidence in their own right.

The record types worth checking, and what each signals

A and AAAA

The IPv4 and IPv6 addresses the name points at. An address means something is reachable. It does not mean a website exists, and it certainly does not mean the content is hostile: parked names have addresses too.

NS

The nameservers the registry has delegated the name to. Two uses: a name with nameservers is registered even if nothing else is published, and nameservers matching your own are a strong hint that the name is one of yours.

MX

Where mail for the name is delivered. This is the record that changes a triage decision most often, because publishing mail routing is a deliberate act with a purpose. A lookalike that can receive mail is set up for something involving people replying to it.

TXT

Unstructured text, in practice mail authentication policy and service verification tokens. A lookalike carrying an SPF record has been configured by somebody who intends to send.

CNAME

An alias to another name. Useful because it points at the infrastructure behind a variation, which frequently connects several findings to one operator.

Nameservers but no A record: the dormant case

One combination deserves its own name. A domain that has nameservers but no A record has been registered and delegated, and nothing has been published on it yet. Ask for its NS records and you get an answer; ask for its address and you get a successful response with nothing in it.

Troubleshooting guides treat this as a fault, and for your own domain it is. On a lookalike it is a state, and an early one. Someone has bought the name and pointed it at a DNS provider, and has not yet put anything there. A check that only reports names with addresses will miss this state entirely, which is why dormant registrations are worth keeping as findings rather than discarding as empty.

The same logic applies in reverse later. A finding that was dormant last week and has an address and mail records this week has changed in the direction that matters, and a monitoring process should treat that change as more urgent than a new discovery. The registration record will not tell you this happened; only comparing two DNS answers will.

A registry can also show a name as registered while its status is inactive, meaning no nameservers are delegated at all. That is one step earlier than dormant: bought, not yet pointed anywhere.

What MX records on a lookalike domain mean

An MX record names the host that accepts mail for the domain. Nobody publishes one by accident: it has to be added, and it only matters if somebody expects mail to arrive. On a lookalike, that expectation is the finding. A name that can receive mail is prepared for replies, for password-reset messages, or for people who answer a message rather than click a link.

Read the target as well as the fact. An MX pointing at a large hosted mail provider means an account was created there for this name, which is a small but real investment. An MX pointing at the lookalike's own address means the operator runs their own mail server. Several findings sharing one MX target were almost certainly configured by one person.

There is one MX record that says the opposite. RFC 7505 defines the Null MX, a single record with preference 0 and an exchange of a lone dot, and its meaning is that the domain accepts no mail. example.com publishes exactly that: ask for its MX and the answer is 0 and a dot. A lookalike with a Null MX has been deliberately closed to incoming mail, which is unusual and worth noting either way.

SPF and DMARC as evidence of intent to send

MX is about receiving. Two TXT records are about sending, and a lookalike that carries them has been set up to get mail delivered from that name rather than merely to collect it.

SPF, from RFC 7208, must be published as a TXT record at the domain itself and lists which hosts may send mail using the name. A lookalike with an SPF record that includes a bulk mail provider has been connected to that provider's sending infrastructure. DMARC, from RFC 7489, lives in a TXT record at the _dmarc subdomain and tells receivers what to do with mail that fails authentication. Operators add it because mail from a domain without it is more likely to be filtered, so its presence on a lookalike is a sign that deliverability was considered.

Neither record proves anything on its own; every legitimate business publishes both. The point is the combination. A recent registration with an MX, an SPF record naming a sending service and a DMARC policy is a name that somebody configured to send and receive mail, and that is a stronger statement of purpose than an address alone.

SPF record shape

example.com. 300 IN TXT "v=spf1 include:_spf.example.org -all". The include names a sending service; -all says nothing else may send. example.com itself publishes "v=spf1 -all", which says nobody may send as it.

DMARC record shape

_dmarc.example.com. 300 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com". The p tag is the policy; reject asks receivers to refuse mail that fails. example.com publishes p=reject.

NXDOMAIN, NODATA and SERVFAIL: an answer that is not an answer

DNS distinguishes between a name that does not exist and a name that exists with nothing published, and conflating them loses information. RFC 2308 gives the two cases their names.

NXDOMAIN, response code 3, means the name is not in the zone at all. NODATA is a successful response, code 0, with no records of the type you asked for: the name exists and has nothing of that kind, no mail, or no address, which as above is itself a finding. A DoH resolver reports the first as Status 3 and the second as Status 0 with an empty Answer.

Then there are non-answers: SERVFAIL, code 2, a timeout, a truncated response. As with registration lookups, a tool that records these as nothing found has manufactured a negative. The honest handling is to keep them unknown and say so.

One more subtlety applies to hosting platforms. Many public platforms answer DNS for every possible subdomain whether or not anyone has claimed it, so a DNS answer alone proves nothing there. Names of that shape need an HTTP check to confirm that somebody actually claimed them.

Run it yourself

Every query in this guide can be made from a browser address bar or a terminal. The DoH JSON endpoint at cloudflare-dns.com answers a GET request with a name and type parameter, provided the request carries an Accept header of application/dns-json; dns.google/resolve answers the same shape without the header. The dig command gives the same answers from a terminal. The shapes below are real answers for example.com.

curl -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=example.com&type=MX'

{"Status":0,"TC":false,"RD":true,"RA":true,"AD":true,"CD":false,"Question":[{"name":"example.com","type":15}],"Answer":[{"name":"example.com","type":15,"TTL":300,"data":"0 ."}]}. Status 0 is success; type 15 is MX; data is the record; TTL is how long a cache may keep it. Change type to A, AAAA, NS, TXT or CNAME for the others.

The same query for a name that does not exist

{"Status":3,"TC":false,"RD":true,"RA":true,"AD":true,"CD":false,"Question":[{"name":"this-name-does-not-exist.example","type":1}],"Authority":[{"name":"","type":6,"TTL":86400,"data":"a.root-servers.net. nstld.verisign-grs.com. 2026092201 1800 900 604800 86400"}]} with no Answer member at all; the Authority section carries the SOA of the zone that denied the name, here the root. Status 3 is NXDOMAIN. A name that exists but has no record of the type asked for returns Status 0 with no Answer, which is NODATA.

dig example.com A

example.com. 300 IN A 104.20.23.154 and a second A record; the header line shows status: NOERROR.

dig example.com NS

example.com. 21600 IN NS elliott.ns.cloudflare.com. and hera.ns.cloudflare.com. A name that answers here but returns nothing for A is dormant.

dig example.com MX

example.com. 300 IN MX 0 . which is the Null MX: no mail accepted.

dig example.com TXT

example.com. 300 IN TXT "v=spf1 -all" plus any verification tokens. For DMARC, dig _dmarc.example.com TXT returns "v=DMARC1;p=reject;sp=reject;adkim=s;aspf=s".

dig this-name-does-not-exist.example A

Header shows status: NXDOMAIN, ANSWER: 0. The name is not in the zone. Compare status: NOERROR with ANSWER: 0, which is NODATA.

First seen and last seen

A DNS answer is true at the moment it was retrieved and at no other. Records have lifetimes, the TTL in every answer, and change without notice, so a single answer is a snapshot. Evidence comes from keeping two things with every record: the first time you saw it and the last time you saw it.

First seen is when a name, an address or a mail record entered your records. For a lookalike it is usually the closest thing you have to the moment of preparation, and it is often earlier than the first time anybody complained. Last seen is the most recent confirmation that the record was still there. A record whose last seen stops advancing has gone, and a name whose address changed between two observations has moved.

The checker on this site keeps those two dates for every finding and every re-check, resolves candidates over DNS over HTTPS, and lists what appeared, changed or vanished since the previous report, which is how a dormant finding that came alive is surfaced rather than lost.

Reading infrastructure across findings

The most useful thing DNS offers is not any single record but the overlap between findings. Several variations sharing an address, a nameserver set or a mail provider are probably one operator, and that reframes the review: instead of thirty separate decisions you have one, about a group.

It also helps in the benign direction. A cluster of findings sharing your own registrar and nameservers is almost certainly your own defensive portfolio surfacing, and marking the group settles it in one action.

What DNS cannot establish

DNS says where a name points, not what is served there. It gives no content, no ownership and no intent. An address in a particular country tells you where a host is, which is weak evidence about anything, because hosting is a commodity bought from anywhere.

And every record here is consistent with an innocent explanation. Businesses register near-miss spellings of their own name and leave them dormant; a mail-enabled lookalike may be a reseller or an unrelated company with a similar name. The records order what to look at first. They do not say what you will find.

Common questions

what does it mean if a domain has nameservers but no a record

The domain is registered and delegated to a DNS provider, but no address has been published, so nothing is reachable at it yet. For your own domain that is a misconfiguration. For a lookalike it is a dormant registration: bought and pointed somewhere, not yet used, and worth watching for the moment an address appears.

what do mx records on a lookalike domain mean

Someone has configured the name to receive mail, which has to be done deliberately. It suggests the name is prepared for replies or account messages rather than only for a web page. Combined with a recent registration and an SPF record it describes a name set up to send and receive as a brand.

what is the difference between nxdomain and nodata

NXDOMAIN, response code 3, means the name does not exist in the zone at all. NODATA is a successful response with no records of the type requested: the name exists but has, for example, no address or no mail routing. A DoH resolver shows them as Status 3 and Status 0 with an empty Answer.

how do i check dns records without visiting a site

Query a public resolver over DNS over HTTPS. A GET to https://cloudflare-dns.com/dns-query?name=example.com&type=MX with an Accept header of application/dns-json returns the answer as JSON, and dns.google/resolve does the same. Neither contacts the domain itself; they ask the DNS system about it.

does an spf record on a lookalike domain prove phishing

No. Every legitimate domain that sends mail publishes SPF, and many defensive registrations carry one by default. It is evidence that somebody configured the name to send, which raises review priority when the registration is recent and mail routing is present. It is never proof of intent.