Writing an abuse report that gets actioned
Abuse desks at hosting providers and registrars work through queues. A report they can verify and act on in two minutes gets actioned. A report that needs a reply asking for the URL, or a screenshot, or which of the twelve domains in the email is the problem, goes to the bottom and often never comes back up. The difference is almost entirely in what you send the first time.
What the recipient has to be able to do
Put yourself on the other side. The person reading your report needs to:
- Find the thing. An exact URL, or an IP and port, or a message they can locate in their logs.
- Confirm it is what you say. Evidence they can check without trusting you.
- Match it to a customer. Their systems key on IP, hostname or domain, at a specific time.
- Know what you want. Content removal, account suspension, domain suspension, or just notification.
- Reach you if needed.
Every field in the template below exists to serve one of those five.
The fields
Subject line. Type of abuse, the domain or IP, and nothing else: Phishing: secure-login-yourbank-verify.com impersonating YourBank. Desks triage from the subject. "Urgent!!!" and "Please help" are triaged last.
One incident per report. Ten URLs on one host can go in one report to that host. Ten URLs on ten hosts are ten reports. A registrar report covers one domain.
The exact URL. Full, including scheme, path and query string. Do not defang it (hxxp://, [.]) in a report to an abuse desk; they need to click or paste it, and defanging is for chat and tickets inside your own organisation. If your mail system rewrites links, send plain text.
The IP and the time. The address you resolved the domain to, and when, in UTC with the zone written out: 2026-09-29 09:14 UTC. Shared hosting moves; the desk matches on address and time. For an email report, the sending IP from the Received: header that handed the message to your server.
What it is. One sentence: phishing impersonating which brand, malware distribution of what, command-and-control, spam source, scanning. The desk classifies on this.
Evidence. A screenshot of the page as rendered, with the URL bar visible. For phishing, a note of what the page asks for (credentials, card numbers). For email, the complete original message as an .eml attachment or pasted in full with all headers; a forwarded copy strips the headers that matter. For malware, the SHA-256 of the sample and where it was fetched from; do not attach live malware unless the recipient has asked for it, and then in a password-protected archive with the password in the report.
Why they are the right recipient. One line: "the domain resolves to 203.0.113.10 in your AS64500" or "your RDAP record lists you as the sponsoring registrar (IANA ID 1234)". It shows you looked, and it pre-empts the "not our customer" reply.
Registered or compromised. Say which you think it is and why (registration date, URL path). It changes what a good desk does.
What you want. Removal of the content and suspension of the account, or suspension of the domain, or preservation of evidence for law enforcement. Ask for one thing.
Who you are. Name, organisation, role, a reply address that is monitored. If you are the impersonated brand or acting for them, say so; it moves the report up the queue. If you are not, do not imply that you are.
The template
Subject: Phishing: <domain> impersonating <brand>
Hello,
I am reporting a phishing page hosted on your network.
URL: https://<domain>/<path>
Resolves to: <ip> (observed 2026-09-29 09:14 UTC)
Your record: <ip> is within <cidr>, <netname>, per <RIR> RDAP
Type: Credential phishing impersonating <brand>; the page requests
online banking username, password and one-time code.
Domain: Registered 2026-09-20 via <registrar>; no legitimate content
observed. I believe it was registered for this purpose.
Evidence: Screenshot attached (page as rendered, URL bar visible).
HTTP response headers attached.
Request: Please remove the content and suspend the responsible account.
I can provide further detail on request.
<Name>
<Role>, <Organisation>
<monitored reply address>For a registrar, replace the middle block with the RDAP facts about the domain (registrar, IANA ID, registration date, status) and ask for suspension. For an email source, replace the URL block with the sending IP, the Received: line it appears in, and attach the .eml.
What gets a report ignored
- No URL, or a URL inside a screenshot only.
- A dozen unrelated incidents in one message.
- Legal threats in the first contact. Desks are used to them and they change nothing.
- CCing the registrar, the host, the CDN, two CERTs and the brand on one email. Each recipient assumes another will act.
- Reporting to
postmaster@,info@,webmaster@or the registrant. Use the published abuse contact; the contact-finding guide shows where it is. - Asking a hosting provider to suspend a domain, or a registrar to remove a file. Neither can.
- Sending the report from an address that cannot receive replies.
Machine-readable formats
If you send reports in volume, two formats let the receiving side automate intake. ARF (RFC 5965) is the standard for email feedback and is what most feedback loops expect. X-ARF extends the idea to other abuse types with a YAML block describing the incident, and a number of large European hosts parse it directly. Neither is required; a well-structured plain text report is parsed by a human just as reliably. Use them when the recipient documents that they accept them.
Following up
Allow 48 hours for a host and 72 for a registrar before a follow-up. Reply on the same thread, quote their ticket number if they gave one, and add only what is new: the page is still live as of a fresh timestamp, and a fresh screenshot. Do not resend the original report as a new message; it opens a second ticket that competes with the first.
If a second follow-up produces nothing, escalate rather than repeat. For a host, the RIR record shows the larger allocation the address sits in; the upstream network's abuse desk can pressure or disconnect its customer. For a registrar, the registry that operates the top-level domain has its own abuse process, and ICANN's compliance team takes complaints about registrars that do not act.
Keep a record
Log every report: recipient, address, timestamp, ticket number, and when the content went down. After a few months you will know which desks act on first contact, which need the follow-up, and which only respond to their upstream. That record is worth more than any template, because it tells you where to send the next one.
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.