New gTLDs and Edge Cases

The Pre-2012 World

Before 2012, the set of generic TLDs was small and stable:

• .com, .net, .org, .edu, .gov, .mil, .int
• .arpa (infrastructure)
• Country-code TLDs: .uk, .de, .jp, .fr, etc. (about 250)

Total: a few hundred TLDs. You could hardcode a list. You could validate {2,4} characters. You could check "must end with .com or .net or .org or..." and be right for most cases.

That world no longer exists.

The New gTLD Program

In 2012, ICANN opened applications for new generic TLDs. Organizations paid $185,000 per application and went through an evaluation process. Hundreds of new TLDs were approved and delegated starting in 2013.

Today there are over 1,500 TLDs including:

Descriptive TLDs: .restaurant, .photography, .attorney, .accountant, .cancerresearch, .travelersinsurance

Geographic TLDs: .london, .berlin, .tokyo, .sydney, .nyc

Brand TLDs: .google, .apple, .amazon, .microsoft, .chrome

Industry TLDs: .bank, .insurance, .pharmacy, .healthcare

Script-based TLDs (IDN): .中文 (Chinese), .укр (Ukrainian), .рус (Russian), .مصر (Egyptian Arabic)

Short and memorable: .io, .co, .ai, .app, .dev

Why This Breaks Old Validators

Length limits

The {2,4} constraint (common in older code) fails for:

• .museum (6 chars)
• .travel (6 chars)
• .photography (11 chars)
• .cancerresearch (14 chars)
• .travelersinsurance (18 chars)

The maximum TLD length today is about 24 characters. Any fixed upper limit will eventually be wrong.

Static TLD lists

A validator that checks against a hardcoded list will miss any TLD added after the list was written. New TLDs are delegated continuously. A list from 2015 is missing hundreds of TLDs. A list from 2020 is missing dozens.

"Must have a dot"

Some validators require at least two labels (something + dot + TLD). This is a practical constraint, not an RFC requirement. user@localhost is syntactically valid and useful for development environments.

The Single-Label Domain Question

Can a domain have only one label, like user@example? Per the DNS specification, yes — a single-label domain is syntactically valid. In practice:

• The public internet does not route single-label domains
• RFC 2606 reserves .test, .example, .invalid, .localhost for testing
• Private networks often use single-label internal domains: user@mailserver

For web application validators, the right answer depends on context:

• Public-facing registration: reject single-label domains (won't receive email on public internet)
• Internal tooling: potentially accept them (valid for internal mail servers)
• API that processes emails from any source: accept them (they may be valid in the source's context)

The Trailing Dot Edge Case

A domain with a trailing dot (example.com.) explicitly includes the root zone. This form:

• Is valid in DNS zone files and DNS APIs
• Is rarely accepted by web application validators
• Can appear in imported data or API responses from DNS-adjacent systems

If your application receives data from DNS systems, test whether user@example.com. is handled gracefully.

Testing for New gTLD Compatibility

For any email or URL validator, test:

1. Common short TLD: user@example.io — should be accepted
2. 6-char TLD: user@example.museum — if rejected, length limit is wrong
3. Long TLD: user@example.photography — if rejected, length limit is wrong
4. Very long TLD: user@example.cancerresearch — if rejected, length limit is very wrong
5. Brand TLD: user@google.google — should be accepted (valid domain)
6. IDN TLD in punycode: user@example.xn--p1ai — should be accepted
7. Single label: user@localhost — acceptance depends on requirements
8. Trailing dot: user@example.com. — document whether accepted or rejected

The Correct Approach

The only correct approach for TLD validation is to use the IANA-maintained Public Suffix List (PSL) or the IANA TLD registry. These are downloadable, regularly updated lists of all valid TLDs. Libraries like mozilla-publicsuffix (JavaScript) and similar provide access to the PSL.

For applications that need TLD validation, the choice is:

1. Use the PSL (accurate, requires periodic updates)
2. Accept any domain label following RFC 1123 syntax (permissive, allows invalid TLDs but never rejects valid ones)
3. Validate by attempting delivery (most accurate, asynchronous)

Any hardcoded TLD list or length constraint is a time bomb that will be wrong when the next batch of TLDs is delegated.