Labs · Cyber Security

Lab: Check Your Domain's A, CNAME, MX and TXT Records with dig and nslookup, and Spot Missing Email Protection

By Ravindra Bagale Last updated: 8 October 2026

Beginner30 minCommand Prompt or Terminal · dig (Mac, Linux, WSL) · nslookup (built in)

Course: Cyber Security · Chapter 12: Domains and DNS: GoDaddy, Elastic IP, A/CNAME and Subdomains

Chapter 12 connects a GoDaddy domain with A and CNAME records; this lab checks records like a security reviewer.

Chala mitrano! DNS is the phone book of the internet, and a wrong or missing entry causes outages and even fake emails in your company's name. Today we read DNS records ourselves with two free commands. These are public records, so reading them is completely safe. Chala bagha!

Suppose we are…

Suppose we are a trainee in the IT team of a Tata Motors dealership group. Customers say they received a "booking confirmation" email that looks like ours but asks for an advance payment. The first check is DNS: does our domain publish SPF (a TXT record listing which servers may send our email) and DMARC (a TXT record telling receivers what to do with fake mail)? We also confirm the website records point to the right server.

Goal of this lab

By the end you will have:

Looked up A (name to IPv4), CNAME (alias to another name), MX (mail servers) and TXT records.
Checked SPF and DMARC for a well-known domain and for your own domain (if you have one).
Compared the answer from two public DNS resolvers.

What you need (all free)

Any laptop. nslookup is built into Windows, Mac and Linux. dig is built into Mac and Linux; on Windows use WSL Ubuntu or just nslookup.
Your own domain from Chapter 12 (optional). Without one, use gmail.com and wikipedia.org for practice.
25–30 minutes.

Safety and ethics

DNS records are public and meant to be read, so these lookups are safe. Do not try zone transfers or brute-force sub-domain lists against other organisations' domains; that is reconnaissance and needs written permission.

Steps

Look up the A record (IPv4 address) of a site:
```
nslookup wikipedia.org
```
What you should see: a Server line (your resolver, often your router), and under Non-authoritative answer one or more Address lines.
Do the same with dig (Mac, Linux or WSL). +short prints only the answer:
```
dig wikipedia.org A +short
dig www.wikipedia.org +short
```
What you should see: for www.wikipedia.org, first a name such as dyna.wikimedia.org. (a CNAME, an alias) and then the IP address it points to.
Find the mail servers (MX records) of a domain:
```
nslookup -type=MX gmail.com
```
What you should see: lines like mail exchanger = 5 gmail-smtp-in.l.google.com. The number is the priority: lower is tried first.
Check SPF. It is a TXT record that starts with v=spf1:
```
nslookup -type=TXT gmail.com
```
What you should see: a line with "v=spf1 redirect=_spf.google.com".
Check DMARC. It is a TXT record on the special name _dmarc. in front of the domain:
```
nslookup -type=TXT _dmarc.gmail.com
```
What you should see: "v=DMARC1; p=none; ..." with a policy p= of none, quarantine or reject. reject is the strongest.
Ask two different public resolvers and compare (Google 8.8.8.8 and Cloudflare 1.1.1.1):
```
nslookup wikipedia.org 8.8.8.8
nslookup wikipedia.org 1.1.1.1
```
If the answers differ a lot from your router's answer, your router's DNS may be wrong or tampered with.
Now your own domain (replace mydomain.in): run steps 1, 3, 4 and 5 for it. For a website hosted on your EC2 server, the A record should match the server's Elastic IP.
Write a small table: Record, Value, OK? For example, "A: 13.233.10.25, matches Elastic IP: OK", "SPF: missing: fix", "DMARC: missing: fix".

Ravindra Bagale's Tip

Even if your domain never sends email, add SPF v=spf1 -all and a DMARC record with p=reject. That tells every mail server "nobody sends mail as this domain", so fake emails get blocked. Free protection in two records!

Ravindra Bagale's Tip – मराठी

तुमचा domain कधीच email पाठवत नसेल तरी SPF v=spf1 -all आणि p=reject असलेला DMARC record टाका. त्यामुळे प्रत्येक mail server ला कळतं की "या domain च्या नावाने कोणीच mail पाठवत नाही", आणि fake emails block होतात. दोन records मध्ये free protection!

Ravindra Bagale's Tip – हिंदी

भले ही आपका domain कभी email न भेजे, फिर भी SPF v=spf1 -all और p=reject वाला DMARC record डालो। इससे हर mail server को पता चलता है कि "इस domain के नाम से कोई mail नहीं भेजता", और fake emails block हो जाते हैं। दो records में free protection!

Common mistakes

Mistake	What happens	Fix
Looking for DMARC on the main domain	"No answer" and you think it is missing	DMARC lives at `_dmarc.yourdomain`
Two SPF records on one domain	SPF fails for all mail	Keep exactly one `v=spf1` TXT record
Checking right after changing a record	Old answer still shows	Wait for the TTL (time to live) to pass; compare with `8.8.8.8`
A record pointing to an old server IP	Visitors reach a server you no longer control	Point A records only to your current Elastic IP
Using `dig` in Windows Command Prompt	"not recognized"	Use `nslookup`, or `dig` inside WSL

Self-check checklist

I found an A record and a CNAME with dig or nslookup.
I found the MX records of gmail.com.
I read an SPF and a DMARC record and can explain p=reject.
I compared answers from 8.8.8.8 and 1.1.1.1.
I wrote a record table for my own domain or a practice domain.

0 of 5 done

Try-at-home challenge

Use dig to find the TTL (how many seconds a resolver may cache the answer) of wikipedia.org's A record. Run it twice, 10 seconds apart, against your router. What happens to the number and why?

Check your answer

Run dig wikipedia.org A (without +short). In the ANSWER SECTION, the number after the name is the TTL, for example 300. On the second run it is about 10 lower, because your resolver is counting down its cached copy. When it reaches 0, the resolver asks the authoritative server again. That is why DNS changes take time to "spread".

Samjla ka? A for the site, MX for mail, TXT for SPF and DMARC, and always check twice. Aata pudhe jaauya: Chapter 13 adds HTTPS with Certbot.