How to Check if an IP Address Is Malicious

Enter the address in the IP reputation check or open its IP page directly. The result combines all threat signals for the address into a 0-100 score and lists every finding with its severity:

The score is weighted: categories differ in severity, and confirmation by several independent sources raises it with diminishing returns, so one old listing does not make an address look as dangerous as one that is actively reported everywhere.

The categories answer "malicious how?", which matters more than the number. The findings returned by ipctl use these tags:

The same flag means different things on different networks. Look at the ASN, the organization and the prefix the address belongs to:

• Hosting and cloud networks: attack traffic often comes from rented servers. A flagged address here is usually a compromised or abused server, and the provider's abuse desk can act on it.
• Residential ISPs: flags typically come from infected home devices. The address may be reassigned to another customer within hours or days.
• Mobile carriers and carrier-grade NAT: thousands of users can share one address, so blocking it affects many innocent users.
• Tor exit nodes and VPN endpoints: the traffic is relayed. Use the Tor check to confirm a Tor exit, and decide by policy rather than by score.

For the bigger picture, the daily threat map shows where flagged networks are located by country and category (for example C2 servers by country) and which networks (ASNs) host the most of them.

The IP page shows the ASN, owner, prefix, reverse DNS, location and abuse contact in one view. From a terminal, the plain-text output gives the same summary:

$ curl ipctl.io/ip/185.220.101.1
IP:              185.220.101.1
Reverse DNS:     berlin01.tor-exit.artikel10.org
ASN:             AS60729
AS Name:         TORSERVERS-NET Stiftung Erneuerbare Freiheit
Prefix:          185.220.101.0/27
...
Threat Score:    .../100

Before blocking an address or escalating an incident, check the common sources of false positives:

• Timing: does the listing predate the event you are investigating, and is it still current? Dynamic addresses change hands, and a listing from last month may describe a different user.
• Shared infrastructure: CDNs, large cloud load balancers, mail providers and CGNAT gateways serve many unrelated customers from the same addresses.
• Security scanners: some research and monitoring projects scan the whole internet on purpose. They show up as scanner but are not attacking you specifically.
• Your own address: if your server or office IP is flagged, the cause may be an infected device, an open proxy or a previous holder of the address. Fix the cause; most listings expire once the reporting sources stop seeing the activity, and some blocklists require a delisting request.

A simple decision rule for most environments:

• Malicious (76-100) or a c2/botnet finding: block, and search your logs for other connections to or from the address.
• Suspicious (51-75): block at exposed services such as SSH, VPN gateways or login pages, or add friction (rate limits, CAPTCHA, step-up authentication).
• Low risk with anonymization tags: apply your policy for Tor, VPN and proxy traffic instead of treating it as an attack.
• Clean: no action from reputation alone - absence of evidence is not proof of good intent.

If the address is attacking you, report it to the network's abuse contact shown on the IP page; hosting providers in particular act on well-documented reports.

For SIEM enrichment, SOAR playbooks or scripts, the REST API returns the score and the findings as JSON:

$ curl -s https://api.ipctl.io/v1/intel/192.0.2.10
{
  "data": {
    "score": 62,
    "intel": [
      { "tag": "scanner", "severity": "medium" },
      { "tag": "brute-force", "severity": "high" },
      { "tag": "hosting", "severity": "info" }
    ]
  }
}

In a shell, curl ipctl.io/ip/<address>/threat prints just the score. AI assistants and editors that support the Model Context Protocol (MCP) can use the ipctl MCP server, whose check_ip_reputation tool returns the same data; setup is on the integrations page.

If your question is "why is my mail being rejected?", an IP reputation check is only part of the answer. Mail servers decide based on the specific DNS-based blocklists (DNSBLs) they subscribe to, plus their own sender reputation, SPF, DKIM and DMARC results. A spam flag here tells you the address has been reported for spam; to fix delivery, also check the blocklists named in the bounce messages and the postmaster tools of the large mail providers.

For security work - triaging alerts, deciding whether to block a connection, enriching logs - the threat categories, the network context and the corroboration across sources are what matter, and that is what this workflow is built on.