DNS Explained: The Complete Guide to DNS Records, Email Migration & Real-World Troubleshooting

A beginner-to-advanced guide to DNS — how it works, every record type explained, email migration with zero downtime, and real-world troubleshooting for IT engineers.

Category: IT Infrastructure · Published: March 20, 2026 · 25 min read · Author: ZM Technologies Team

If you work in IT — whether you're setting up a website, migrating email, or troubleshooting connectivity issues — DNS (Domain Name System) is something you deal with every day. Yet, many engineers treat DNS as a black box. This guide changes that.

We'll take you from the fundamentals to advanced real-world scenarios, including a full email migration walkthrough from GoDaddy to Zoho Mail. By the end, you'll be able to configure DNS records, handle email migrations, and troubleshoot DNS issues with confidence.

Part 1: What Is DNS?

The Simple Explanation

DNS is the phonebook of the internet. When you type zmtechnologies.com in your browser, your computer doesn't understand domain names — it only understands IP addresses like 185.158.133.1. DNS translates human-friendly domain names into machine-readable IP addresses.

Without DNS, you'd have to memorize the IP address of every website you visit. Imagine typing 142.250.195.46 instead of google.com — every single time.

Why DNS Is Critical

DNS affects everything in your IT infrastructure:

Website accessibility — if DNS fails, your website goes offline
Email delivery — incorrect DNS means emails bounce or land in spam
Security — DNS records like SPF, DKIM, and DMARC protect against spoofing
Performance — DNS caching and TTL settings directly impact page load times
Cloud services — Microsoft 365, Zoho, Google Workspace — all rely on correct DNS configuration

Part 2: How DNS Resolution Works (Step by Step)

When you type www.zmtechnologies.com in your browser, here's exactly what happens:

The DNS Resolution Flow


Step 1: Browser Cache

  └── Has the browser visited this site recently?

       ├── YES → Use cached IP → Done

       └── NO → Continue to Step 2



Step 2: Operating System Cache

  └── Does the OS have this IP stored?

       ├── YES → Return cached IP → Done

       └── NO → Continue to Step 3



Step 3: Recursive Resolver (ISP / Google 8.8.8.8 / Cloudflare 1.1.1.1)

  └── Does the resolver have a cached answer?

       ├── YES → Return cached IP → Done

       └── NO → Start querying DNS hierarchy



Step 4: Root Name Server (13 root servers worldwide)

  └── Resolver asks: "Where is .com?"

  └── Root responds: "Ask the .com TLD server at X.X.X.X"



Step 5: TLD (Top-Level Domain) Server

  └── Resolver asks .com TLD: "Where is zmtechnologies.com?"

  └── TLD responds: "The authoritative server is ns1.example.com"



Step 6: Authoritative Name Server

  └── Resolver asks: "What is the IP for www.zmtechnologies.com?"

  └── Authoritative server responds: "185.158.133.1"



Step 7: Response Delivered

  └── Resolver caches the answer (based on TTL)

  └── Returns IP to browser

  └── Browser connects to web server

This entire process typically takes 20–120 milliseconds. The caching at each layer is what makes subsequent visits nearly instant.

Part 3: DNS Record Types — Complete Reference

A Record (Address Record)

What it does: Maps a domain name to an IPv4 address.

Syntax:


Type: A

Host: @              (or subdomain like 'mail')

Value: 185.158.133.1

TTL: 3600            (1 hour)

Real-world use case: Pointing zmtechnologies.com to the Lovable hosting server. When a visitor types your domain, the A record tells the internet where your web server lives.

Multiple A records: You can have multiple A records for load balancing. For example, large websites use multiple A records pointing to different servers for redundancy.

AAAA Record (IPv6 Address Record)

What it does: Same as A record, but for IPv6 addresses.

Syntax:


Type: AAAA

Host: @

Value: 2606:4700:3030::ac43:8cd6

TTL: 3600

