How do you read DNS query results accurately?

You've run a dig command to check your DNS record, and now you're staring at output that looks like a wall of technical gibberish. The good news: it's actually pretty simple once you know what to look for. Let's walk through it.

The basic structure of a dig response

Every line in a DNS response follows the same pattern: name, TTL, class, type, value. Here's what each means. The name is your domain. TTL (Time To Live) is how long that answer gets cached in seconds. Class is almost always "IN" for internet. Type tells you what kind of record you're looking at (TXT, MX, A, etc.). Value is the actual content you care about.

Here's a real example:

example.com. 3600 IN TXT "v=spf1 include:sendgrid.net ~all"

That 3600 means this record gets cached for an hour. The TXT type means it's a text record. Everything in quotes is the actual content.

The tricky part: TXT record quoting

DNS displays TXT records in quotes, but those outer quotes aren't part of your actual record. They're just how the output format shows it to you. That's a common source of confusion. You'll also sometimes see TXT records split across multiple quoted strings like this:

"first part" "second part"

Those separate strings automatically get concatenated into one value. You don't need to do anything. The receiver sees them as a single record.

MX records and priorities

MX (Mail Exchange) records include a priority number before the hostname. Lower numbers get tried first, so 10 mail.example.com. means "try mail.example.com first," and 20 mail2.example.com. means "try this one second if the first fails." You'll notice a trailing dot on the hostname (mail.example.com.). That's normal in full DNS output. It represents the root of the DNS hierarchy.

Common mistakes when reading results

But the first mistake: thinking those outer quotes on TXT records are part of your content. They're not. The second: assuming a long TTL means your record is wrong. A 3600 (one hour) or 86400 (24 hour) TTL is completely normal and fine. Third: forgetting to check that you're looking at the right record type. If you're validating your DKIM record but you dig a TXT record from the wrong selector, you'll be confused. Make sure you're querying the right domain and the right type.

So once you've got the basics down, grab our free SPF and DNS parser tools which do this reading for you visually. If you're still unsure after running your own dig command, our SOS hotline can walk you through what you're seeing.