Start with the name each record describes
A DNS zone is a portion of the domain name system managed as a unit. If you manage the zone for example.com, its apex is example.com itself. Names such as www.example.com, mail.example.com, and shop.example.com sit beneath that apex. DNS records are attached to specific names, so a record for www does not automatically apply to example.com, or the other way around.
DNS editors often call the name attached to a record its “host” or “name.” In an editor for example.com, an entry of @ commonly means the apex, while www commonly means www.example.com. Some editors instead ask for a complete name. Check the editor’s preview or documentation before saving: entering www.example.com in a field that automatically appends example.com could produce an unintended name.
What makes the apex different?
The apex has two essential record types in a conventional DNS zone: SOA, which carries zone administration information, and NS, which identifies the zone’s authoritative name servers. Other records can also live there. For example, an A or AAAA record can point example.com to a web server address, an MX record can specify where mail for example.com is delivered, and a TXT record can hold a domain-verification value.
A standard CNAME record makes one name an alias of another, but it cannot coexist with other record types at the same name. Because the apex has SOA and NS records, you cannot put a standard CNAME at the zone apex. This matters when a website provider asks you to point your root domain to a provider hostname. Some DNS services offer features labeled ALIAS, ANAME, or CNAME flattening to handle that situation; these are provider features rather than standard CNAME records. If your service lacks such a feature, check which apex-compatible record options your website provider supports.
A subdomain such as www.example.com can generally use a CNAME when no other records are needed at that same name. A common website setup therefore uses one approach for the apex and a CNAME for www, then configures the website to serve or redirect both names as intended. The DNS records make the names resolvable; they do not, by themselves, configure web redirects.
Place records where the service expects them
The right location depends on the exact name the service uses. An MX record at example.com describes mail delivery for addresses ending in @example.com. An MX record at team.example.com instead describes mail delivery for addresses ending in @team.example.com. They are separate names, even if both eventually use the same mail provider.
Email authentication records provide another useful illustration. An SPF policy, when used, is published as TXT at the name whose mail-sending policy it describes. A DKIM public key is typically published at a selector name beneath _domainkey, such as selector1._domainkey.example.com. A DMARC policy for the example.com domain is published at _dmarc.example.com, not at the apex. Follow the service’s requested record name precisely rather than moving every email-related TXT value to @.
The same rule applies to verification records. A provider may ask for TXT at the apex, or at a specific name such as _verify.example.com. If a record appears to be missing after you add it, first check the full name that the DNS editor created. A correct value at the wrong name will not answer a query for the requested name.
Subdomains can be ordinary names or separate zones
Most subdomains are simply names within the parent zone. You can add records for app.example.com in the example.com zone without creating a new zone. You can also add names beneath it, such as status.app.example.com, if you need them.
A subdomain may instead be delegated. For example, NS records at app.example.com in the parent zone can direct DNS lookups to name servers responsible for a separate app.example.com zone. Once delegated, records for names inside that child zone are generally managed on its authoritative name servers, not alongside ordinary app records in the parent zone. This distinction is useful when a team or service needs to manage its own branch of a domain.
A wildcard such as *.example.com can supply answers for otherwise unmatched names, but it is not a substitute for planning named records. It does not make the apex itself match the wildcard, and explicitly defined names can affect what the wildcard covers. Use a wildcard only when you understand which names your application is prepared to handle.
A quick placement check before you save
Write down the full name you want to answer, the record type, and the requested value. Then identify the zone whose authoritative name servers manage that name. In that zone’s editor, confirm whether the name field expects @, a short label, or a complete domain name. For example, if the intended name is www.example.com, verify that the saved record displays as www.example.com rather than www.example.com.example.com.
Finally, check for records that conflict at the same name, especially a CNAME alongside another record. Remember that changing a record for www will not necessarily change the apex, and changing records at a registrar will not help if different name servers are authoritative for the zone. Keeping these distinctions clear makes both initial setup and later troubleshooting much simpler.