Real-world use case: As the internet transitions to IPv6, AAAA records ensure your domain is accessible on modern networks. Many Indian ISPs like Jio already use IPv6 extensively.

CNAME Record (Canonical Name)

What it does: Creates an alias that points one domain to another domain (not an IP).

Syntax:


Type: CNAME

Host: www

Value: zmtechnologies.com

TTL: 3600

Real-world use case: Making www.zmtechnologies.com point to zmtechnologies.com. Also commonly used for SaaS verification — e.g., em1234.yourdomain.com → u1234.wl.sendgrid.net for email services.

Important rule: You cannot create a CNAME on the root domain (@). CNAME records can only exist on subdomains. This is a common source of configuration errors.

NS Record (Name Server)

What it does: Specifies which DNS servers are authoritative for your domain.

Syntax:


Type: NS

Host: @

Value: ns1.domaincontrol.com

TTL: 86400

Real-world use case: When you buy a domain from GoDaddy, NS records point to GoDaddy's name servers by default. If you move DNS management to Cloudflare, you change NS records to Cloudflare's servers.

Critical note: Changing NS records effectively hands over control of all DNS for that domain. This is the most impactful DNS change you can make.

MX Record (Mail Exchange) — Critical for Email

What it does: Tells the internet which mail server should receive emails for your domain.

Syntax:


Type: MX

Host: @

Priority: 10

Value: mx.zoho.in

TTL: 3600

How MX priority works:

Lower number = higher priority
Email is first attempted at the server with the lowest priority number
If that server is unavailable, the next priority server is tried

Example MX configuration for Zoho Mail:


Priority  Mail Server

10        mx.zoho.in

20        mx2.zoho.in

50        mx3.zoho.in

Critical understanding: MX records work at the domain level, not per user. When you change MX records, all email for @yourdomain.com is routed to the new server. You cannot use MX alone to route user1@domain.com to Server A and user2@domain.com to Server B. This is why email migrations require special handling (covered in Part 5).

TXT Record (Text Record)

What it does: Stores arbitrary text data. Used extensively for domain verification and email security.

Syntax:


Type: TXT

Host: @

Value: "v=spf1 include:zoho.in ~all"

TTL: 3600

Common uses:

Domain ownership verification (Google, Microsoft, Zoho)
SPF records (email authentication)
DMARC policies
DKIM public keys
Site verification codes

Part 4: Email-Specific DNS Records (The Critical Section)

This is where most IT engineers struggle — and where mistakes cause the most damage. Let's break down the three pillars of email authentication.

SPF (Sender Policy Framework)

What it does: Tells receiving mail servers which IP addresses and servers are authorized to send email on behalf of your domain.

How it works: SPF is published as a TXT record at your domain root.

Syntax:


Type: TXT

Host: @

Value: "v=spf1 include:zoho.in include:_spf.google.com ~all"

Breaking down the syntax:

v=spf1 — version identifier (always required)
include:zoho.in — authorize Zoho's mail servers
include:_spf.google.com — authorize Google's servers (if using Google Workspace too)
~all — soft fail for unauthorized servers (emails flagged but delivered)
-all — hard fail (emails from unauthorized servers are rejected)

Common mistake: Having multiple SPF TXT records. The DNS standard allows only one SPF record per domain. If you have two, both are invalid and all email authentication fails. Always merge SPF entries into a single record.

SPF lookup limit: SPF allows a maximum of 10 DNS lookups. Each include: counts as one lookup. Exceeding this limit causes SPF to fail silently. For complex setups, use SPF flattening tools.

DKIM (DomainKeys Identified Mail)

What it does: Adds a digital signature to every outgoing email, proving the email hasn't been tampered with in transit.

How it works:

Your mail server signs each outgoing email with a private key
The public key is published as a DNS TXT record
The receiving server uses the public key to verify the signature

Syntax:


Type: TXT

Host: zmail._domainkey         (selector varies by provider)

Value: "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBA..."

