How do I check which mail servers a domain uses?

Look up the domain's MX records, which list mail servers each with a priority number. Lower numbers are preferred. The WhatIP mx-lookup tool shows them directly. If email is bouncing, confirm the MX records exist, point at real mail servers, and that those server names resolve to valid addresses.

What is the difference between SPF, DKIM, and DMARC?

SPF lists which servers may send mail for the domain. DKIM cryptographically signs outgoing mail so receivers can verify it. DMARC ties the two together and tells receivers what to do when a message fails both checks, such as quarantine or reject. Together they reduce spoofing and improve deliverability.

Why is my DNS change not showing up yet?

Resolvers cache each record for its TTL, so they keep serving the old value until that time expires. Query the authoritative server directly to confirm your change saved, then wait for caches to refresh. Lowering the TTL before a planned change makes new values appear much faster.

Can I put a CNAME on the root of my domain?

No. A CNAME cannot coexist with other records at the apex of a domain, and the apex always needs records like SOA and NS. Attempting it causes errors. Use an A or AAAA record at the root instead, or a provider feature that flattens an alias into address records.

What does the SOA serial number do?

The serial number in the SOA record increments each time the zone changes. Secondary name servers compare it against their copy to decide whether to pull updates. If you edit records but forget to bump the serial, secondaries may keep serving stale data, which looks like a propagation problem.

How can I tell if a record change is broken or just propagating?

Query the authoritative name server directly with a tool like WhatIP dns-lookup. If the authoritative server shows your new value, the change saved correctly and you are only waiting on caches elsewhere to expire. If even the authoritative server shows the old value, the edit did not save and needs fixing.

Reading and Diagnosing DNS Records

DNS records are the settings that make a domain work. They decide where a website loads from, where its email is delivered, which servers are authoritative, and which certificate authorities may issue its certificates. When something breaks, a site that will not load or email that bounces, the cause is very often a DNS record that is wrong, missing, or still propagating. Knowing how to read these records turns a frustrating outage into a quick diagnosis.

The good news is that every record follows a predictable structure once you know what each type means. An MX record is not mysterious once you understand it lists mail servers with priorities. A TXT record looks like random text until you recognize it as an email authentication policy. The skill is mostly pattern recognition plus a method for checking what is actually live versus what you think you configured.

This WhatIP guide explains each common record type in plain terms, shows how to read the values, and then walks through diagnosing the two problems people hit most: email authentication with SPF, DKIM, and DMARC, and changes that have not propagated yet. Throughout, you can follow along with the WhatIP dns-lookup tool for general records and the mx-lookup tool for mail routing.

How to read a DNS record

Every record shares the same basic anatomy: a name, a TTL, a type, and the data the record carries. For example:

www.example.com.   3600   IN   A   203.0.113.10

That reads as: the name www.example.com has an A record, cacheable for 3600 seconds, pointing at the IPv4 address 203.0.113.10. The IN simply means the internet class. Once you can parse that pattern, every record type below is a variation on it.

A and AAAA records

An A record maps a name to an IPv4 address. An AAAA record does the same for an IPv6 address. These are the records that actually tell a browser where to connect.

example.com.       A      203.0.113.10
example.com.       AAAA   2001:db8::10

If a site does not load, the first check is whether its A or AAAA record points at the address you expect. A wrong or missing A record is one of the most common reasons a site is unreachable.

CNAME records

A CNAME is an alias. It points one name at another name rather than at an address.

blog.example.com.  CNAME  www.example.com.

Here blog.example.com is an alias for www.example.com. A resolver follows the CNAME to its target and then looks up that target's A or AAAA record. One firm rule: a CNAME cannot exist at the apex of a domain alongside other records, so you cannot put a CNAME directly on example.com itself.

NS and SOA records

NS records list the authoritative name servers for the domain, the servers that hold the real answers.

example.com.       NS     ns1.examplehost.com.
example.com.       NS     ns2.examplehost.com.

The SOA, or start of authority, record holds administrative data for the zone: the primary name server, the responsible contact, a serial number that increments on each change, and timers for refresh, retry, and expiry.

example.com.       SOA    ns1.examplehost.com. admin.example.com. 2026053001 7200 3600 1209600 3600

The serial number, here 2026053001, is the most useful field for diagnosis. If you updated the zone but the serial did not change, secondary servers will not pick up your edits.

MX records

MX records define where email for the domain is delivered. Each has a priority number and a mail server name. Lower numbers are tried first.

example.com.       MX     10 mail1.example.com.
example.com.       MX     20 mail2.example.com.

Here mail1 at priority 10 is preferred, and mail2 at priority 20 is the backup. Check these with the WhatIP mx-lookup tool. If email is bouncing, confirm the MX records exist, point at real mail servers, and resolve to valid addresses.

CAA records

A CAA record states which certificate authorities are permitted to issue certificates for the domain. It is a safeguard against an unauthorized authority issuing a certificate.

example.com.       CAA    0 issue "letsencrypt.org"

