What is a DNS lookup? A guide to A, MX, TXT, CNAME and NS records

James Bruckel·CEO, Wuluf

A DNS lookup retrieves the records published for a domain name. Those records tell internet services where to find a website, where to deliver email, which names are aliases and which name servers are authoritative for the domain. They can also publish security policies and ownership-verification information.

Use Wuluf's free DNS Lookup to query the live A, AAAA, MX, TXT, CNAME and NS records for any domain. This guide explains what each result means, what commonly goes wrong, and when a DNS record deserves closer investigation.

DNS is more than the internet's phone book

The Domain Name System, or DNS, is often described as the internet's phone book. The analogy is useful: people remember a name such as example.co.uk, while computers need technical information such as an IP address to make a connection.

But modern DNS does much more than translate names into addresses. Its records can tell other systems:

• where a website or application is hosted
• which servers should receive email
• which providers may send email for the domain
• where a service or subdomain should redirect
• which name servers control the DNS zone
• whether a domain owner has completed a verification process

DNS is therefore part of an organisation's operational and security boundary. A wrong record can make a website unavailable, interrupt email or weaken a security control. An obsolete record can expose infrastructure the organisation no longer intends to use.

How does a DNS lookup work?

When you enter a domain into a browser, email system or lookup tool, a DNS resolver searches for the requested record.

If the answer is already cached and still valid, the resolver may return it immediately. Otherwise, it follows the DNS hierarchy towards the name servers authoritative for the domain and retrieves the published answer.

A lookup result normally contains:

• Name: the domain or hostname the record belongs to
• Type: the kind of information requested, such as A, MX or TXT
• Value: the address, hostname, text or other data returned
• TTL: the time to live, which indicates how long a resolver may cache the answer

A public lookup shows what a resolver can see at that moment. It does not necessarily show the entire contents of a DNS zone, and cached answers can briefly differ after a change.

Common DNS record types at a glance

The examples in this article use addresses and domains reserved for documentation. They should not be copied into a live DNS configuration.

What is an A record?

An A record maps a domain or hostname to a 32-bit IPv4 address. For example:

www.example.co.uk → 203.0.113.10

When someone visits the website, DNS provides the address needed to reach the hosting infrastructure.

What an A-record lookup can tell you

An A lookup can help confirm:

• whether a hostname resolves to an IPv4 address
• whether a recent hosting change is visible
• whether the domain points to the expected provider or environment
• whether several addresses are published for availability or traffic distribution

Common A-record problems

• Old IP address: the record still points to retired hosting after a migration
• Missing record: the hostname does not resolve over IPv4
• Wrong environment: a production hostname accidentally points to a test or legacy system
• Unexpected exposure: a forgotten hostname reveals an internet-accessible service that should have been retired or restricted

An IP address alone does not prove which organisation operates the system or whether the service is secure. It is a starting point for validation.

What is an AAAA record?

An AAAA record, sometimes called a "quad-A" record, maps a domain or hostname to a 128-bit IPv6 address. It performs the IPv6 equivalent of an A record:

www.example.co.uk → 2001:db8::10

Where both A and AAAA records exist, clients may be able to reach the service over IPv4 or IPv6.

Common AAAA-record problems

IPv6 is sometimes enabled in DNS without receiving the same operational attention as IPv4. A service may work correctly over its A record but fail or expose a different configuration over IPv6.

Check that:

• the IPv6 destination is intentional
• the service responds correctly over IPv6
• security controls apply consistently across both protocols
• obsolete AAAA records are removed when infrastructure changes

What is a CNAME record?

A CNAME, or Canonical Name record, makes one hostname an alias of another hostname. For example:

portal.example.co.uk → customer.example-platform.com

DNS then continues resolving the target hostname to obtain its address.

CNAME records are frequently used for hosted platforms, content delivery networks, customer portals and software-as-a-service products. They allow the provider to change the destination addresses behind its hostname without requiring every customer to update an A or AAAA record.

What a CNAME lookup can tell you

• which external platform a hostname relies on
• whether an alias points to the intended service
• whether a failed service is caused by a broken alias chain
• whether a supposedly retired third-party integration is still referenced

Common CNAME problems

• Broken target: the alias points to a hostname that no longer resolves
• Long chains: one alias points to another and then another, increasing complexity and lookup work
• Conflicting records: a CNAME is published alongside record types that should not coexist at the same name
• Orphaned third-party mapping: the DNS record remains after the external service has been removed

That last condition deserves attention. Depending on the provider and configuration, an orphaned mapping may create an opportunity for another party to claim the abandoned resource. Removing obsolete DNS entries should therefore be part of service offboarding.

What is an MX record?

An MX, or Mail Exchange record, identifies the servers responsible for receiving email for a domain. A result may look like this:

10 mail1.example.co.uk
20 mail2.example.co.uk

The number is the preference value. A sending system normally attempts delivery to the server with the lowest value first. Records with the same preference can be used to distribute delivery between servers.

What an MX lookup can tell you

• which provider receives email for the domain
• whether backup or alternative mail servers are published
• whether a migration has left records for an old provider
• why inbound mail may be delayed or undeliverable

Common MX-record problems