TTL: 3600

Real-world example: When Zoho Mail sends email from your domain, it attaches a DKIM signature. The recipient's server looks up zmail._domainkey.yourdomain.com and verifies the signature matches. If it does, the email is trusted.

Selectors: Each email provider uses a unique selector (the part before ._domainkey). Zoho uses zmail, Google uses google, Microsoft uses selector1 and selector2. You can have DKIM records from multiple providers simultaneously — they don't conflict.

DMARC (Domain-based Message Authentication, Reporting & Conformance)

What it does: Tells receiving servers what to do when an email fails SPF and DKIM checks. Also provides reporting so you can monitor abuse.

Syntax:


Type: TXT

Host: _dmarc

Value: "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; pct=100"

Breaking down the policy:

v=DMARC1 — version (required)
p=none — monitor only, don't take action (start here)
p=quarantine — send suspicious emails to spam
p=reject — block failed emails completely
rua=mailto:... — where to send aggregate reports
pct=100 — apply policy to 100% of emails

Recommended approach: Start with p=none to monitor for 2–4 weeks. Review DMARC reports to ensure legitimate emails pass. Then move to p=quarantine, and finally p=reject once confident.

How SPF, DKIM & DMARC Work Together


Incoming Email to Recipient's Server:



Step 1: Check SPF

  └── Is the sending server authorized in the SPF record?

       ├── PASS → Good signal

       └── FAIL → Suspicious



Step 2: Check DKIM

  └── Does the email signature match the public key in DNS?

       ├── PASS → Good signal

       └── FAIL → Suspicious



Step 3: Check DMARC

  └── Did SPF or DKIM pass AND align with the From domain?

       ├── PASS → Deliver to inbox

       └── FAIL → Apply DMARC policy (none/quarantine/reject)

Key insight: DMARC requires that at least one of SPF or DKIM must pass AND align with the domain in the From: header. This alignment check prevents attackers from passing SPF with their own domain while spoofing your domain in the From: field.

Part 5: Real-World Scenario — Email Migration from GoDaddy to Zoho Mail

This is where theory meets practice. Let's walk through a real migration scenario that IT engineers commonly face.

The Scenario

Domain: yourcompany.com (purchased on GoDaddy)
Current email: GoDaddy Professional Email (5 users)
Target: Zoho Mail (better features, better deliverability, better admin controls)
Requirement: Zero downtime, migrate users one by one

The Challenge

Remember: MX records work at the domain level. When you change MX to Zoho, all email for @yourcompany.com goes to Zoho — even for users who haven't been migrated yet. This is the fundamental challenge.

The Solution: Split Delivery (Email Routing)

Split delivery allows you to point MX to Zoho (new server) while routing emails for non-migrated users back to GoDaddy (old server).

Step-by-Step Migration Plan

Phase 1: Preparation (Day 1-2)

Lower TTL values — Before any changes, reduce TTL on MX and TXT records to 300 seconds (5 minutes). This ensures DNS changes propagate quickly.


Type: MX

Host: @

TTL: 300    (changed from 3600)

Create all user accounts on Zoho Mail — Set up all 5 mailboxes on Zoho before touching DNS.
Configure Split Delivery on Zoho — In Zoho Admin Panel → Email Routing → Add GoDaddy's mail server as a routing destination for non-migrated users.
Prepare SPF record — Create a merged SPF that includes both providers:


v=spf1 include:zoho.in include:secureserver.net ~all

Phase 2: DNS Switchover (Day 3)

Update SPF TXT record — Change to the merged SPF record prepared above.
Add Zoho DKIM record:


Type: TXT

Host: zmail._domainkey

Value: (provided by Zoho admin panel)

Change MX records — Remove GoDaddy MX records and add Zoho MX records:


Remove:  MX 10 mailstore1.secureserver.net

Remove:  MX 0  smtp.secureserver.net



Add:     MX 10 mx.zoho.in

