DNS Records, Read Properly: What Each Record Type Actually Says

The Domain Name System is the directory that turns a name people can remember into the technical details a computer needs, and DNS records are the individual entries in that directory. An A record points a name at an IPv4 address, an AAAA record does the same for IPv6, an MX record names the mail servers that accept mail for a domain, and a TXT record carries free-form text that other systems read, for example to verify ownership or to publish mail policies. A CNAME record creates an alias, pointing one name at another name rather than at an address, and NS records name the servers that are authoritative for a zone. Each type has its own shape, and reading a record means knowing which question that type answers before judging whether its value looks right.

The DNS Lookup takes records you paste in and validates their format by type, without performing a live lookup. That distinction matters. A format check can tell you that a pasted A record contains a properly formed address, or that a pasted MX record has a priority number followed by a hostname, but it cannot tell you what the wider internet currently returns for that name, because it never asks. Treating a format result as a live answer is the single most common misunderstanding around this kind of tool, and it leads people to conclude that a record is live and working when all that has been shown is that its text is well formed.

Format rules differ by type in ways that catch out even experienced users. An A record must hold four numbers separated by dots, each between 0 and 255. An MX record needs a numeric preference first, so that mail systems know which server to try first, followed by a hostname that should end with a dot in a full zone file. A TXT record wraps its text in quotes and has length limits that matter when a long policy is split across several strings. A CNAME must point at a name, never at a bare address, and a name that is an alias cannot also carry other record types in the same zone. These are not matters of taste; they are the rules that parsers enforce, and a record that breaks them may be ignored silently rather than rejected loudly.

Worked example

Worked example with sample values. Suppose you paste three sample records: an A record reading example.com. 3600 IN A 93.184.216.34, an MX record reading example.com. 3600 IN MX 10 mail.example.com., and a TXT record reading example.com. 3600 IN TXT "v=spf1 include:_spf.example.com -all". Counting the fields gives 3 records and 3 different types, and each one passes a basic shape check: the A value has 4 groups, the MX value has a priority of 10 followed by a hostname, and the TXT value is quoted. The time-to-live value, 3600, converts to hours by dividing by 3600, which equals 1 hour, so a resolver may cache each record for up to 1 hour. The sample MX priority of 10 is lower than a backup priority of 20, and lower means tried first, so mail would go to the priority-10 server before the priority-20 one. These are sample values only, chosen to show the arithmetic and the field order, not records copied from a live zone.

Now change one character and watch the meaning shift. If the MX priority is typed as mail.example.com. 10, with the hostname first, the record no longer matches the expected order and a checker should flag it, even though every word in it is correct. If the A record address reads 93.184.216.999, the fourth group exceeds 255 and the address is invalid, however plausible it looks. If the TXT record loses its closing quote, the text is unterminated and a parser may swallow the following lines. In each case the fix is the same: correct the pasted text at its source, in the zone file or the provider panel, and then paste the corrected version for a fresh check.

Mistakes to avoid

The first mistake is confusing a format check with a live lookup, as described above. A clean format result says nothing about propagation, caching, or whether the authoritative server actually serves the record, and only a real query against a resolver can answer those questions. The second mistake is copying a record from a tutorial without adjusting the names inside it, which leaves a mail policy or verification string pointing at somebody else's domain. The third mistake is editing a record in a provider panel and forgetting the trailing dot on a hostname, so that the panel appends the zone name and produces a doubled name such as mail.example.com.example.com.. The fourth mistake is changing several records at once and then being unable to tell which change caused a problem; change one record, check it, and only then move on.

A related trap is assuming that a short time-to-live makes a change instant. A TTL of 300 seconds means a resolver may cache the old value for up to 5 minutes, since 300 divided by 60 equals 5, but resolvers that already hold the old value will keep serving it until that window ends, and some ignore short TTLs altogether. Plan changes with that delay in mind, lower the TTL a day ahead when a change is important, and verify afterwards with a fresh query rather than by reloading a page once and declaring success.

Putting it into practice

Use the checker when drafting or reviewing records before they go live, when auditing a zone you inherited, and when a mail or verification problem points at a record you have not read closely. Paste one record type at a time, read each field in order, and compare the value against what the service that consumes it actually expects. Keep a copy of the corrected zone text, note the TTL you set, and re-check after any edit. DNS looks simple because its records are short, but a short line with its fields in the wrong order can quietly break mail, verification, or an entire site, and a careful read is the cheapest protection available.

Related tools and reading: the CNAME Lookup, the CAA Lookup cover neighbouring checks that pair naturally with this one, and the guide at [/blog/cname-lookup-guide/] extends the same topic with further background and examples for readers who want to go deeper.

Key points

• Record type decides which question the record answers
• Field order matters as much as the values themselves
• TTL is a cache lifetime, measured in seconds
• Format checks never prove a record is live

In short: DNS records are short lines with strict shapes. The checker reads pasted records by type. Field order, address ranges and trailing dots decide whether a record parses. A format result is never a live answer.

One habit ties all of this together: re-check after every change. A result from the DNS Lookup is only as current as the input it was run on, so a fix, a redesign, or a new version of the underlying material deserves a fresh run rather than reliance on an old report. Keep the previous result alongside the new one, note what changed between them, and treat any new finding as a question to investigate rather than a verdict to accept or dismiss. That loop of checking, fixing, re-checking and recording is what turns a one-off test into a reliable routine, and it costs far less time than debugging a problem that a second check would have caught early.