How do you file an abuse report once you've found the contact?

This picks up after you’ve found the contact

How to find an abuse contact in a WHOIS/RDAP result covers locating the right address — the registrar’s dedicated abuse role for a domain, or the regional internet registry’s listed contact for an IP block. This guide assumes that step is done and covers what to actually put in the report, and what to realistically expect once you send it.

Pick the report to match what you’re actually reporting

A domain and the server it resolves to are controlled by two different parties, and each can only act on their own piece:

• Report the domain to its registrar when the problem is the registration itself — a domain registered specifically to impersonate a brand, a name used for phishing, or one whose registration details suggest fraud. A registrar can suspend, lock, or otherwise act on the registration, but has no access to whatever is actually running on the server the domain points to.
• Report the IP address to its network’s abuse contact when the problem is what’s running on the server or the traffic coming from it — malware distribution, a compromised host sending spam, or an exposed service being actively abused. That contact, found by running AdminKit’s Whois/RDAP tool against the IP address directly, belongs to whoever the address block is allocated to, not to the domain owner.

When both are implicated — a phishing page on a domain registered an hour ago, hosted on a compromised but otherwise legitimate server — sending both reports, to both contacts, covers each party’s actual area of control rather than hoping one report reaches everyone who could act.

What to include

A report an abuse desk can act on quickly needs to answer, without follow-up questions, what happened, where, and when:

1. The exact artifact — the full URL, not just a domain name, if the issue is a specific page; the IP address and port if it’s network traffic; the exact message if it’s email abuse.
2. A timestamp in UTC for when you observed it, to avoid ambiguity across time zones between you and whoever reads the report.
3. What it’s doing, stated plainly — phishing a specific brand, distributing a named malware family, scanning your network, sending unsolicited mail — rather than a general “this is bad” characterization.
4. Evidence that doesn’t depend on the artifact still being live — a screenshot, a saved copy of the page’s source, or relevant log lines, since phishing pages and compromised content are often taken down or changed within hours of being reported, sometimes by the attacker rather than the host. NIST SP 800-61’s incident-handling guidance applies the same discipline to any abuse investigation: precise, preserved evidence is what turns a report into something actionable, rather than a claim that can’t be independently verified after the fact.
5. Your own contact information, even if reporting anonymously feels safer — an abuse desk that needs clarification and has no way to ask will often simply close the report rather than guess at missing detail.

How to send it

Most registrar and network abuse contacts expect a plain-text email to the published address rather than a structured form, though some larger registrars and hosting providers also run a dedicated web form — use whichever the organization’s own published abuse policy specifies if one exists, since an email sent somewhere other than the designated channel can sit unread far longer than one sent correctly the first time. ICANN’s RAA requires every accredited registrar to publish both the contact address and a description of its own abuse-handling process on its website — worth a quick check before sending, in case the registrar asks for a specific format or subject line.

What to expect afterward

ICANN’s rules require registrars to take “reasonable and prompt steps” to investigate general abuse reports, which is a real obligation but not a fixed deadline — the 24-hour review requirement in the RAA applies specifically to reports of illegal activity submitted through a registrar’s dedicated law-enforcement channel, not to every report from the general public. A 2024 amendment strengthened this specifically for DNS Abuse, requiring registrars to act once they have credible evidence, which gives a well-evidenced report more weight than it had before. In practice, a report with a precise artifact, timestamp, and preserved evidence is simply more likely to be actioned promptly than one without — not because of a formal rule, but because it gives an abuse desk less work to do before deciding to act.

Next step

Run AdminKit’s Whois/RDAP tool against the domain or IP address in question to confirm you have the current, correct abuse contact before sending a report — registrar and hosting assignments can change, and a report sent to a stale contact from an old lookup may never reach anyone who can act on it.

This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.