Why should I lower TTL values before a client website launch?

Lowering TTL values to 300 seconds a couple of days before launch ensures that internet service providers do not cache old DNS records for long periods. When you update the records on launch day, global traffic shifts to your new server within minutes instead of hours, minimizing potential downtime.

What is the difference between an A record and a CNAME record?

An A record directly points a domain name to a specific IPv4 address, such as 192.0.2.1. A CNAME record points one domain or subdomain to another domain name, acting as an alias which is frequently used for CDNs or load balancers.

Can I put a CNAME record on a root domain like example.com?

Strict DNS standards prohibit placing a CNAME record on a root apex domain. However, many modern DNS providers support CNAME flattening or ALIAS records to mimic this functionality, or you can use standard A records.

How do I check if my client's email authentication records are correct?

You can inspect SPF, DKIM, and DMARC settings by querying TXT records using command-line tools like nslookup or specialized email verification utilities. Ensure there is only one active SPF record and that all authorized mail senders are included.

What should I do if my local computer still loads the old website after changing DNS?

Your local operating system or web browser is likely caching the old IP address. You can fix this by flushing your local DNS cache using ipconfig /flushdns on Windows or the appropriate flush command for macOS, then trying an incognito window.

Freelancer Client DNS Verification Checklist & Guide

Verifying client DNS health before launching a new website or email migration is the single best way to prevent embarrassing downtime, broken routing, and frantic client phone calls. When you take control of the technical handoff, you ensure that A records point to the right servers, MX records deliver mail, and TTL values are optimized for a smooth go-live.

Before you update a single record or flip the routing switch, you need a reliable way to query live name servers from your own machine. You can use a tool like NS Lookup to instantly test record propagation, verify authoritative name servers, and spot misconfigurations across global resolvers without guessing.

The Anatomy of a Client DNS Audit

When a client hands over access to their domain registrar or DNS hosting provider, you cannot simply trust that their current setup is clean. Legacy records, abandoned subdomain delegations, and missing security records are standard issues. A thorough DNS audit establishes a clean baseline before you deploy your project files or connect new third-party services.

1. Identify the Registrar vs. Authoritative DNS

Many clients confuse the company where they bought their domain (the registrar) with the company actually hosting their DNS zone (the nameservers).

