DNS Records Explained: A, CNAME, MX and TXT

DNS records are the instructions that tell the internet where your website, email and domain-verification services should go. This guide explains the main types with a small-shop example, then shows how to read and edit them in DirectAdmin without accidentally breaking your site or email.

What a DNS record is

DNS, or the Domain Name System, translates a name such as yourshop.in into the information that computers need. A DNS record is one entry in that system. It has a name, a type, a value and usually a TTL, which tells resolvers how long they may cache the answer.

When somebody types your domain into a browser, their device asks DNS servers for records. The answer may point the browser to a web server, tell a mail server where to accept messages, or prove that you control the domain. DNS does not contain your website pages; it helps services find the right destination.

Field	What it means	Example
Name or host	The part of the domain the record applies to	www or @
Type	The kind of instruction	A, CNAME, MX or TXT
Value or target	The address, hostname or text to publish	203.0.113.42
TTL	How long a resolver may cache the answer	3600 seconds
Priority	Preference used by some record types, especially MX	10

@ normally means the root domain, such as yourshop.in. A panel may also leave the host field blank for the root. The exact display differs between providers, so read the field labels before saving.

The definitions of the classic record types come from the DNS specification in RFC 1035. In everyday use, you will most often work with A, AAAA, CNAME, MX, TXT and NS records.

A and AAAA records: sending visitors to your website

An A record maps a hostname to an IPv4 address. For example:

Name:  @
Type:  A
Value: 203.0.113.42

That example uses an address reserved for documentation. Your hosting provider gives you the real server address for your domain. An A record can also be created for a subdomain such as shop or blog.

An AAAA record does the same job for an IPv6 address. The difference is the address format: A is for IPv4, while AAAA is for IPv6. If your provider gives you both, publish both records so visitors using either network protocol can reach the site.

The root and www are separate hostnames. A common arrangement is an A record for @ and a CNAME for www that points to the root domain. Some providers use A records for both. Follow the values supplied by your hosting provider rather than replacing a working record with a guessed address.

Do not put https://, a page path or a port number in an A or AAAA value. DNS needs the address only; HTTPS and the web server handle the protocol and page request later.

CNAME records: aliases for hostnames

A CNAME record makes one hostname an alias of another hostname. It does not contain an IP address. For example, www.yourshop.in might point to yourshop.in, or a service might ask you to point store.yourshop.in to a hostname it controls.

Name:   www
Type:   CNAME
Target: yourshop.in

Use the exact target given by the service, including any trailing dot only if the panel asks for it. Never change a CNAME target into an IP address; use an A or AAAA record when the instructions provide an address.

Keep a CNAME name separate from other data for that same hostname. For example, do not add an MX or TXT record to www when www already has a CNAME. Email records and domain-verification records usually belong at the root or at a separate selector/host name.

The root domain needs special care because it normally already has required DNS data. If a service asks for a CNAME at @, follow its provider-specific instructions or use the alias record type supported by that DNS service. Do not delete the root A, MX, TXT, NS or SOA records just to make a CNAME fit.

MX records: directing email

An MX, or Mail Exchange, record tells sending mail servers where to deliver email for a domain. It does not control where the website opens. A typical layout might look like this:

Host	Type	Priority	Target
@	MX	10	mail.yourshop.in

The target must normally resolve to an A or AAAA record. If the target is mail.yourshop.in, that hostname needs an address record of its own. Your email provider may give you one MX record or several, each with its own priority. A lower number generally means higher preference.

Do not guess MX values. If you move email to another provider, copy its current records exactly and remove old records only when the provider tells you to. Keeping an old MX record can send some messages to the wrong mailbox.

For example, Google’s current Workspace setup instructions use the MX value smtp.google.com for new setups, while older accounts may still use legacy values. Use the instructions for your own account, not an example from a blog. Google explains the relationship between MX records and mail delivery in its official MX record guide.

TXT records: verification and email security

