Understand the XARF v4 structure: reports are JSON objects with a shared envelope (schema_version, report_id, reporter object, reported_at timestamp in ISO 8601 UTC) and a category-specific payload from one of seven categories (Spam, Phishing, Malware, NetworkAbuse, ContentAbuse, Fraud, or Other) covering 32 defined types.
To file an abuse report, construct a JSON object matching the appropriate XARF v4 schema; validate against the official JSON Schema files published in the xarf/xarf-spec GitHub repository before sending.
Locate the abuse contact for the reported IP or domain: query RIPE Whois (whois.ripe.net), ARIN, or APNIC for the abuse-c handle; use the Abusix Contact DB API for automated lookups that aggregate abuse contacts across all five RIRs into a single query.
Deliver the XARF report to the abuse contact's registered email address as a JSON attachment with Content-Type application/json, or via an HTTPS POST if the receiving organisation publishes an abuse API endpoint; include a human-readable summary in the email body.
To receive XARF reports, publish an abuse contact in your WHOIS record and optionally expose an HTTPS endpoint that accepts POST requests with Content-Type application/json; validate incoming JSON against the xarf/xarf-spec schemas and acknowledge receipt with an HTTP 200 response.
Automate report triage: parse report_type to route to the correct team (Spam to anti-spam, NetworkAbuse to NOC, Phishing to security); use reported_at and evidence fields to correlate with your own logs; close reports with a follow-up notification to the reporter.
Known gotchas
XARF v4 is the current specification as of early 2026; older XARF v2/v3 reports still circulate from legacy abuse-reporting systems—your ingestion pipeline must handle both versions or explicitly reject older schemas with a clear error message.
Many receiving abuse desks still accept only plain-text ARF (Abuse Reporting Format, RFC 5965) emails rather than XARF JSON; check the receiving organisation's abuse desk documentation before sending XARF and fall back to ARF if necessary.
Never include actual malware samples or live exploit payloads in a XARF report body; reference external sandbox analysis URLs or hash values instead, and strip any executable content before transmitting.
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp