Catch fake signups with three layered checks

OWASP describes account creation as creating multiple accounts for subsequent misuse, such as spam, laundering goods or manipulating reviews and surveys ¹. The accounts come through the same form your customers use, so the defence is to score each signup on several independent facts rather than to trust one rule.

The three facts below cost one lookup each and need no interaction from the visitor: whether the email domain is a throwaway service, how long the email domain has been registered, and whether the visitor's IP address belongs to a hosting network. Each fact is weak alone. Together they separate a bot farm from a person who simply uses a privacy-minded mailbox.

The email-domain-check product reads public DNS and open lists for the domain behind an address. It returns disposable (the domain is on a list of throwaway providers), free_provider, role_account, the MX records, and a deliverability_signal with reasons. A domain that publishes a null MX record, the single record with preference 0 and . as the host, tells senders it accepts no mail ², and the product reports that as null_mx. It never opens a mail connection, so it cannot tell you whether a specific mailbox exists.

The domain-age product asks the registry over RDAP. RDAP events carry an eventAction and an eventDate, and the registration action marks when the object was first registered ³. The product returns created_at and age_days, the registrar and the registry server it used. If the registry cannot be reached the answer is unavailable, never an age of zero.

The ip product returns the network owner (asn, asn_org), is_hosting with hosting_provider, and is_tor. Hosting is decided by matching the address against ranges that cloud providers publish themselves; AWS, for example, publishes its ranges as a JSON file meant for identifying traffic from AWS ⁴. Our own risk_score adds 25 points for a hosting address and 70 for a Tor exit. is_vpn is always null, because we do not have a VPN data source, so an unknown value is never reported as false.

1curl -X POST https://YOUR_API_HOST/v1/ip \
2  -H "Authorization: Bearer $LOOKVALID_API_KEY" \
3  -H "Content-Type: application/json" \
4  -d '{"ip":"8.8.8.8"}'

1{
2  "asn": 15169,
3  "asn_org": "Google LLC",
4  "is_hosting": true,
5  "hosting_provider": "Google",
6  "is_tor": false,
7  "is_vpn": null,
8  "risk_score": 25
9}

The table is a starting policy we suggest. Tune the cut-offs against your own signups, where you can see which rows later produce abuse.

1type Signals = { disposable: boolean; nullMx: boolean; ageDays: number | null; hosting: boolean; tor: boolean };
2​
3function decide(s: Signals): 'allow' | 'verify' | 'review' | 'new_address' {
4  if (s.nullMx) return 'new_address';
5  const network = s.hosting || s.tor;
6  if (s.disposable) return network ? 'review' : 'verify';
7  const young = s.ageDays !== null && s.ageDays < 30;
8  return young && network ? 'verify' : 'allow';
9}

A missing age (ageDays null) is treated as no signal rather than as a young domain, because a registry outage is not evidence about the visitor.

• Hosting addresses carry real people. Corporate gateways, remote desktops and some privacy tools exit from cloud networks, so is_hosting alone should never reject a signup.
• Young domains belong to new businesses. A founder who registered a domain last week is not a bot.
• The disposable list is a list. A new throwaway service is missed until it is added, and a domain can appear on it by mistake, so offer step-up verification before a hard refusal.
• A null is_vpn means unknown. Do not read it as a clean result.

Prefer actions that add friction to risky signups, such as a second verification step, over actions that silently drop them, and log which signal fired so you can measure the cost to honest visitors. Our email domain check, domain age and IP pages list every field.