The Hierarchy
DNS organizes the internet namespace as an inverted tree. The root is at the top (represented as .), branches downward into TLDs, then registered domains, then subdomains.
. (root)
/|\
.com .uk .io ...
/ |
example co.uk
| |
www. example.co.uk
Reading left-to-right in a domain name, you go from specific to general. mail.example.co.uk means: the mail host, within the example zone, within co.uk, within uk.
Label Rules (RFC 1123)
Each element separated by dots is a label. Label rules per RFC 1123:
- Length: 1 to 63 octets (characters in ASCII context)
- Characters: letters A-Z (case-insensitive), digits 0-9, hyphen
- - Cannot start with hyphen:
-example.com— invalid - Cannot end with hyphen:
example-.com— invalid - Cannot have
--in positions 3 and 4 (reserved for IDN prefixxn--) - Must not be all digits (though this is a convention, not a hard requirement per all implementations)
RFC 952 (the earlier specification) required labels to start with a letter. RFC 1123 explicitly relaxed this to allow labels starting with a digit. Validators based on RFC 952 or on memory of RFC 952 will reject 3com.com or 123example.com.
The Full Domain Length
- Maximum total length: 253 characters (including dots)
- This allows for deeply nested subdomains:
a.b.c.d.e.f.g.example.comis valid if under 253 characters
The length limit is per the DNS wire format: 255 bytes when the dots are represented as length bytes rather than dot characters. The 253 character limit in dotted notation is equivalent to 255 bytes in DNS format.
Common Multi-Level Domain Patterns
Several valid structures are commonly mishandled by validators:
Country-code second-level domains (ccSLDs):
example.co.uk → registered under co.uk, not .uk
example.com.au → registered under com.au
example.org.cn → registered under org.cn
Validators that extract the TLD by taking "everything after the last dot" extract .uk, .au, .cn — missing that these are delegated to public registries that function like TLDs. The actual "registered domain" in each case is two labels deep.
Non-standard subdomains:
mail.example.com → common
api.v2.example.com → versioned API subdomain
staging.app.example.com → environment subdomain
Validators that limit subdomain depth will reject legitimate configurations. There is no RFC limit on subdomain depth — only the 253-character total.
Testing Subdomain Handling
For any domain validator, test:
- Simple:
example.com— baseline - One subdomain:
mail.example.com— basic subdomain - Two subdomains:
api.mail.example.com— nested - ccSLD:
example.co.uk— country-code SLD - Digit-starting label:
123.example.com— RFC 1123 allows this - Hyphen in label:
my-service.example.com— valid - Leading hyphen:
-example.com— invalid - Trailing hyphen:
example-.com— invalid - Double hyphen mid-label:
my--service.example.com— valid (not in positions 3-4 of the label) - xn-- prefix:
xn--nxasmq6b.com— valid punycode label
Wildcard and Reserved Labels
Wildcard *: Used in DNS records (*.example.com) but not valid in domain names submitted by users. An application that accepts *.example.com as a valid email domain has a validation defect.
localhost: Valid per DNS rules (it's a valid label). Whether your application should accept user@localhost as a valid email depends on the use case.
IP addresses without brackets: user@192.168.1.1 — the . separates valid numeric labels. Technically this is a domain name with four numeric labels, not an IP address. It is valid per the DNS label rules but not routable on the public internet. RFC 5321 uses [...] to explicitly denote IP address literals.
The Trailing Dot
A trailing dot in a domain name (example.com.) makes the root explicit. This is common in DNS zone files and some DNS APIs. It is rarely accepted by web application validators.
If your application processes domain names from external sources (DNS APIs, configuration files, imported data), you may receive trailing-dot forms. Test whether your validation and storage handles them correctly.