Registrar: Manages domain ownership, renewal, and registrar locks (e.g., GoDaddy, Namecheap, Google Domains).
Authoritative DNS: Stores the actual zone file records (e.g., Cloudflare, AWS Route 53, DigitalOcean, or the registrar's default nameservers).

Always verify where the nameservers are currently pointing using command-line utilities. For example, running a quick query on example.com shows you exactly which servers hold the master records:

nslookup -type=ns example.com

Sample output:

Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
example.com	nameserver = ns1.example-dns.net.
example.com	nameserver = ns2.example-dns.net.

2. Document Existing Critical Records

Never delete existing records until you have exported or manually cataloged them. Clients often forget that they are routing corporate email through Google Workspace, tracking conversions through specialized subdomains, or hosting a staging site on a hidden A record.

Create a spreadsheet tracking every active record. Pay special attention to:

A and AAAA Records: Root domain and www aliases.
CNAME Records: Verification tokens for SSL certificates, marketing tools, and CDN endpoints.
MX Records: Mail exchange servers ensuring inbound email doesn't break.
TXT Records: SPF, DKIM, DMARC, and domain ownership verification strings.

Step-by-Step Freelancer Client DNS Verification Checklist

Follow this structured checklist for every client project, whether it is a simple marketing brochure site or a complex web application.

Verification Step	What to Check	Recommended Action	Tool / Command
TTL Reduction	Time-To-Live values	Lower TTL to 300 seconds 48 hours prior to launch	DNS Provider Dashboard
Root A Record	IPv4 server assignment	Confirm IP matches current hosting provider (e.g., `192.0.2.1`)	`nslookup example.com`
WWW CNAME	Subdomain consistency	Ensure `www` correctly points to the root or CDN	`nslookup -type=cname www.example.com`
MX Integrity	Mail routing records	Verify priority numbers and server hostnames	`nslookup -type=mx example.com`
Email Security	SPF, DKIM, DMARC	Check that anti-spoofing TXT records validate properly	`nslookup -type=txt example.com`
SSL Handshake	Certificate validity	Test TLS configuration and issuer chains	`openssl s_client -connect example.com:443`

Step 1: Lower the TTL (Time To Live)

High TTL values (like 86400 seconds or 24 hours) mean internet service providers cache old DNS records for a full day. Two days before you launch, log into the client's DNS manager and lower the TTL on all records you plan to change down to 300 seconds (5 minutes). This ensures that when you point the domain to your new server, global propagation happens in minutes instead of hours.

Step 2: Validate A and CNAME Records

Check that the root domain (example.com) resolves to the exact IPv4 address provided by your hosting environment.

nslookup example.com 1.1.1.1

If you are using PowerShell on Windows, you can query specific name servers directly:

Resolve-DnsName -Name example.com -Server 8.8.8.8

Ensure that the www subdomain has a valid CNAME or A record pointing to the same destination. A common freelancer mistake is launching the root domain successfully while leaving www.example.com pointing to an old, broken hosting provider.

Step 3: Audit Email Authentication (SPF, DKIM, DMARC)

Nothing ruins a successful website launch faster than the client's outgoing emails suddenly landing in spam folders. Before touching the DNS, inspect the existing TXT records for email authentication.

SPF (Sender Policy Framework): Specifies which mail servers are authorized to send email on behalf of the domain. Ensure you merge old and new provider strings properly if changing email hosts.
DKIM (DomainKeys Identified Mail): Adds a cryptographic signature to headers. Make sure the CNAME or TXT records provided by the new email service are added accurately.
DMARC (Domain-based Message Authentication, Reporting, and Conformance): Instructs receiving servers on what to do with failing emails (p=none, p=quarantine, or p=reject).

Step 4: Test SSL and HTTPS Redirection

Once DNS records point to your new server, test the TLS certificate installation before notifying the client that the site is live. Use curl to verify that HTTP requests automatically upgrade to HTTPS:

curl -I https://example.com

Look for a HTTP/2 200 OK status and check that the issuer matches your provisioned certificate authority (e.g., Let's Encrypt, ZeroSSL, or a commercial provider).

Common DNS Mistakes and How to Fix Them

Even experienced developers occasionally trip over DNS edge cases. Here is how to diagnose and resolve the most frequent errors during client handoffs.

CNAME Flattening and Apex Records

Standard DNS specifications do not allow a CNAME record on a root apex domain (like example.com). If your hosting provider requires a CNAME target (such as a cloud load balancer or CDN endpoint), but the registrar doesn't support CNAME flattening (also known as ANAME or ALIAS records), your site will fail to resolve.

The Fix: Move the client's DNS hosting to a modern provider that supports CNAME flattening at the apex, or use standard A records mapped to the server's static IP addresses (e.g., 192.0.2.10).

Conflicting SPF Records

A domain can only have one active SPF TXT record starting with v=spf1. If a client previously used Microsoft 365 and is now switching to Google Workspace, developers often accidentally create two separate SPF records.

The Fix: Combine the mechanisms into a single record. For example: v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all.

Propagating Stale Local Caches

After updating records, you might see the new site on your phone while your laptop still loads the old staging server. This is caused by local operating system or browser DNS caching.

The Fix: Flush your local DNS cache. On Windows, run ipconfig /flushdns in PowerShell. On macOS, run sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder in the terminal.

Launch Day Verification Checklist

Use this final rapid-fire checklist on launch day to confirm everything is operational:

TTL values reduced 48 hours prior.
All legacy DNS records backed up to a spreadsheet.
Root A record updated to the new server IP (192.0.2.5).
WWW CNAME verified and pointing correctly.
MX records tested and email delivery confirmed.
SPF, DKIM, and DMARC validated without syntax errors.
SSL certificate active with proper HTTPS redirection.
Global propagation checked via online lookup tools.

Freelancer's Checklist: Verifying Client DNS Health Before Launching Projects