DNS records are the short lines that decide where your domain name points: which server opens your website, where mail for the domain is delivered, who is allowed to issue SSL certificates for you, and which server has the right to answer these questions in the first place. Each record type has its own rules, and some of those rules cannot be broken. This guide walks through all the commonly used DNS record types with real examples, documented limits and troubleshooting commands.
What is a DNS record made of?
Every record in a zone file has four parts: a name, a TTL, a type and a value. DNS management panels show you exactly these four columns, but under the hood something like this is stored:
; name TTL class type value
example.ir. 3600 IN A 203.0.113.10
www.example.ir. 3600 IN CNAME example.ir.
example.ir. 3600 IN MX 10 mail.example.ir.
example.ir. 3600 IN TXT "v=spf1 mx ~all"The class column is in practice always IN, and no panel ever asks you for it. Two points to note. First, in a zone file a record's name is written in full, with a trailing dot; in panels you usually enter only the relative part: www, or @ for the domain itself. Second, a single "name + type" combination can hold several values. This set is called an RRset, and it is why two MX records or three A records on the same name are perfectly legal.
Records are stored on the domain's "authoritative nameservers", but end users never talk to those servers directly. The browser asks a resolver (the ISP's DNS server or a public DNS service), and the resolver caches the answer for a while. Almost all of the "why hasn't my change taken effect?" confusion comes from that gap.
A and AAAA records: the heart of it all
An A record says "this name is this IPv4 address"; an AAAA record does the same for IPv6.
example.ir. A 203.0.113.10
www.example.ir. A 203.0.113.10To point a domain to a cloud server, these two lines are usually all you need: one for the main domain and one for www. Both A and AAAA records are allowed at the root of the domain (the apex); what the standard forbids at the root is a CNAME.
You can define several A records for one name. The nameserver returns all of them and rotates their order from one query to the next (round-robin). But here lies a costly misconception: plain round-robin knows nothing about the health of your servers. If one of the IPs goes down, DNS keeps handing it out for its share of answers, and part of your visitors end up at a dead server.
For AAAA, follow one rule: only create an AAAA record if the server really serves traffic on that IPv6 address. When browsers see an AAAA record they try IPv6 first, but thanks to the Happy Eyeballs algorithm (RFC 8305) they also try IPv4 in parallel about 250 milliseconds later. So the connection does not fail, but that quarter of a second is added to every page load, and if your own network has no IPv6 you will never notice the slowdown yourself.
CNAME: an alias, and the rules you cannot break
A CNAME record refers one name to another name (not to an IP address):
blog.example.ir. CNAME example.ir.The advantage is that when the server's IP changes, you edit only the main A record and every alias follows automatically. The price is that each CNAME adds an extra lookup step, so keep chains short.
example.ir itself), and do not define a CNAME and any other record for the same name. The rule comes from RFC 1034 (section 3.6.2) and RFC 2181 (section 10.1), and RFC 1912 states it plainly: "A CNAME record is not allowed to coexist with any other data." The only exceptions are DNSSEC records such as RRSIG and NSEC. And the root of a domain always has SOA and NS records, so it is never empty.You will often see the practical consequence: a service asks you to connect example.ir to its hostname with a CNAME, and the panel rejects it with an error. The standard solution is an A record at the root and a CNAME from www to the root.
MX: where is your domain's email delivered?
An MX record specifies which server receives mail for you@example.ir. The number next to it is the "priority", and lower means preferred:
example.ir. MX 10 mail.example.ir.
example.ir. MX 20 mail2.example.ir.A sending server tries priority 10 first and falls back to 20 only if it gets no answer; two MX records with the same number mean the load is shared between them.
Take three limits seriously. The value of an MX record must be a hostname that itself has an A or AAAA record, not a raw IP address and not a CNAME alias. An MX record at the root only covers @example.ir addresses; mail on a subdomain needs an MX record of its own. And most important of all: delete the old MX records before you add new ones. A leftover record with a lower priority means part of your mail silently goes to the wrong destination.
The MX values of email services change over time, so copy them exactly from that service's own documentation. For example, Google Workspace's current documentation says that for new setups a single record is enough, instead of the old five:
example.ir. MX 1 smtp.google.com.And here is the point that causes the most confusion: MX is only about receiving. Whether the mail you send lands in the inbox or in spam depends on the TXT records in the next section, even on your own shared hosting.
TXT: free-form text, but vital
A TXT record looks like nothing more than free-form text, but it carries three key jobs:
- SPF: states which servers are allowed to send email on behalf of your domain:
example.ir. TXT "v=spf1 mx ~all" - DKIM/DMARC: a digital signature and a policy for handling forged email. Without them your messages head for the spam folder; we cover building all three records correctly in our guide to fixing emails that go to spam.
- Ownership verification: Google Search Console, Microsoft 365 and many other services ask you to add a specific TXT record to verify your domain. The eNamad trust seal (the trust badge that Iranian online shops display) is the exception: there you prove ownership by uploading an empty text file, with the name shown in its panel, into the
public_htmlfolder, not with a DNS record.
Three documented limits are expensive to ignore. First, a domain has only one SPF record. Two records that start with v=spf1 produce a permerror, and in effect you have no SPF at all; different services must be combined in a single record with include:. Second, under section 4.6.4 of RFC 7208, SPF evaluation may use at most 10 DNS lookups. Every include, a, mx, ptr and exists, as well as redirect, uses up one of those ten, while all, ip4 and ip6 cause no lookup at all. Third, each text string inside a TXT record is at most 255 bytes, which is why long DKIM keys are split into several quoted strings.
Where these records live is fixed as well, and getting it wrong means a record that does nothing: SPF goes on the domain itself, DKIM on selector._domainkey.example.ir, where the "selector" is given to you by the email service, and DMARC on _dmarc.example.ir. In DMARC only v=DMARC1 has to be the first tag, and the rest can come in any order. The value of p is one of none, quarantine or reject, and if you leave it out the record behaves like p=none; writing it explicitly is still recommended. The current reference is RFC 9989, which replaced RFC 7489 in May 2026 and dropped the pct tag:
_dmarc.example.ir. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.ir"p=none. This policy rejects nothing and only sends reports. Watch the reports for a few weeks to make sure no legitimate sender (your site's contact form, your invoicing system, your newsletter) has been left out, then move to quarantine and finally to reject. Tightening the policy before that stage sacrifices your own genuine email.NS: who answers for your domain?
An NS record declares which nameservers hold the domain's records. When you hand your domain's DNS over to a service such as Mehran Host DNS, you change the NS entries in your domain registrar's panel (IRNIC, the registry for .ir domains, or an international registrar) to the nameservers you were given.
What is said less often is that NS records are registered in two places: at the domain registrar, which tells the parent zone (.ir, for example) where to ask, and inside the zone itself. The outside world follows the registrar's copy; editing the NS records inside your DNS panel without changing them in the registrar's panel achieves nothing.
A nameserver change is slower than a change to any other record, because the TTL of the referral in the parent zone is not in your hands: for .ir domains it is usually a few hours and at most 24 hours, and for .com up to 48 hours. So the order of work matters: first create and check all your records at the new service, then switch the NS records, and leave the old zone untouched for at least a week. If this is part of a full move, we lay out the order of steps in our guide to migrating a website to a new host.
SRV and CAA: two more specialized records
An SRV record publishes the address and port of a specific "service" (VoIP, games, some chat servers). The record's name has a fixed format that starts with underscores, _service._proto.name, and its value has four parts: priority, weight, port and target hostname:
_sip._tcp.example.ir. SRV 10 60 5060 sip1.example.ir.
_sip._tcp.example.ir. SRV 10 40 5060 sip2.example.ir.Priority works just as it does in MX, and "weight" only has meaning among records with the same priority: in the example above, about 60 percent of connections go to the first server.
A CAA record specifies which certificate authorities, and only those, may issue SSL certificates for your domain:
example.ir. CAA 0 issue "letsencrypt.org"The three parts of the value are, in order, the "flags", the "tag" and the "value", and three tags concern TLS certificates: issue for ordinary issuance; issuewild, which covers only wildcard certificates and takes the place of issue for them; and iodef, which gives an address for reporting violations. Other tags such as issuemail are registered too, but they concern email certificates, not your website's SSL. Take each authority's identifier from its own documentation; Let's Encrypt accepts exactly letsencrypt.org.
Two practical points. The absence of any CAA record means "every authority is allowed", so CAA only helps once you create it. And under the CA/Browser Forum ballot, the result of a check stays valid for the record's TTL or 8 hours, whichever is longer, so after fixing a CAA record, give it some time. The steps for getting a free certificate are in our tutorial on installing free SSL with Certbot.
What DNS TTL should you use? How long the world remembers your record
Every record has a TTL (time to live): how long DNS servers around the world are allowed to cache the answer. A high TTL (say, 1 day) means less load but slow propagation of changes; a low TTL (5 minutes) means changes take effect quickly. The professionals' trick: lower the TTL a day before you move servers. This advice is not a matter of taste. RFC 1912 recommends the same sequence (there it is about the minimum field in the SOA record, which at the time served as the zone's default TTL): lower it, wait as long as the old TTL, make and check the change, then raise it again.
There is a second TTL as well: the negative TTL. When a name does not exist, the resolver caches that "non-existence" too, and how long it does so comes from the zone's SOA record. So if you tested a subdomain before creating it, the negative answer can sit in the cache for an hour, and the correct new record is not seen until it expires. RFC 2308 considers one to three hours a sensible range for this value.
And let's retire a misleading term: "DNS propagation" does not really exist, because nothing is "broadcast" from your server to the world. The authoritative nameserver serves the new answer from that very second, and the only thing that takes time is for the old copies in caches to expire. So "wait up to 72 hours" is a safety margin, not a technical figure: with a 300-second TTL, the real maximum wait is about that long too.
DNS record types at a glance
| Record | What it does | Example value | Limit or trap |
|---|---|---|---|
| A | Name → IPv4 address | 203.0.113.10 | Allowed at the root (unlike CNAME); several values = round-robin with no health check |
| AAAA | Name → IPv6 address | 2001:db8::10 | Only if the server really serves over IPv6 |
| CNAME | Name → another name | example.ir. | Forbidden at the root; cannot coexist with any other record |
| MX | Where email is delivered | 10 mail.example.ir. | A hostname, not an IP and not a CNAME; delete old MX records |
| TXT | Text/proof | "v=spf1 mx ~all" | One SPF per domain; 10-lookup limit; 255 bytes per string |
| NS | Authoritative nameservers | ns1.example-dns.ir. | The copy that counts is at the registrar; a change takes up to 24 hours for .ir and up to 48 hours for .com |
| SRV | Service + port | 10 60 5060 sip1.example.ir. | Name in _service._proto format |
| CAA | Permission to issue SSL | 0 issue "letsencrypt.org" | No record means every authority is allowed; an earlier check stays valid for at least 8 hours, or for the record's TTL if that is longer |
Troubleshooting DNS records with dig and nslookup
Before any guessing, ask. On Linux and macOS, the dig command is the shortest route. If it is not installed, install it with sudo apt install bind9-dnsutils on Ubuntu and Debian, or with sudo dnf install bind-utils on Rocky Linux and AlmaLinux:
dig +short example.ir A
203.0.113.10
dig +short example.ir MX
10 mail.example.ir.
dig +short _dmarc.example.ir TXT
"v=DMARC1; p=none; rua=mailto:dmarc@example.ir"The main trick: ask once from the authoritative nameserver and once from a public resolver. If the answers differ, the record is stored correctly and you are only dealing with the cache; if the authoritative nameserver also answers with the old value, the problem is the record itself:
dig @ns1.example-dns.ir example.ir A +noall +answer
example.ir. 3600 IN A 203.0.113.10
dig @8.8.8.8 example.ir A +noall +answer
example.ir. 1784 IN A 198.51.100.20The second number in the public resolver's answer is the remaining TTL of the cached copy: this old answer expires in about half an hour. The zone's negative TTL, for its part, is the smaller of two numbers: the last field of the SOA record (the minimum field) and the TTL of the SOA record itself, as RFC 2308 specifies. In the example below both are 3600 seconds:
dig +noall +answer example.ir SOA
example.ir. 3600 IN SOA ns1.example-dns.ir. hostmaster.example.ir. 2026090701 10800 3600 604800 3600On Windows, the rough equivalent is nslookup -type=MX example.ir 8.8.8.8. The table below links the most common symptoms to their cause and fix:
| Symptom | Likely cause | Next step |
|---|---|---|
The domain opens but www does not | No www record was created | Add a CNAME from www to the root |
| The answer is correct but the browser shows the old site | The resolver's cache or the computer's own cache | Compare with dig @8.8.8.8 and wait for the TTL to expire |
| SERVFAIL for the whole domain | The NS records at the registrar are wrong, or the zone does not exist | Check dig +short example.ir NS first |
| Email does not arrive | An old MX record was left behind, or the MX points to a CNAME | List all MX records and delete the extra ones |
| SSL certificate issuance is refused | CAA does not authorize the certificate authority you want | Fix the issue value and wait a few hours |
| A newly created subdomain cannot be found | An earlier negative answer is still cached | Wait for the zone's negative TTL to expire (the smaller of the minimum field and the SOA record's own TTL) |
Common mistakes when setting up records
- Forgetting www: the domain opens but www does not (or the other way round). Define both.
- Dropping the trailing dot when copying CNAME/MX values: the result is a record like
mail.example.ir.example.ir. Read the final value once more before you save. - Creating records in the wrong zone: if the domain's NS records still point to the previous provider, a new record has no effect. Use
dig +short example.ir NSto make sure which zone is answering. - A permanent 60-second TTL: a low TTL is a tool for the migration period, not a permanent setting. Keeping it means that almost every visit triggers a full DNS lookup from scratch.
Managing DNS records in the Mehran Host panel
Mehran Host's DNS management service covers exactly these eight record types: A, AAAA, CNAME, MX, TXT, NS, SRV and CAA. The lowest TTL you can choose is 60 seconds, and the default is 3600 seconds. MX and SRV priority has a field of its own, hostnames are normalized with a trailing dot, and a TXT value entered without quotes is quoted automatically; in other words, several of the traps above are caught before you save.
A records get two extra features. The first is Smart load balancing: at least two IPs under one name, picked by "Nearest location" or "Random", with an optional health check that runs against all of those IPs, either an HTTP/HTTPS URL or an open TCP port. This is exactly what plain round-robin lacks: an IP that fails the check is taken out of the rotation of answers. The second is a CDN switch next to every A record. Turning it on hides the origin IP and changes the public answer to the nearest edge node; it works on any domain whose DNS is managed here, and the first 1 TB of traffic is free. What does and does not get cached on the node is covered in our guide to what a CDN is.
These few records cover a large share of everyday DNS work, all from one panel and without editing a zone file by hand. Your next step: point your domain to your server.
Frequently asked questions
What are DNS records, and which ones matter most?
DNS records are lines in a domain's zone file that connect each name to a destination or a text value. Eight types are used most: A and AAAA map a name to an IPv4 or IPv6 address, CNAME refers a name to another name, MX sets where email is delivered, TXT carries SPF, DKIM, DMARC and ownership checks, NS declares the authoritative nameservers, and SRV and CAA name a service's address and the authority allowed to issue SSL certificates.
What is the difference between an A record and a CNAME, and which should I use?
An A record points directly to an IP address, while a CNAME refers to another name that must itself eventually lead to an IP. At the root of the domain you must use an A record (or AAAA if you have IPv6), because the standard does not let a CNAME sit beside the root's mandatory records. For subdomains, a CNAME is better when the target is an external service whose IP may change; for your own server, an A record is simpler and one lookup faster.
How long does a DNS record change take to apply?
The authoritative nameserver serves the new answer immediately; what takes time is for the old copy to expire from resolver caches, and the upper bound is roughly the TTL the record had before the change. With a five-minute TTL that means a few minutes; with a one-day TTL, up to a full day. Nameserver changes are the exception: usually a few hours and at most 24 hours for .ir domains, and up to 48 hours for .com, because the referral TTL in the parent zone is not under your control.
Why can't I create a CNAME record on my root domain?
Because the DNS standard does not allow a name to have a CNAME and any other record at the same time, and the root of a domain always has SOA and NS records, so it is never empty. The standard solution is to point the root to the target IP with an A record and to use CNAMEs for subdomains such as www. Some providers offer a non-standard feature called ALIAS, but it is an extension and is not available everywhere.
How can I check that my DNS record is set up correctly?
Use dig to ask once from the domain's authoritative nameserver and once from a public resolver, then compare the two answers. If the authoritative nameserver returns the right value but the public resolver does not, the record is fine and you only need to wait for the TTL to expire. If the authoritative nameserver also returns the old value, the record was not saved or was created in a zone that does not answer for the domain.