• Incorrect hostname: email is directed to a server that does not handle mail for the domain
• Legacy provider: old MX records remain after a migration
• Unexpected priority: a backup or unwanted server is preferred over the intended destination
• Target is an alias: MX records should point to hostnames with address records, not to CNAME aliases
• No-mail domain left ambiguous: a domain that never receives email has no explicit null MX declaration where one would be appropriate

MX records govern incoming delivery. They do not authorise outgoing senders; that is one of the roles commonly performed by SPF through a TXT record.

What is a TXT record?

A TXT record allows text data to be published in DNS. Although the format was originally general-purpose, TXT records now carry many machine-readable policies and verification values.

Common uses include:

• SPF policies authorising email senders
• domain ownership verification for cloud services
• service configuration tokens
• other security or operational declarations

A TXT lookup might return:

v=spf1 include:example-email-provider.com -all

DMARC is also stored in a TXT record, but it is normally queried at a specific hostname such as _dmarc.example.co.uk, not simply at the root domain.

DKIM public keys are published as TXT records beneath a selector-specific hostname such as selector1._domainkey.example.co.uk.

What a TXT lookup can tell you

TXT records can reveal which services a domain has authorised or verified. They are especially useful when diagnosing email authentication, but interpretation depends on querying the correct hostname.

Common TXT-record problems

• Multiple SPF policies: more than one TXT value begins with v=spf1, producing an invalid SPF configuration
• Obsolete verification tokens: evidence of services that may no longer be in use
• Invalid syntax: the text exists but cannot be processed as the intended policy
• Wrong location: a valid-looking value is published against the wrong hostname
• Excessively broad authorisation: an email policy trusts more infrastructure than the organisation intends

Do not delete an unfamiliar TXT record solely because its purpose is unclear. Establish which service owns it and whether it is still required.

What is an NS record?

An NS, or Name Server record, identifies the authoritative DNS servers for a domain or delegated zone. For example:

example.co.uk → ns1.example-dns.net
example.co.uk → ns2.example-dns.net

These servers publish the authoritative DNS information used by resolvers around the internet.

What an NS lookup can tell you

• which DNS provider hosts the authoritative zone
• whether a nameserver migration has completed
• whether delegation information is consistent
• whether an unexpected provider remains involved in the domain

Common NS-record problems

• Inconsistent delegation: the parent zone and the domain's authoritative data do not agree
• Unreachable server: an authoritative name server is unavailable or incorrectly configured
• Old provider: delegation still references infrastructure that should have been retired
• Insufficient resilience: authoritative DNS is overly dependent on a narrow set of infrastructure

Because DNS controls where users and systems are directed, access to the registrar, DNS provider and administrative accounts should be strongly protected.

What is TTL, and why does it matter?

TTL, or time to live, states how long a resolver may cache a DNS answer before querying again.

A TTL of 3600 represents one hour. During that period, a resolver may continue returning its cached result even if the authoritative record has changed.

This explains why DNS updates do not appear everywhere at exactly the same moment. Different resolvers may have cached the previous answer at different times.

A low TTL can help planned migrations take effect more quickly, but it increases how often records need to be queried. A high TTL reduces repeated lookup work but can extend the visible life of an incorrect or outdated answer.

How to perform a DNS lookup

The simplest route is to use Wuluf's free DNS Lookup:

1. Enter the domain or hostname
2. Select the record type: A, AAAA, MX, TXT, CNAME or NS
3. Run the lookup
4. Compare the returned value with the expected provider or configuration
5. Check related record types before reaching a conclusion

Technical users can also query DNS from a command line with tools such as dig or nslookup. For example:

dig example.co.uk MX
nslookup -type=TXT example.co.uk

The exact command and available output depend on the operating system and tool.

How to interpret a DNS result safely

A lookup should answer a specific question. "What records exist?" is less useful than:

• Does the website point to the new hosting platform?
• Are all MX records owned by the current email provider?
• Does the SPF record include a service we have retired?
• Does this CNAME still point to an active third-party resource?
• Are the expected name servers authoritative?
• Do IPv4 and IPv6 reach equivalent, secured services?

Use three checks:

1. Is the result technically valid?

Does the record use the expected structure, and does its target resolve where necessary?

2. Is the result operationally correct?

Does it reflect the organisation's current suppliers, infrastructure and intended service design?

3. Is the result appropriately controlled?

Is the destination still needed? Is the provider account secure? Is ownership clear? Would the record expose or authorise more than intended?

A DNS lookup provides evidence. Organisational context determines whether that evidence is reassuring or concerning.

Why unexpected DNS records matter

DNS estates tend to accumulate history. Campaigns end, suppliers change, companies acquire domains and applications are retired. The visible service disappears, but the DNS entry survives.

Unexpected records may indicate:

• incomplete migration or offboarding
• dependency on an unrecorded third party
• an abandoned subdomain
• inconsistent security between IPv4 and IPv6
• obsolete email authorisation
• a change that was made without proper governance

None of those conclusions should be made from a record alone. But each is a valid reason to identify an owner and investigate.

Regular DNS review should include all organisational domains, not only the primary website. Defensive registrations, campaign domains, regional domains and domains that no longer send email can still affect security and reputation.

Speak to Wuluf about domain and cyber security.

Frequently asked questions