What Is a DNS Record?

Read the name, type and value together

A useful DNS check starts with a precise question. Which name are you checking, which record type do you expect, and which service supplied the required value? Checking a domain without specifying the relevant record can produce findings that have little to do with the problem you are investigating.

DNS resource records and their structure are defined in RFC 1035. Cloudflare's record directory is a helpful starting point for the different types, including MX, TXT and CNAME.

In an outbound operation, keep the expected record beside the service that requires it. Record the exact name, type, value and responsible owner. That makes a later change review much clearer than a collection of screenshots marked "DNS passed."

An email example: receiving mail versus authenticating a sender

Imagine a company uses a business mailbox service and a separate application that sends customer notifications. This is an illustrative setup, not a configuration recommendation.

The team checks the company's MX records to understand its receiving route. It also checks the authentication information needed by the sending application. The receiving route alone cannot show whether that application's outgoing messages authenticate as intended.

This is why "the domain has DNS" is not a useful completion check. Different records answer different questions, and the service operating the sending path may need information published under a different name or selector.

Why a change can appear inconsistent

DNS includes caching, so distinguish a record's authoritative publication from what a particular resolver returns. A cached answer and the current authoritative answer are different observations. Save the lookup time and resolver when investigating a change rather than assuming one screenshot represents every system's view.

Before editing, copy the current state and confirm which services depend on it. An unfamiliar value is not automatically obsolete. Removing it to satisfy a generic checker can disrupt a different sending service that still uses it.

What to check next

Write down the symptom first: receiving failure, authentication failure or a record that appears missing. Then select the narrow lookup that addresses it. Compare the result with the current instructions from the relevant provider, and agree on a rollback before changing a shared production record.

Use the SPF record checker for an SPF question, or our MXToolbox guide to choose the appropriate diagnostic. A clean lookup is useful configuration evidence; inbox placement requires additional evidence from actual messages.