This says only the named authority may issue certificates. If certificate issuance is failing, a too-restrictive CAA record is a likely culprit.

TXT records and email authentication

TXT records hold arbitrary text. Their most important modern use is email authentication, which relies on three policies layered together: SPF, DKIM, and DMARC. Diagnosing email almost always means reading these.

SPF

SPF, the Sender Policy Framework, is a TXT record listing which servers are allowed to send mail for the domain.

example.com.   TXT   "v=spf1 include:_spf.mailprovider.com -all"

Read it left to right: v=spf1 marks it as SPF, include authorizes another provider's servers, and -all means reject anything not listed. A common mistake is having two SPF records, which is invalid; there must be exactly one.

DKIM

DKIM, DomainKeys Identified Mail, publishes a public key in a TXT record at a selector-specific name. Outgoing mail is signed, and receivers verify the signature against this key.

selector1._domainkey.example.com.   TXT   "v=DKIM1; k=rsa; p=MIGfMA0..."

If DKIM is failing, confirm the selector name matches what your mail system signs with, and that the public key value is intact and not truncated.

DMARC

DMARC ties SPF and DKIM together and tells receivers what to do when checks fail.

_dmarc.example.com.   TXT   "v=DMARC1; p=reject; rua=mailto:reports@example.com"

The p tag is the policy: none for monitoring only, quarantine to send failures to spam, or reject to refuse them. The rua tag sets where aggregate reports go.

A worked email diagnosis

Suppose mail you send to a customer keeps landing in spam. Work through it methodically:

Look up the SPF record with the dns-lookup tool. You find two separate v=spf1 TXT records. That is invalid, and receivers may fail SPF. Merge them into a single record.
Check the DKIM selector your mail system uses. The TXT record at that selector is missing, so signatures cannot be verified. Publish the correct public key.
Read the DMARC record. The policy is p=reject, so any message failing both SPF and DKIM is refused outright. With SPF broken and DKIM missing, that explains the rejections.
Fix the two SPF records into one, publish the DKIM key, and confirm each change is live before retesting.

The order matters: SPF and DKIM are the checks, and DMARC is the enforcement layer that acts on their results.

Diagnosing propagation issues

When you change a record and it does not seem to take effect, the cause is usually caching rather than a failed save. Resolvers hold each record for the length of its TTL before refreshing. Until that cache expires, they keep returning the old value.

To diagnose a suspected propagation issue:

Query the authoritative server directly. If it shows the new value, your change saved correctly and you are simply waiting on caches elsewhere.
Check the SOA serial number. If it did not increment after your edit, secondaries may still serve stale data.
Compare the record's TTL against how long ago you made the change. A record with a TTL of 86400 can take a full day to refresh everywhere.
Use the dns-lookup tool to see the value currently being returned, and compare it to what you configured.

A practical habit is to lower a record's TTL a day before any planned change. Caches then turn over quickly when the real edit lands, so the new value appears almost immediately.

A method for diagnosing a site that will not load

When a website is unreachable, a quick DNS check rules in or out the most common causes before you touch the server itself. Work through it in order:

Confirm the domain has NS records and that they point at the name servers you expect. If the NS records are missing or wrong, nothing else will resolve.
Look up the A and AAAA records with the dns-lookup tool. Verify they point at the correct server address. A blank or outdated A record is the single most common cause of an unreachable site.
If the name is a subdomain using a CNAME, follow the alias to its target and check that the target itself has valid A or AAAA records. A broken CNAME chain looks like a missing site.
Check the CAA record only if the problem is a failing certificate rather than a failing connection. A restrictive CAA record can block certificate issuance without affecting normal traffic.

This sequence isolates the layer at fault. If the records are correct and resolve cleanly but the site still fails, the problem has moved beyond DNS to the server, the network path, or the application, and you can stop chasing DNS.

Reading records from the authoritative source

A recurring theme in diagnosis is the difference between what a cache returns and what the authoritative server actually holds. Resolvers around the world may show stale or inconsistent answers during a change, but the authoritative server is the single source of truth. When results disagree, always treat the authoritative answer as correct and assume the differences elsewhere are caches that have not yet expired. Comparing the cached value against the authoritative value is often the fastest way to tell a real misconfiguration apart from ordinary propagation delay.

Common pitfalls

Duplicate SPF records. There must be exactly one v=spf1 TXT record per domain.
CNAME at the apex. You cannot put a CNAME on the root of the domain alongside other records.
Forgetting the SOA serial bump. Secondary servers rely on the serial to detect changes.
Truncated DKIM keys. Long keys split across strings must be reassembled correctly or verification fails.
Confusing waiting with breakage. A change that is live on the authoritative server but not yet visible elsewhere is propagating, not broken. Confirm at the source with dns-lookup before assuming an error.

With these patterns and a methodical check at the authoritative source, reading and diagnosing DNS records becomes a routine skill rather than guesswork.

Reading and Diagnosing DNS Records: A Practical Guide