Add:     MX 20 mx2.zoho.in

Add:     MX 50 mx3.zoho.in

Enable Split Delivery routing — In Zoho, configure email routing rules so that non-migrated users' emails are forwarded to GoDaddy's server.

Phase 3: Migrate Users One by One (Day 3-7)

Migrate User 1 — Export mailbox from GoDaddy (IMAP sync or POP download). Import into Zoho using Zoho Migration Tool. Verify all emails, folders, contacts are intact. Remove this user from Split Delivery routing.
Test thoroughly — Send test emails to and from the migrated user. Check spam folder placement. Verify SPF, DKIM, DMARC pass using email header analysis.
Repeat for remaining users — Migrate one user at a time, testing after each.

Phase 4: Cleanup (Day 8-10)

Remove Split Delivery — Once all users are migrated, disable email routing to GoDaddy.
Update SPF — Remove GoDaddy's include:


v=spf1 include:zoho.in ~all

Set up DMARC — Add monitoring:


Type: TXT

Host: _dmarc

Value: "v=DMARC1; p=none; rua=mailto:admin@yourcompany.com"

Restore TTL — Increase TTL back to 3600 (1 hour) for stability.
Cancel GoDaddy email — Only after confirming everything works for at least 48 hours.

Part 6: TTL (Time To Live) — The Hidden Factor

What Is TTL?

TTL is a value (in seconds) that tells DNS resolvers how long to cache a DNS record before checking for updates.

Common TTL Values

| TTL Value | Duration | When to Use |

|-----------|----------|-------------|

| 300 | 5 minutes | Before DNS changes / migrations |

| 3600 | 1 hour | Standard for most records |

| 14400 | 4 hours | Stable records, moderate traffic |

| 86400 | 24 hours | Very stable records (NS records) |

How TTL Affects You in Practice

The real problem: If your MX record has a TTL of 86400 (24 hours) and you change it, some email servers will still send mail to the old server for up to 24 hours. This is why lowering TTL before making changes is critical.

Best practice workflow:

48 hours before migration → Lower TTL to 300
Wait for old TTL to expire (up to 24 hours)
Make DNS changes
Changes propagate within 5-10 minutes
After migration is stable → Restore TTL to 3600

Why wait 48 hours? Because you need to wait for the old TTL to expire across all caches worldwide. If the old TTL was 24 hours, the earliest all caches will check for updates is 24 hours later — but some resolvers may not strictly respect TTL, so 48 hours provides a safety margin.

Part 7: Troubleshooting Real-World DNS Issues

Problem 1: MX Changed But Email Not Received

Symptoms: You changed MX records to the new provider, but emails are still going to the old server or bouncing.

Causes & fixes:

DNS propagation delay — Check if the old TTL has expired. Use nslookup -type=MX yourdomain.com 8.8.8.8 to verify what Google's DNS sees.
Cached records — ISP resolvers may cache longer than TTL. Wait 24-48 hours.
Incorrect MX format — MX value must be a hostname (e.g., mx.zoho.in), never an IP address.
Missing trailing dot — Some DNS panels require mx.zoho.in. (with trailing dot). Check your provider's requirements.

Problem 2: SPF Conflicts Causing Spam Issues

Symptoms: Emails land in recipients' spam folders despite correct MX records.

Causes & fixes:

Multiple SPF records — Run nslookup -type=TXT yourdomain.com and count SPF records. If more than one exists, merge them into a single record.
Missing include — If you use Zoho for email but forgot include:zoho.in in SPF, emails will fail SPF checks.
Too many lookups — Count your includes. Each include: is one lookup. Stay under 10.
Using +all — This allows anyone to send as your domain. Always use ~all (soft fail) or -all (hard fail).

Problem 3: DKIM Not Working

Symptoms: Email headers show DKIM: fail.

Causes & fixes:

