DOMAIN · RDAP · DNS · TYPOSQUATTING
How to analyse a suspicious domain: a DNS reputation guide
A link received by text, a sign-in portal or a sender address can mimic a familiar domain. Through typosquatting or lookalike characters, fraudsters try to capture credentials, lead you to a phishing page or divert a payment. Before acting, compare the exact name with technical evidence and an independent official source.
A suspicious-domain analyser helps collect these signals but cannot conclusively attribute a domain to an organisation or declare a site harmless.
1. Review registration data: WHOIS and RDAP
RDAP has superseded the older WHOIS protocol as the definitive registration-data source for many generic domains. It provides fields published by the registry at lookup time, not a full history.
Creation date: a contextual clue
Registry RDAP data can show registration date and registrar. A newly registered domain purporting to be an established bank or supplier portal merits extra scrutiny. No 15-day threshold proves fraud: legitimate domains can be new, while older domains can be compromised or resold.
Redacted ownership and registry limits
Registrant data is often redacted, and some registries do not expose every field. RDAP provides current registration data, not a complete history of owners, nameservers or delegation changes. SecurCheck reports unavailable sources rather than inferring an identity from a missing field.
2. Review DNS, mail and public certificates
Current DNS and network
Current DNS resolution may return a public IP address and, when the source responds, ASN or hosting context. This snapshot does not reconstruct historical DNS. Cloud or overseas hosting does not in itself prove an attack.
Public certificates and the HTTPS padlock
Certificate Transparency logs can show certificates issued for the domain and sometimes their earliest observed date. They do not certify the operator’s integrity. HTTPS encrypts the connection, but a fraudulent site may also hold a valid certificate. The tool does not comprehensively audit the TLS chain, issuer or every SAN name.
MX and mail: a separate check
If the incident involves email, review MX records and the message headers separately. MX records primarily designate receiving mail servers; their absence does not prove a domain cannot send email, and their presence does not authenticate a sender. This domain tool does not provide an MX inventory.
Protect your teams against targeted typosquatting
SecurCheck Business gives SOC analysts, IT and support teams a starting point for checking suspicious domains: available RDAP dates, current DNS resolution, public certificates, observable redirects and accessible reputation signals.
Results depend on the available sources and replace neither a full investigation nor partner confirmation through another channel.
Explore our business offer3. Cross-check the name, reputation and email context
Spot lookalikes and homographs
Compare the exact domain against an independently known official address: an extra letter, hyphen, misleading subdomain or character from another script. An internationalised name may appear in the ASCII “xn--” (Punycode) form. That can aid manual review, but the prefix alone does not mean fraud, and the tool cannot guarantee detection of all homographs.
Cross-check threat feeds without overclaiming
A known hit in Google Web Risk or another available source is a useful warning. No hit is not an endorsement: a new domain may not yet be listed. SecurCheck does not provide historical category changes or every abuse database worldwide.
For email, inspect SPF, DKIM and DMARC separately
Inspect the message headers and domain alignment with a dedicated email tool. A DNS record alone does not prove the received message passed authentication. Missing or failed controls call for investigation, not an automatic impersonation verdict: legitimate senders may also be misconfigured.
ICANN: understand RDAP · Certificate Transparency: public logs
Conclusion: treat the domain as evidence, not identity
A domain reputation check helps identify discrepancies and prepare an incident report. Do not let a favourable score or padlock decide alone: compare the address with trusted records, confirm payment or access requests using a known contact and escalate evidence to your security team when needed.