TXT records store text that other services can read. The text may be human-readable, but it is often a machine-generated token. Common uses include:

• Domain verification: Google Search Console and other services give you a token to publish as TXT.
• SPF: a policy that lists which senders are allowed to send email for your domain.
• DKIM: a public key published at a selector such as selector1._domainkey.
• DMARC: a policy published at _dmarc that tells receiving systems how to handle messages that fail authentication.

TXT records are not interchangeable. A verification token belongs at the host named by the service. SPF belongs at the domain root in the value supplied by your mail provider; DKIM and DMARC use their own host names. Do not copy a value from another domain, and do not delete an existing TXT record because several TXT records can serve different purposes.

For Google Search Console, choose domain-provider verification, copy the TXT string Google gives you, add it to the authoritative DNS provider, and then return to Search Console. Google’s ownership-verification instructions show the required host and value fields. Leave the record in place after verification if you want to keep the verification method available.

NS records and nameservers

NS records identify the authoritative nameservers for a DNS zone. Those nameservers are the servers that publish the final answers for your domain. This is why changing nameservers at a registrar is different from editing an A or MX record inside a DNS panel.

Think of the relationship like this:

1. The registrar tells the wider DNS system which nameservers are authoritative for yourshop.in.
2. Those nameservers publish the zone’s A, AAAA, CNAME, MX, TXT and other records.
3. Browsers, mail servers and verification services query the authoritative data, often through caching resolvers.

If your domain uses HostKarle’s DNS, the nameservers are ns1.fastnsdns.com and ns2.fastnsdns.com. You can follow the guide to find HostKarle nameservers and update them. If your domain uses nameservers from another provider, edit the records there instead; a change made in DirectAdmin will not be authoritative until the domain delegates DNS to the right nameservers.

A small-shop DNS example

Suppose a shop owns mylittlemart.in. It wants the root domain and www to open its website, email to arrive at its mailbox provider, and Search Console to verify ownership. The records could look conceptually like this:

Purpose	Name	Type	Value
Main website	@	A	The IPv4 address supplied by the host
Website alias	www	CNAME	The hostname supplied by the host
Email delivery	@	MX	The mail server and priority supplied by the email provider
Domain verification	@	TXT	The exact token supplied by Search Console
Email authentication	Provider-specific	TXT	The exact SPF, DKIM or DMARC value supplied by the email provider

This table is a map, not a set of values to copy. Your domain, hosting account and email service each have their own destinations. When a provider gives you a record, preserve the spelling, punctuation, host name and priority.

How to edit DNS records in DirectAdmin

DirectAdmin provides DNS Management at the user level. The menu wording can vary slightly with the skin, but the workflow is the same.

1. Open DNS Management. Sign in to DirectAdmin, go to the user-level area and open DNS Management for the domain.
2. Check the current zone. Find the existing A, CNAME, MX, TXT and NS entries before adding anything. Record the old value if you are changing a record.
3. Add or edit the record. Choose the type, enter the host/name and paste the exact value. For an MX record, also enter the priority. Use the TTL already recommended by the provider unless its instructions say otherwise.
4. Save one change at a time. This makes it easier to identify a typo. Do not remove an existing record just because its purpose is not obvious.
5. Confirm the authoritative provider. If the domain’s nameservers point somewhere other than HostKarle, make the change in that provider’s DNS panel instead. DirectAdmin’s DNS documentation covers DNS Management and record maintenance.

For a new website, the host usually tells you whether to add an A record or a CNAME. For a new mailbox, the email provider supplies MX and authentication records. For a verification request, add only the token and host supplied by that service.

How to check whether a record is live

Use a DNS lookup after saving. On Windows, macOS or Linux, nslookup is a simple option:

nslookup -type=A yourshop.in
nslookup -type=MX yourshop.in
nslookup -type=TXT yourshop.in
nslookup -type=NS yourshop.in