Wrong selector — Verify the selector matches what your email provider expects. Zoho uses zmail, not zoho or default.
TXT record too long — Some DNS providers split long TXT records incorrectly. Check if the DKIM key was truncated.
Propagation delay — DKIM records can take up to 48 hours to propagate fully.
Record not on correct subdomain — DKIM must be at selector._domainkey.yourdomain.com, not at the root.

Problem 4: DNS Propagation Delays

Symptoms: DNS changes not reflecting even after hours.

Causes & fixes:

Old TTL was high — If the previous TTL was 86400, changes can take up to 24 hours.
ISP caching — Some ISPs ignore TTL and cache for longer. Try flushing your local DNS: ipconfig /flushdns (Windows) or sudo dscacheutil -flushcache (Mac).
Check authoritative server directly — Use dig @ns1.domaincontrol.com yourdomain.com MX to check if the change is live on the authoritative server.

Problem 5: Email Bouncing After Migration

Symptoms: Emails to migrated users bounce with 'user not found' errors.

Causes & fixes:

Mailbox not created — Ensure the user's mailbox exists on the new provider before changing MX.
Alias mismatch — If users have aliases (e.g., sales@domain.com → user1@domain.com), these must be recreated on the new provider.
Split delivery misconfigured — Verify routing rules are correctly pointing non-migrated users to the old server.
Catch-all disabled — If the new provider doesn't have a catch-all mailbox, emails to non-existent addresses will bounce.

Part 8: Command-Line Tools & Online Utilities

nslookup (Available on Windows, Mac, Linux)


# Check A record

nslookup yourdomain.com



# Check MX records

nslookup -type=MX yourdomain.com



# Check TXT records (SPF, DKIM, DMARC)

nslookup -type=TXT yourdomain.com

nslookup -type=TXT zmail._domainkey.yourdomain.com

nslookup -type=TXT _dmarc.yourdomain.com



# Query specific DNS server (e.g., Google DNS)

nslookup -type=MX yourdomain.com 8.8.8.8

dig (Linux / Mac — more detailed output)


# Full DNS query with all details

dig yourdomain.com ANY



# Check MX records with TTL

dig yourdomain.com MX



# Query specific nameserver

dig @ns1.domaincontrol.com yourdomain.com MX



# Trace the full resolution path

dig +trace yourdomain.com



# Short output (just the answer)

dig +short yourdomain.com MX

Online Tools

| Tool | URL | Best For |

|------|-----|----------|

| MXToolbox | mxtoolbox.com | MX, SPF, DKIM, DMARC validation |

| Google Admin Toolbox | toolbox.googleapps.com/apps/dig | DNS lookups from Google's perspective |

| DNSChecker | dnschecker.org | Global propagation checking |

| Mail Tester | mail-tester.com | Email deliverability scoring |

| DMARC Analyzer | dmarcanalyzer.com | DMARC report analysis |

Quick Reference: DNS Record Cheat Sheet

|--------|---------|---------------|-----------|

| A | Domain → IPv4 | 185.158.133.1 | Web server |

Summary: What Every IT Engineer Should Know

DNS is infrastructure — treat it with the same care as firewalls and servers
Always lower TTL before changes — this single habit prevents most migration issues
MX records are domain-wide — use split delivery for gradual email migrations
SPF, DKIM, DMARC are not optional — they're essential for email deliverability in 2026
One SPF record per domain — multiple SPF records break everything
Test before, during, and after — use nslookup, dig, and MXToolbox at every stage
Document every change — DNS changes affect the entire organization; keep a change log

DNS may seem complex at first, but once you understand the fundamentals and practice with real-world scenarios, it becomes one of your most powerful tools as an IT professional.

Need Help With DNS or Email Migration?

At ZM Technologies, we handle DNS configuration and email migration projects regularly — from small businesses to manufacturing enterprises across India. Whether you're migrating from GoDaddy, moving to Zoho Mail or Microsoft 365, or troubleshooting email delivery issues, our team can help.

Contact us for a free DNS health check and email migration consultation.