# DNS Records Explained with Practical Examples - Link: https://offshorehosting.pk/dns-records-explained-with-practical-examples/ - Published: 2026-10-25T10:08:00+00:00 - Author: admin # DNS Records Explained with Practical Examples DNS — the Domain Name System — is the phone book of the internet. When you type example.com into a browser, DNS translates that name into an IP address. When someone emails you, DNS tells their mail server where to deliver it. Every one of those translations is a DNS record, and each record type has a specific job. ## How DNS works, in thirty seconds A domain’s DNS is a _zone_ — a set of records hosted on authoritative nameservers. When a visitor’s computer needs to find your site, it asks a resolver, which asks your authoritative nameservers, which answer from the zone. Resolvers cache answers for the record’s TTL (time to live), which is why DNS changes take time to spread: a TTL of 86400 seconds means resolvers may serve the old answer for up to 24 hours. Two practical consequences follow. First, lower the TTL before making a change you want to spread quickly. Second, when something is wrong, check whether you are seeing a cached answer or the live one — a public DNS lookup tool that queries authoritative servers directly will tell you. ## A records: the website’s address An A record maps a hostname to an IPv4 address. It is the record that makes a website reachable. An A record maps a hostname to an IPv4 address. It is the record that makes a website reachable. Your hosting provider gives you the IP; you create the A record. If the server’s IP changes, you update the A record — nothing else needs to change. ## AAAA records: the IPv6 address An AAAA record does the same job for IPv6. ``` example.com. AAAA 2606:2800:220:1::1946 ``` When to use it: alongside the A record, if your server has an IPv6 address. An increasing share of networks prefer IPv6, and its absence is a real gap on modern networks. ## CNAME records: aliases A CNAME record aliases one name to another name. Instead of an IP address, its value is a hostname. ``` www.example.com. CNAME example.com. blog.example.com. CNAME shops.provider.com. ``` When to use it: when a service gives you a hostname rather than an IP address — for example, pointing a subdomain at a hosted platform, a CDN, or an external service. If the target’s IP changes, your CNAME keeps working, because you follow the target’s name rather than a fixed address. Two rules that catch people out: * **A CNAME cannot coexist with other records at the same name.** That is why you cannot put a CNAME at the zone apex (the bare domain, example.com) — the apex already has NS and SOA records. Use an A record at the apex, or a provider feature( sometimes called ALIAS or ANAME) designed for it. * **A CNAME must point to a hostname, never an IP address.** Pointing a CNAME at an IP address is invalid and will fail. ## MX records: where email goes MX records name the mail servers for a domain, each with a priority number. Lower numbers are tried first. ``` example.com. MX 10 mail.example.com. example.com. MX 20 mail2.example.com. ``` When to use it: to direct incoming mail to your mail provider. Your provider — whether it is your host, Google Workspace, or Microsoft 365 — publishes the exact MX values to use. Copy them exactly, including priorities. Common mistakes: * **Pointing MX at an IP address.** MX records must point to a hostname, and that hostname needs its own A or AAAA record. * **Forgetting the priority.** Two MX records with the same priority are fine ( mail servers will try both), but a missing backup MX means a single server failure stops your mail. * **Proxying the mail hostname through a CDN.** If you use a CDN’s proxy (for example, Cloudflare’s orange cloud) on the mail hostname, SMTP traffic breaks — mail hostnames must resolve directly to the mail server (DNS only). ## TXT records: SPF, DKIM, DMARC, and verification TXT records hold free-form text. In practice, that means three things: email authentication, and domain-ownership verification. **SPF (Sender Policy Framework)** lists the servers allowed to send mail for your domain. It lives in a TXT record at the bare domain: ``` example.com. TXT "v=spf1 include:_spf.google.com ~all" ``` **DKIM (DomainKeys Identified Mail)** publishes a public key that receiving servers use to verify your mail was really sent by you and not altered. It lives at a selector subdomain: ``` default._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0G..." ``` The selector (here, `default`) comes from your mail provider. **DMARC (Domain-based Message Authentication, Reporting and Conformance)** tells receiving servers what to do with mail that fails SPF or DKIM checks. It lives at` _dmarc`: ``` _dmarc.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:reports@example.com" ``` Start with `p=none` (monitor only) and move to `quarantine` or `reject` once you are confident your legitimate mail passes. Jumping straight to `reject` with a misconfigured SPF record will block your own mail. **Verification tokens.** Many services (Google Search Console, Microsoft 365, and others) ask you to add a TXT record containing a token, to prove you own the domain. These are harmless and can be removed after verification — or left in place. Rules for TXT records: there should be only one SPF record per domain (multiple SPF records invalidate each other — combine them into one); and values must be quoted exactly as your provider gives them, because a stray space or missing character breaks authentication. ## NS records: who answers for the domain NS records list the authoritative nameservers for the zone. They decide who is allowed to answer DNS queries for your domain. ``` example.com. NS ns1.example-dns.com. example.com. NS ns2.example-dns.com. ``` You normally set nameservers at the registrar, not by editing NS records by hand— the registrar tells the registry which nameservers are authoritative, and the zone’s own NS records should match. If they disagree, resolvers can behave unpredictably. When you change DNS providers, change the nameservers at the registrar and make sure the new provider’s zone is complete _before_ the switch. ## SOA records: the zone’s identity card Every zone has one SOA (Start of Authority) record. It names the primary nameserver, the responsible mailbox, the zone serial number, and timing values. You rarely edit it by hand — your DNS provider manages it — but the serial number is useful when debugging: if it does not increase after an edit, the change has not been published. ## SRV records: finding a service SRV records locate a service by protocol and port, and are used by SIP, XMPP, and directory services. Most website owners never need them; if a service asks you to add one, copy the priority, weight, port, and target exactly as given. ## CAA records: who may issue your SSL certificate A CAA record declares which certificate authorities may issue certificates for your domain. It is a cheap, high-value control: if an attacker tries to obtain a certificate for your domain from another authority, the CAA record blocks it. Add one for the authority you actually use. ## PTR records: reverse DNS A PTR record maps an IP address back to a hostname, and lives in the reverse zone rather than your domain’s forward zone. It is normally controlled by whoever owns the IP block — your hosting provider, not you. It matters most for outbound email: many receiving servers reject mail from an IP with no PTR record, or with a PTR that does not match the sending hostname. ## A complete example zone Here is what a small business zone might look like, with the pieces together: ``` example.com. A 93.184.216.34 example.com. AAAA 2606:2800:220:1::1946 www.example.com. CNAME example.com. mail.example.com. A 93.184.216.35 example.com. MX 10 mail.example.com. example.com. TXT "v=spf1 ip4:93.184.216.35 -all" default._domainkey TXT "v=DKIM1; k=rsa; p=..." _dmarc.example.com. TXT "v=DMARC1; p=quarantine" example.com. CAA 0 issue "letsencrypt.org" ``` ## Troubleshooting checklist When a site or email stops working after a DNS change, work through this list: 1. **Is the record actually published?** Query the authoritative nameserver directly( with `dig` or a public lookup tool) — if it is not there, the change never went live. 2. **Is it cached?** If the authoritative answer is correct but the public answer is old, wait out the TTL. 3. **Is the name spelled correctly?** DNS is literal: `www.example.com` and `example. com` are separate names with separate records. 4. **Does the MX target have an A record?** An MX pointing at a hostname with no address record is a common silent failure. 5. **Is there exactly one SPF record?** Two SPF TXT records cancel each other out. ## The bottom line You do not need to memorise every record type — you need to know which one does which job, and to copy provider-given values exactly. A records point websites at servers, MX records point mail at mail servers, TXT records authenticate your mail and prove ownership, and CNAME records alias names to names. Get those four right and most DNS problems never happen. Related reading: [How to Transfer a Domain Without Disrupting Email](https://offshorehosting.pk/blog/how-to-transfer-a-domain-without-disrupting-email/), [How Domain Registration, Renewal and Transfer Work](https://offshorehosting.pk/blog/how-domain-registration-renewal-and-transfer-work/), and [How to Choose a Domain Name and Extension](https://offshorehosting.pk/blog/how-to-choose-a-domain-name-and-extension/). See our [domain services](https://offshorehosting.pk/domains/). --- _Reviewed 25 October 2026. Prices, fees, and availability for Offshore Hosting domain services are [TO BE CONFIRMED] — this article does not state them._ ## Sources * Cloudflare — Onboard a domain (DNS setup): https://developers.cloudflare.com/ fundamentals/manage-domains/add-site/ * Cloudflare — Domain configuration, Email Service docs: http://developers.cloudflare. com/email-service/configuration/domains/ * InventiveHQ — DNS Lookup Tool, record type reference: https://inventivehq.com/ tools/network/dns-lookup * PrivacyKit — DNS Lookup FAQ (SPF, DKIM, DMARC, TTL): https://privacykit.dev/tools/ dns-lookup/