DNS Lookup for India — Free A/MX/TXT/CNAME Records
Free DNS lookup for Indian domains (.in, .co.in, .org.in). Check A, MX, TXT, NS, CNAME, SPF, DMARC records instantly. No signup, no ads.
Diagnosing .in / .co.in DNS records, Zoho Mail / Google Workspace MX setup, SPF & DMARC hardening against email spoofing that targets Indian brands.
Open the tool →Common Indian use cases
- New founders registering .in domains via BigRock or GoDaddy India who need to confirm nameserver propagation.
- IT teams migrating from cPanel to Cloudflare and verifying MX records still point at Zoho Mail India POPs.
- Marketing agencies checking SPF/DMARC on client domains after phishing complaints from RBI-regulated customers.
Why the India variant matters
Most DNS lookup sites are ad-heavy and rate-limited. PhishGuard queries authoritative resolvers directly and returns the raw records in under a second — useful when you're on a call debugging a broken email flow.
Records that matter for Indian setups
For a working .in or .co.in domain, five record types cover 95% of what you need. A / AAAA map the domain to its server. MX routes email — a Zoho Mail India setup uses mx.zoho.in, Google Workspace uses aspmx.l.google.com, and any random-looking MX is worth investigating. TXT holds SPF (which servers may send email as this domain), Google/Microsoft ownership tokens, and the DMARC policy at _dmarc.yourdomain. NS shows which nameservers are authoritative — during migrations, mismatched NS is the single most common cause of 'my site is down for some users'. CNAME aliases one host to another.
Email spoofing is the Indian pain point
An SPF record with no -all hard-fail, or a missing DMARC policy at p=reject, means any spammer can forge email that looks like it came from your .co.in domain. Indian banks and government portals are constantly impersonated this way. Run your domain through PhishGuard's DNS lookup and check that SPF ends with -all, DMARC exists with p=quarantine or p=reject, and DKIM selectors are present for whichever mail sender you use (Zoho, Amazon SES, Sendgrid).
Propagation and TTL
DNS changes don't reach every resolver instantly — TTL controls how long each record is cached. Before switching nameservers, lower TTL to 300 seconds a day in advance so the cutover is fast. PhishGuard queries authoritative nameservers directly, bypassing your ISP cache, so what you see is what the internet will see within one TTL cycle. That's a lot more useful than opening whatismyip.com and refreshing.
Frequently asked questions
Why does my new .in domain not resolve?
Nameserver propagation. When you change NS records, resolvers cache the old ones for up to 48 hours. Query authoritative nameservers directly (PhishGuard does this) instead of your ISP resolver to see the true state.
How do I check if my SPF record is correct?
Look up the TXT record and confirm it starts with 'v=spf1', lists every service that sends mail as your domain (Zoho, Google, SES, Sendgrid), and ends with '-all' (hard fail). A '~all' soft fail is weak; no SPF at all lets anyone spoof you.
What TTL should I use for A records?
300 seconds during migrations (fast cutover), 3600 or higher for stable production. Very low TTLs increase resolver load and can trigger rate limits at some Indian ISPs.