A lookalike name is a lead, not a complete abuse case. The report should show what happened, where the relevant evidence came from and what the receiving provider can investigate. Preserve the original before making a convenient sharing copy. Separate similarity, observed conduct and inferred responsibility.
Capture the exact identity
Record the complete domain spelling, the visible From address, Reply-To, envelope identity where available and any relevant URL without activating it. A screenshot can show the impersonation seen by a recipient, but it does not preserve all message headers. Export the raw message through an authorized process and retain its original bytes. Keep the received time with timezone and distinguish it from the sender-supplied Date field.
DMARC concerns the relationship between authenticated domains and the author domain. It does not make a visually similar domain part of your domain's policy. A lookalike can authenticate for itself. RFC 9989. State that distinction in the report so a pass does not erase the observed impersonation.
Establish provenance before attribution
An Authentication-Results field is meaningful only within a known trust arrangement. An attacker can insert a convincing-looking field. Ask the receiving mail team for its trusted results and correlate them with the message record; do not treat every copied header as receiver evidence. RFC 8601.
Keep a case owner, collection method, collection time, original-file hash and access location. Hashing helps identify the same bytes later; it does not prove who sent them or that the content is truthful. Preserve source IPs as routing clues, not conclusive personal attribution. Shared infrastructure and intermediate hops require further corroboration.
Build a minimal sharing package
Prepare an incident summary stating the exact observed behavior, affected identity, evidence times, known impact and requested investigation. Attach a redacted copy only after deciding which fields the intended recipient needs. Retain a transformation log linking it to the original. Do not remove the very URL or domain needed to understand the allegation without supplying it through an appropriate secure channel.
ICANN's registrar guidance distinguishes actionable evidence from a bare allegation and gives examples such as the abuse URL and evidence of the phishing representation. Its contractual framework concerns gTLD registrars and registries, not every hosting or country-code domain dispute. ICANN advisory.
Follow a bounded written evidence ledger
Assume case DEMO-ABUSE-01 describes visible From billing@brand-payments.test and an untrusted header assertion naming brand.test. Preserve both values, but record trusted receiver authentication as unavailable. The reported identity and the copied assertion differ; neither proves who operated the sender. No original message bytes, collection time or computed hashes are supplied here.
The proposed collection ledger contains: case owner, authorized collector, collection method, receiver-observed time and timezone, original file location and original hash. The sharing ledger separately contains: intended recipient, approved purpose, redacted fields, derivative location and derivative hash. For this example all actual file and approval fields remain not supplied. Do not fill gaps with plausible-looking values.
The next action is to obtain a trusted receiver export and document the observed abusive behavior before a recipient-specific sharing decision. No synthetic file was generated, hash computed, domain looked up, provider contacted or takedown requested for this teaching revision. The ledger illustrates evidence discipline, not a completed abuse report.
Before a real submission, verify the destination independently, obtain authorization to share the relevant data and record the submission receipt. Keep urgent account or payment protection separate from the provider's review. A complete report makes investigation easier; it does not promise removal.
Keep findings within the evidence
The examples are defensive decision aids, not observed allegations against real people or current providers. Retain authentication evidence, business verification and attribution separately. Current protocol sources describe domain validation and trusted result boundaries; they do not supply the missing account evidence or authorize publication of an accusation.