Read registrable-domain boundaries

Reference Last tested 24 October 2026

Use a Public Suffix List rule to separate a hostname’s public suffix from its registrable-domain boundary. The boundary is a structural result from a particular list snapshot; it does not prove registration, ownership or the trustworthiness of a hosted tenant.

The boundary is more than the final two labels

A hostname is a sequence of labels. Some public suffixes contain more than one label, and the list also includes private hosting boundaries.¹ A rule that blindly keeps the last two labels therefore cannot describe every case represented by the list.

The inspector checks both the ICANN and private sections of its bundled snapshot. It prefers the applicable longest rule, handles wildcard rules and gives exception rules their defined treatment. The list’s format documentation explains those mechanisms²; the implementation records the matched rule beside the output so the result can be inspected.

These examples are structural teaching cases. No host was resolved and no tenant page was requested. The .test examples use the default rule because the supplied name has no explicit suffix entry in this snapshot.

The table is an original compilation from the recorded inspector cases. The public observation record preserves the input and visible output. Compilation data are CC BY 4.0; the list itself retains its own licence.

Private hosting is a structural distinction

In the blogspot.com case, the private suffix entry makes two.blogspot.com the registrable boundary used by this calculation. It does not say that two is an occupied tenant, that a particular person owns it, or that the platform’s isolation is effective in every product feature.

This matters when comparing labels that look familiar. A platform name can be part of the suffix used by many independent tenants. The boundary helps describe that structure, but a tenant’s displayed name and the platform’s reputation are separate facts. Do not collapse them into a single claim about the page behind the address.

The list is also not an ownership database. If a name has changed hands, the same suffix rule can still apply. If a tenant is inactive, a valid structural boundary can still be calculated. Ownership and activity need other evidence.

Wildcards, exceptions and malformed labels

The wildcard example includes one additional label in the public suffix. The exception case changes that treatment for the named rule. Those details are why a list-aware calculation is preferable to a small set of country-code guesses.

A single terminal dot is removed for boundary calculation while the parser’s hostname remains visible in its field.³ An empty label elsewhere, including a second terminal dot, produces Not determined and a structural warning. The tool does not return a fragment such as .com as if it were a meaningful registrable name.

An IP address takes a different route: there is no DNS-name suffix boundary to calculate. A hostname that is itself a suffix also lacks the additional label needed for a registrable-domain portion. These are distinct outputs, not missing values that should be silently replaced with the input.

The script check is separate from the suffix calculation. It checks each Unicode label independently and ignores Common and Inherited characters. пример.com and пример.рф do not trigger a mixed-script flag, while аpple.com mixes Cyrillic and Latin within one label. xn--80ak6aa92e.com decodes to a single-script Cyrillic label; its possible lookalikes are a separate warning. faß.de remains Latin. None of these results establishes reputation.

Keep the snapshot with the result

The bundled list’s version is 2026-10-22_08-36-41_UTC. Its method and provenance identify the original source, hashes and the removal of non-licence comments. Rules and section markers remain, and the MPL 2.0 notice is included.

Use the demo to compare a hostname and its matched rule. When updating the list, rerun the wildcard, exception, private-suffix and malformed-label cases. A reproducible result includes the list version as well as the input, because the list can change independently of the browser’s parser.

Not covered on this page

• Registration availability, legal ownership or trademark rights.
• Hosted-tenant account status or isolation guarantees.
• Reputation, DNS responses or destination contents.