How to find the abuse contact for a domain
A domain used for phishing, malware or fraud has at least two parties who can act on it, and they are not the same company. The registrar controls the domain name. The hosting network controls the server the name points to. Each publishes an abuse contact in a different registry, and a report sent to the wrong one is a report that gets forwarded at best and ignored at worst.
This guide shows how to find both contacts by hand, using the same public sources an automated service uses.
Two parties, two registries
The registrar is the company the domain was bought through. It can suspend the name, which takes the whole site offline everywhere at once. It cannot remove content from a server. Its abuse contact lives in the domain registry's RDAP service, published because ICANN's 2013 Registrar Accreditation Agreement (section 3.18) requires every accredited registrar to publish an abuse email address and phone number and to act on reports.
The hosting network is the operator of the IP address the domain resolves to. It can remove the content, suspend the account or null-route the server. It cannot touch the domain name. Its abuse contact lives in the RDAP service of one of the five Regional Internet Registries: ARIN (North America), RIPE NCC (Europe, Middle East, Central Asia), APNIC (Asia-Pacific), LACNIC (Latin America) and AFRINIC (Africa). All five require an abuse contact on allocated address space, though how well it is maintained varies by operator.
A third party appears when the domain sits behind a content delivery network or reverse proxy. That case has its own guide: Reporting abuse behind Cloudflare and CDNs.
Step 1: the registrar abuse contact
RDAP is the JSON replacement for WHOIS. For generic top-level domains it is mandatory and the old port 43 WHOIS has been switched off since January 2025, so RDAP is the source, not a fallback.
The simplest way to reach the right server is the public redirector at rdap.org, which reads the IANA bootstrap file for you:
curl -sL https://rdap.org/domain/example.comFor a .com domain you can also go straight to the registry:
curl -s https://rdap.verisign.com/com/v1/domain/example.comIn the response, look at the entities array. The entry with "roles": ["registrar"] names the sponsoring registrar and carries its IANA ID under publicIds. Nested inside it is another entity with "roles": ["abuse"], and its vcardArray holds the email and telephone:
["email", {}, "text", "abuse@registrar.example"],
["tel", {"type": "voice"}, "uri", "tel:+1.5555551234"]That address is the one to use. Two things it is not:
- It is not the registrant's email. That belongs to whoever registered the domain, which for a malicious domain is the attacker.
- It is not the privacy-proxy address. Entries like
abc123@withheldforprivacy.comforward to the registrant, not to anyone who will suspend the domain.
Registry RDAP for .com and .net is "thin": it names the registrar but the abuse contact itself may only be in the registrar's own RDAP server, which the registry response links to under links with "rel": "related". Follow that link if the abuse entity is missing from the first response. Most other gTLD registries are "thick" and include it directly.
Step 2: the IP addresses
Resolve the domain yourself rather than trusting a screenshot or a ticket:
dig +short A example.com
dig +short AAAA example.comResolve every address, not just the first. Large sites return several, and a phishing kit on shared hosting often sits on a single IPv4 address with no IPv6 at all. Note the addresses and the time in UTC; hosting changes quickly once a campaign is noticed.
Step 3: the network abuse contact
Each IP belongs to exactly one RIR. Again, the redirector saves you from working out which:
curl -sL https://rdap.org/ip/203.0.113.10Or query the RIR directly once you know it, for example https://rdap.arin.net/registry/ip/203.0.113.10 or https://rdap.db.ripe.net/ip/203.0.113.10.
The response describes the smallest registered network containing the address: its range, name, country and entities. The entity with "roles": ["abuse"] is the one you want. Its email is usually a role mailbox such as abuse@hoster.example. Some RIRs, APNIC in particular, express it as an IRT object whose abuse-mailbox is what matters.
If the network is a large allocation to a hosting company that resells to customers, the abuse contact may be the hosting company rather than the reseller. That is fine: the hosting company can act on its own infrastructure and will forward to the reseller if it chooses.
Two regional details worth knowing. LACNIC delegates part of its space to national registries, so a Brazilian address answers with an HTTP redirect from rdap.lacnic.net to rdap.registro.br; follow it. RIPE NCC limits how many records containing personal data one address may fetch per day, so query for the network only and do not pull the referenced person objects.
Step 4: decide who gets the report first
If the domain resolves directly to the hosting network, send to the host first: they can remove the content within hours. Send to the registrar as well when the domain was clearly registered for the attack (a look-alike of a brand, registered days ago) rather than a legitimate site that has been compromised. Suspending a compromised legitimate domain punishes the victim and annoys the registrar.
If the IP belongs to a CDN, the host cannot be seen from outside. Report to the registrar and use the CDN's abuse channel, which forwards to the real host. Again, see the CDN guide.
Where manual lookups go wrong
- Reading a stale WHOIS record. Port 43 output for gTLDs is gone; tools that still show it are showing a cached copy.
- Using the technical or administrative contact. Those roles exist for network operations, not abuse. Many are unmonitored.
- Stopping at the first IP. Sites with two hosting providers need two reports.
- Trusting
whoison a CDN address. The record is correct, it is just Cloudflare's or Fastly's, and they do not host the content. - Reporting to the registrant. For a compromised site this is useful. For a malicious registration it is telling the attacker you noticed.
Country-code domains
The picture above is reliable for gTLDs. Country-code registries set their own rules. Many run RDAP now (.br, .co, .fr and others), some still answer only on port 43 in their own text format, and a few publish no registrar contact at all. .de returns registration status but no registrar contact through public queries. .uk publishes registrar details but Nominet's terms restrict commercial reuse of the data, so automated services may decline to return it. When the registrar contact is unavailable, the hosting network contact still is, and for content removal that is the one that matters.
Doing this at scale
Everything above is four or five HTTP requests per domain, plus judgement about which contact to use first. That is fine for one investigation and unworkable for a queue of two hundred phishing URLs a day, which is why abuse desks automate it. The pieces that are hard to get right in automation are the ones that are easy by hand: following RIR redirects, handling registries that return numbers as strings, spotting the CDN, and not hammering the registries so hard that they cut you off. Whichever way you do it, the two contacts above are the answer, and the registrant's address is not.
AbuseRoute is a private API that returns the registrar and hosting abuse contacts for a domain in one call, for security and abuse teams. How it works. For individual manual lookups, use the RrSG's ACID Tool.