The result should show the record you intended to publish. If it still shows the old value, check that you edited the authoritative provider, the host field is correct and the value has no accidental spaces or quotation marks.

DNS answers are cached. A resolver may continue to return the old answer until the previous TTL expires, and different networks may update at different times. That is why a record can look correct in one lookup and old in another immediately after a change. Google notes that DNS verification can take a day or two when the record is not visible yet, so wait and check again before repeatedly changing the value.

Common DNS mistakes to avoid

• Editing the wrong control panel: the registrar, hosting panel and DNS provider may be different companies. First check the domain’s NS records.
• Entering the full name twice: some panels append yourshop.in automatically. If you enter www.yourshop.in where the panel expects only www, you may create the wrong hostname.
• Using a URL as a value: an A record takes an IP address and a CNAME takes a hostname, not https://... and not a page path.
• Treating MX like A: MX needs a mail hostname and priority. It is not the place to enter your website IP.
• Replacing TXT records: SPF, DKIM, DMARC and verification tokens can all be needed at once. Add the new value without deleting unrelated entries.
• Changing nameservers casually: a nameserver change moves DNS authority. It can affect the website, email and verification records together, so copy the required zone data before changing it.
• Making repeated edits while waiting: first confirm the authoritative nameservers, then allow time for caches to expire. Repeated changes make troubleshooting harder.

If you are still choosing a domain, the HostKarle domain search page shows the available names and lets you register in INR. For a broader buying checklist, see how to buy a domain name in India.

FAQ

What are DNS records used for?

DNS records connect domain names with services. A records help browsers find a website, MX records direct email, TXT records publish verification or email-security data, and NS records identify the authoritative DNS servers.

Which DNS record points a domain to a website?

An A record points a hostname to an IPv4 address, while an AAAA record points it to an IPv6 address. A CNAME can point a subdomain to another hostname when the website provider gives you a hostname instead of an IP address.

What is an MX record?

An MX record tells sending mail servers which host accepts email for your domain. It includes a priority, and the target should normally resolve through an A or AAAA record.

Can I use a CNAME for the root domain?

The root domain has other required DNS data, so a standard CNAME there can conflict with those records. Use the A or AAAA values supplied by your host, or follow the DNS provider’s documented alias option if it specifically supports one.

How long do DNS changes take?

There is no single fixed time. Caches follow the record’s TTL, and different networks may refresh at different moments; a change can appear quickly in one lookup and remain old elsewhere for longer. If a verification record is still missing, check the authoritative DNS provider and wait before trying again.

{“@context”: “https://schema.org”, “@type”: “FAQPage”, “mainEntity”: [{“@type”: “Question”, “name”: “What are DNS records used for?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “DNS records connect domain names with services. A records help browsers find a website, MX records direct email, TXT records publish verification or email-security data, and NS records identify the authoritative DNS servers.”}}, {“@type”: “Question”, “name”: “Which DNS record points a domain to a website?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “An A record points a hostname to an IPv4 address, while an AAAA record points it to an IPv6 address. A CNAME can point a subdomain to another hostname when the website provider gives you a hostname instead of an IP address.”}}, {“@type”: “Question”, “name”: “What is an MX record?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “An MX record tells sending mail servers which host accepts email for your domain. It includes a priority, and the target should normally resolve through an A or AAAA record.”}}, {“@type”: “Question”, “name”: “Can I use a CNAME for the root domain?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “The root domain has other required DNS data, so a standard CNAME there can conflict with those records. Use the A or AAAA values supplied by your host, or follow the DNS provider’s documented alias option if it specifically supports one.”}}, {“@type”: “Question”, “name”: “How long do DNS changes take?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “There is no single fixed time. Caches follow the record’s TTL, and different networks may refresh at different moments; a change can appear quickly in one lookup and remain old elsewhere for longer. If a verification record is still missing, check the authoritative DNS provider and wait before trying again.”}}]}

Want to partner with us, suggest a resource or advertise on this blog? Email partnerships@hostkarle.in