DNS records are the instruction lines that tell the internet which server your domain points to, where its email should be delivered, and which verification data belongs to it: an A record maps the site to an IP address, an MX record routes email to a mail server, a CNAME points one name at another, and TXT records carry verification and email-security information. Opening a DNS panel for the first time, these abbreviations look intimidating — but each one has exactly one clear job. This guide covers what every record type does, where people get them wrong, and how to verify a change actually took effect.
When you type a domain into a browser, your computer has no idea which IP address it corresponds to. It asks a resolver, which walks the chain — root servers, then the TLD servers, then finally your domain's authoritative nameservers — to find the answer.
Those authoritative nameservers are where your DNS records live. Which is why the first thing to set in your domain panel is not records but nameservers. If your nameservers do not point at your hosting, nothing you type into that panel will take effect — the internet is looking for your records somewhere else entirely. Perhaps a third of all DNS problems come down to exactly this one mistake.
An A record maps a domain name to an IPv4 address. It is the most fundamental record — it is what makes your site appear at all.
Turkey (Türkçe)
Worldwide (English)
@ → 203.0.113.10 — the domain itself (root/apex)www → 203.0.113.10 — the www subdomaintest → 203.0.113.25 — a subdomain pointing at a different serverAn AAAA record does the same job for IPv6 addresses. If your server supports IPv6, defining A and AAAA together is the right approach; defining an AAAA record on infrastructure that does not actually support it causes connection failures for some visitors.
Subdomain syntax is simple: typing blog in the panel means blog.yourdomain.com. Some panels want the full name, others only the prefix. Getting this wrong usually produces a doubled record like blog.yourdomain.com.yourdomain.com.
A CNAME record points one name at another name. Define www → yourdomain.com and you no longer need to update www separately whenever the main domain's IP changes.
There is one critical rule here: you cannot use a CNAME at the root of a domain (the apex). RFC 1034 is explicit — if a CNAME is present at a name, no other data may exist at that name. But SOA, NS and usually MX records must exist at the apex. Defining a CNAME for yourdomain.com therefore breaks the zone and makes the domain unresolvable.
If a CDN or platform tells you to point your root at a hostname, the answer is an ALIAS or ANAME record, if your DNS provider supports one. These are non-standard: instead of returning a CNAME to the client, the server resolves the target itself and synthesises an A/AAAA record in its place. If your provider does not support them, the only practical alternative is looking up the target's IP and creating a normal A record — but that carries real risk, because your site goes down if that IP changes.
An MX record tells the internet which server should receive email for your domain. It has nothing to do with your site's A record — your website can live in one place and your email somewhere else entirely.
MX records carry a priority value, and here a lower number means higher priority. A server at priority 10 is tried before one at priority 20; the second only takes over if the first does not respond.
@ MX 10 mail.yourdomain.com@ MX 20 mail2.yourdomain.comThe two most common mistakes: moving to an external mail service (Google Workspace, Microsoft 365) without deleting the old hosting MX record — some mail then lands silently on the old server and is lost; and pointing an MX record at an IP address — MX records point at names, not IPs. Create an A record for the IP first, then point MX at that name.
TXT records hold free-form text and serve two purposes: proving domain ownership and authenticating email. The second has not been optional since 2024.
Google Search Console, Microsoft 365 or a payment provider gives you a string to add to DNS, proving the domain is really yours. Do not delete these once verification passes — services re-check them periodically.
Lists which servers are allowed to send email on your domain's behalf, as a single TXT record:
v=spf1 include:_spf.provider.com ~all
A domain may have only one SPF record. Publishing two invalidates authentication entirely — if you need to authorise both your host and your marketing email platform, combine them into one line with multiple include: statements.
Cryptographically signs your outgoing mail. Your mail provider gives you a selector and a public key, which you publish as a TXT record at selector._domainkey.yourdomain.com. The receiving server verifies the signature against that key to confirm the message was not altered in transit.
Tells receivers what to do when SPF and DKIM fail, and provides reporting:
_dmarc TXT v=DMARC1; p=none; rua=mailto:[email protected]
The p value is the policy level: none monitors only, quarantine sends suspicious mail to spam, and reject refuses it outright. The right approach is to start at p=none, read the reports for a few weeks, and tighten gradually once every legitimate sending source is authorised.
Since February 2024, Google has required every sender to Gmail accounts to have at least SPF or DKIM, valid forward and reverse DNS (PTR) records, a TLS connection, and a spam rate below 0.3%. For senders of more than 5,000 messages per day, all three of SPF, DKIM and DMARC are required, the From header must align with either the SPF or the DKIM domain, and marketing messages must support one-click unsubscribe.
Microsoft introduced comparable rules for bulk senders to Outlook.com, Hotmail and Live addresses in May 2025. As of 2026 all three major providers permanently reject non-compliant mail rather than deferring it. For any business running email on its own domain, these records are no longer a technical preference — they are a precondition for deliverability.
Declares the domain's authoritative nameservers. Outside of delegating a subdomain to another provider, this is not a record you edit by hand.
Announces which server and port a particular service runs on. The most common use is game and voice servers: an SRV record lets players connect using just the domain, without typing a port number.
Restricts which certificate authorities may issue SSL certificates for your domain. With no CAA record, the default is that any public CA that validates control of the domain may issue a certificate for it. One line narrows that:
@ CAA 0 issue "letsencrypt.org"
The reverse record, mapping an IP address back to a hostname. It is set not in your domain panel but by whoever owns the IP — your server provider. If you send mail from your own server, a correct PTR record is critical for deliverability.
TTL (Time To Live) is how many seconds resolvers may cache a record. 3600 (one hour) is a common value. A high TTL means changes propagate slowly; a low one means more queries hit your DNS servers.
The practical technique: at least a day before a planned change such as a server migration, lower the TTL to 300 seconds, do the migration, then raise it again once everything is settled. That way, if you need to roll back, the rollback takes effect in minutes.
To verify a change, do not look at your browser — browsers and operating systems keep their own caches. Query directly:
dig yourdomain.com A +short — shows the A recorddig yourdomain.com MX +short — lists MX recordsdig _dmarc.yourdomain.com TXT +short — reads the DMARC recorddig yourdomain.com NS +short — shows authoritative nameserversnslookup -type=MX yourdomain.comTo see propagation from different countries, online DNS checkers query from multiple locations. "I still see the old value" is almost always caching, not an error.
include:.Domains registered with Nubitro are managed from your client panel, where you can define A, AAAA, CNAME, MX, TXT, SRV and CAA records. Because domain and hosting live in the same panel, A and MX records are configured automatically when you order hosting — most customers never need to add a record by hand.
All domain registrations include free WHOIS privacy, and hosting plans include a free SSL certificate. To register a new domain or check availability, use the domain search page; to move an existing domain, use domain transfer.
If you have not chosen a domain yet, our guide on how to choose a domain name covers the name and extension decision. For hosting to point it at, see our professional SSD hosting plans, and once the site is live, our guide on speeding up WordPress completes the performance side.
As long as the record's TTL. With a TTL of 3600, most resolvers see the new value within an hour. Nameserver changes are processed at the registry level and can take up to 24 hours.
The site runs on the A record and email on the MX record; one can be correct while the other is wrong. Check that dig yourdomain.com MX +short returns the right server, then look for a leftover old MX record.
Yes, because they are separate records. Usually one is an A record and the other a CNAME pointing at it. Make sure both are defined — defining only one sends part of your visitors to an error page.
Technically yes, but your messages will most likely land in spam or be rejected outright. Major providers have required these records since 2024 and now permanently reject non-compliant mail.
You can, but there is no benefit. A low TTL increases query volume against your DNS servers and can add resolution latency for every visitor. Lower it temporarily before a planned change instead.
If your nameservers stay the same, the records stay where they are and the transfer does not affect your site. If nameservers are changing too, export a full list of your current records before the transfer and recreate them exactly at the new provider.
dig or nslookup, not with your browser.