How to Check Domain Age With RDAP for Signup Risk

You can check a domain’s registration age from its RDAP record, then use that age as one input to signup risk. The safe rule is equally simple: a young domain can justify extra verification, but it should not cause an automatic rejection.

A new company, side project, or rebrand also starts with a new domain. Domain age tells you when a name was registered. It does not tell you who is behind the signup, whether the mailbox is controlled, or whether the person intends abuse.

Start with the authoritative RDAP record

RDAP is the structured successor to WHOIS for registration data. An RDAP client first finds the authoritative service for a top-level domain from the IANA bootstrap registry, following the process in RFC 9224. It then appends the domain query path defined by RFC 9082.

For .dev, IANA currently points to Google Registry’s RDAP service. I ran this public query for emailverifier.dev on October 29, 2026:

curl -s https://pubapi.registry.google/rdap/domain/emailverifier.dev \
  | jq '.events[] | select(.eventAction == "registration")'

{
  "eventAction": "registration",
  "eventActor": "cloudflare",
  "eventDate": "2026-05-31T13:59:55.122Z"
}

The field to keep is the event whose action is registration. RFC 9083 defines that action as the object’s initial registration. The same response can contain expiration, last-change, and other dates, so choosing the first date you see is an easy way to calculate the wrong age.

This example is useful because it is not hypothetical. It also shows the limit clearly: the record proves that the domain was registered on May 31, 2026. It does not prove that every address at the domain is valid or that every signup using it is trustworthy.

Turn the timestamp into evidence, not a verdict

I would store the registration timestamp and compute age when the policy runs. That preserves the source value, makes the calculation auditable, and lets you change age bands without repeating a network lookup.

Keep the output tri-state:

• Known: RDAP returned a valid registration event.
• Missing: the response was valid but did not publish that event.
• Unavailable: discovery, lookup, parsing, or rate limiting prevented a result.

Both missing and unavailable mean unknown. Converting either one into “new domain” quietly punishes TLDs and registries that publish different data, and it turns an infrastructure failure into a user-risk claim. ICANN’s lookup guidance notes that available registration data can vary across registries and registrars.

Old domains need the same restraint. A long registration history is not an identity check. Domains can change hands, accounts can be compromised, and legitimate infrastructure can be abused. Age is context in both directions, not a trust score.

Use a staged signup decision

The strongest objection is fair: if a new domain is not proof of abuse, why collect the signal at all?

Because it can change the next step when independent evidence already makes a costly signup worth reviewing. I would apply this order:

1. Evaluate the address itself. Check syntax, mail routing, provider classification, typo, role-address, catch-all, and recipient evidence. Keep an inconclusive result as unknown.
2. Look up registration age separately. A recent timestamp adds context. It does not overwrite the email result.
3. Combine it with product evidence. Signup velocity, repeated device use, payment continuity, and the cost of the requested entitlement are more useful together than any isolated flag.
4. Choose a proportional action. Ask for inbox confirmation, delay expensive credits, issue a restricted trial, or route the account to review. Reserve a block for confirmed failures or a policy you can explain.

Do not start by copying somebody else’s seven-day or thirty-day cutoff. Log the raw age beside your own activation, abuse, and support outcomes first. A threshold should come from the false-positive cost and abuse pattern of your product, not from the neatness of a round number.

The same principle applies to free providers, privacy relays, and catch-all domains. Each describes a property of the address or domain. None establishes bad intent. The practical model is already visible in the free-trial abuse policy example: independent evidence should control how much access you grant, not whether you label a person as abusive.

Keep domain age separate from email verification

The emailverifier.dev domain endpoint returns provider classification, risk level, and mail-routing availability. It does not return a registration date. That boundary is deliberate: RDAP registration data and email-domain evidence answer different questions.

A server-side flow can call the email or domain API, then fetch or read a cached RDAP result from a separate component. Apply the email decision using the status, action, and signals described in the production API-results guide. Add domain age only to your application’s risk context.

If inbox control matters, send a confirmation challenge. Verification can identify routing, provider, and mailbox evidence, but it does not prove the submitter controls the address. The distinction between validation, verification, and confirmation still applies when an RDAP lookup is present.

A few implementation details prevent bad data

Parse the registrable domain before the lookup. For user@team.example.co.uk, the relevant registration is example.co.uk, not the mailbox subdomain. Use an up-to-date Public Suffix List implementation instead of assuming the last two labels always form the registrable domain.

Normalize internationalized domains to their DNS A-label form before matching the IANA bootstrap data. Cache the bootstrap registry and RDAP result with bounded lifetimes. RFC 9224 specifically recommends caching the bootstrap registry rather than fetching it for every request.

Store only what the policy needs: the normalized registrable domain, registration timestamp, lookup status, source service, and observation time. Registration responses can include more data than a signup decision requires. Keeping unrelated registrant fields creates privacy and retention work without improving the decision.

I would ship domain age in observation mode first. When it consistently changes a real decision alongside stronger evidence, promote it to a review signal. If it merely produces a satisfying number, leave it out.