Using TLDs as a Trust Signal

When someone signs up with a .bank email address, that domain required rigorous vetting and proof of being a regulated banking institution to register. When someone signs up with a .xyz email, they clicked a button and paid a dollar. No questions asked. Those are not equivalent events.

How hard it is to register a domain under a given TLD is a real trust signal. A domain registered under a strict TLD is inherently more credible because the registry itself has already done identity verification. The TLD carries information about the entity behind it. Most fraud prevention tools ignore this entirely.

UserCheck quantifies this with a tld_trust score from 1 to 5, available on every domain and email API response. This guide walks through each level, what the score means in practice, and how to use it alongside other signals in your signup flow.

1. Open

No verification. Anyone can register a domain in seconds with a credit card and a name they made up. No identity check, no nexus requirement, no documentation. This covers the vast majority of the internet.

Examples: .com, .net, .org, .xyz, .io, .academy, .app, .dev

A score of 1 doesn't mean the domain is suspicious. Most legitimate businesses and developers use these TLDs every day. It means the TLD itself provides no identity signal. You need other data points to form an opinion: domain age, MX configuration, disposable status, domain authority, and whether the domain appears on any blocklist.

2. Low Trust

These TLDs have rules on paper (local address requirements, regional nexus clauses, or national ID requirements) but enforcement is minimal in practice. Many registrars don't verify the information submitted, and trustee or proxy services let anyone register regardless of their actual nexus.

Examples:

• .fr: EU/EEA residency required, but many registrars don't rigorously verify
• .ar: Argentine tax ID (CUIT) required for locals, but NIC Argentina issues foreign registrants their own ID directly
• .barcelona: nexus to the Barcelona community, minimal enforcement

The barrier to entry is low. Anyone motivated to register under these TLDs can usually do so without actually meeting the stated requirements. Treat these similarly to open TLDs for fraud prevention purposes. The rule exists, but it's not reliably enforced.

That said, casual bad actors may not bother. The additional friction, even if minimal, does filter out the least sophisticated abuse.

3. Moderate Trust

These TLDs require a verifiable business number or national ID. The registry or its validation partner checks the information submitted, and false declarations can lead to domain suspension or revocation.

Examples:

• .com.au: Australian Business Number (ABN) or Australian Company Number (ACN), verified against the Australian Business Register
• .it: Italian fiscal code or VAT number required (EEA residents can use their own national ID); false declarations lead to domain revocation
• .bd: national ID or trade license; documents verified within 3 days or the domain is suspended

This is where tld_trust starts being a meaningful trust signal on its own. Someone with a .com.au domain has a verified Australian business. That's not a guarantee of good intent, but it's a real filter that anonymous bad actors can't trivially bypass. They'd need a real business registration or stolen credentials, which is a much higher bar.

For B2B applications where you expect business customers, a score of 3 or above from an expected country TLD is worth weighting positively in your risk model.

4. High Trust

These TLDs are restricted to specific institution types. Getting one requires submitting accreditation documents like university charters, banking licenses, or government authorization letters. The process is slow, expensive, and hard to game.

Examples:

• .bank: restricted to government-regulated banking institutions worldwide, extensively vetted by fTLD Registry
• .ac.uk: UK academic institutions, verified by Jisc
• .ac.jp: Japanese educational institutions, verified through JPRS-accredited registrars
• .abogado: restricted to licensed lawyers, credentials verified by an independent third party
• .sch.uk: UK schools, requiring a valid Department for Education recognition number

An email from a .bank domain carries significant inherent trust. The domain was expensive to acquire, slow to obtain, and required documentation that most bad actors simply can't produce. If someone signs up with a .bank address and confirms they own it, you're almost certainly dealing with a real institution.

For enterprise products, a score of 4 can be used as a positive trust accelerator: reduce friction, skip secondary verification steps, prioritize support. You're not removing risk entirely, but you're dealing with a very different population of registrants than someone who spun up a .xyz five minutes ago.

5. Absolute Trust

These TLDs are not available for public registration at all. They are government-reserved, military-reserved, or brand TLDs controlled entirely by a single entity. There is no application process because there is no public access.

Examples:

• .gov: US government entities (federal, state, local, tribal, and special districts)
• .mil: US military
• .mil.br: Brazilian military
• .apple: Apple Inc. brand TLD
• .aarp: AARP brand TLD

A domain under one of these TLDs is inherently trusted by definition. There is no verification process to evaluate because public registration simply doesn't exist. The only way to get one is to be the controlling entity.

Note that brand TLDs (.apple, .aarp) carry the same score as government TLDs because the registration mechanism is the same (no public access), but the practical implication is different. An email from .gov signals a government employee; an email from .apple signals an Apple employee.

Using the TLD trust score in the API

The field is available on both the domain and email API endpoints for accounts on the Pro plan. Here's an example using a .com.au email address, which returns a score of 3:

curl https://api.usercheck.com/email/[email protected]

{
    "status": 200,
    "email": "[email protected]",
    "normalized_email": "[email protected]",
    "domain": "example.com.au",
    "domain_age_in_days": 842,
    "mx": true,
    "disposable": false,
    "public_domain": false,
    "relay_domain": false,
    "tld_trust": 3,
    ...
}

Use tld_trust alongside other signals to calibrate signup friction. A high score doesn't replace other checks (a .com.au domain can still be newly registered, lack valid MX records, or appear on a blocklist), but it gives you a meaningful baseline signal about the identity verification the registry itself performed before the domain was issued.

A score of 4 or 5 is a strong signal on its own. Even a brand new domain under .bank or .gov is trustworthy, because the registration process already verified the entity behind it. For lower scores, you can pair it with other signals like domain_age_in_days or domain_authority to get a fuller picture.

See the UserCheck API docs for the full response schema and authentication details.

Conclusion

The TLD alone can tell you something real about the entity behind a domain, because the registry already did the work of verifying them. That's a strong signal from something as simple as the last few characters of a domain name. Now you can use it programmatically.