July 16, 2026

How to check if a domain is malicious: a practical triage guide

A user forwards a link. A DNS log shows an endpoint talking to a domain nobody recognises. Before you block it fleet-wide or dismiss it, you need a repeatable triage — one that takes minutes, not a threat-intel subscription. Here is the order that catches the most with the least effort.

1. Check the public threat feeds first

Three feeds cover a large share of commodity phishing and malware distribution: URLhaus (abuse.ch's malware-URL tracker), OpenPhish, and PhishTank (community-verified phishing). A hit on any of them is enough to block immediately — these feeds list observed attacks, not predictions. Our free domain checker queries all three in one lookup, plus the category lists below. No signup.

2. Check content-category lists

Not every unwanted domain is an attack. The UT1 lists from Université Toulouse and StevenBlack hosts categorise millions of domains — ads and tracking, proxy-bypass services, adult content, gambling, AI chat tools. A domain that is "only" a tracker or an unsanctioned proxy still matters for policy, and category listings often explain odd DNS traffic faster than threat feeds do.

3. Look at registration age

Phishing domains are overwhelmingly young. A WHOIS or RDAP lookup (rdap.org works for most TLDs) that shows a domain registered days or weeks ago — especially one imitating a known brand — is a strong signal. Legitimate businesses rarely launch payment or login pages on week-old domains. Age alone proves nothing, but young plus brand-adjacent plus urgent-sounding is the classic phishing triple.

4. Check certificate history

Certificate transparency logs (crt.sh) show every TLS certificate ever issued for a domain. A padlock means encryption, not legitimacy — free certificates are issued to attackers in minutes. What CT logs actually tell you: when the domain first went live with TLS, and which sibling subdomains exist. A burst of look-alike subdomains (login, secure, verify, account) on a fresh certificate is worth escalating.

5. Check DNS posture

Fast-flux hosting, dynamic-DNS providers, and disposable infrastructure show up in the records themselves. Very short TTLs, hosting on residential IP ranges, or a domain parked behind a dynamic-DNS service are all consistent with throwaway attack infrastructure. None is conclusive alone — plenty of legitimate services use short TTLs — but combined with steps 1–4 they round out the picture.

Then make it policy, not a one-off

Manual triage is for the edge cases. The commodity cases — the ones already on URLhaus or OpenPhish — should never reach a user in the first place. That is what endpoint DNS filtering is for: the ClearScreen agent enforces these same feeds and category lists locally on every device, blocks at resolution time, shows the user a clear block page, and records the decision with domain, category, feed source, and timestamp for audit. The triage you just did by hand becomes evidence you can export.

Try the domain checker on the last suspicious domain from your DNS logs — and if the answer is "already on a public feed," that is your case for moving enforcement onto the endpoint.