Evidence first.
Corrections in the open.

Make the evidence inspectable

Our research examines publicly observable phishing infrastructure, public records and submitted evidence. Depending on the investigation, sources can include page captures, public scans, DNS and TLS records, domain registration records, transaction records and correspondence that is published with the material.

A report should identify its sources, the relevant dates, the method used and the limits of the observation. Distinguish a directly recorded fact from an inference, an allegation or an unresolved question. A relationship between infrastructure components does not, by itself, establish who controls them.

Preserve source references and the context needed to reproduce a public observation where practical. Avoid publishing credentials, private keys or unnecessary personal data. Public datasets and automated results are research inputs; they are not substitutes for evaluating the evidence behind a claim.

Match each claim to its source

Before publication, check material factual claims against the cited evidence. Prefer primary records and distinguish what a source says from what the research concludes. Check dates, units, domain names and quoted passages in their original context.

Use the central site-facts.json record for current platform totals. A domain being unreachable is not proof that a particular report caused its removal. Describe detection, reporting, unavailability and confirmed enforcement as separate events.

Automated checks can identify broken links, inconsistent totals and missing metadata. Human judgment remains necessary for attribution, interpretation, disputed claims and publication decisions. State uncertainty and the scope of a finding instead of presenting missing evidence as proof.

Keep changes accountable

To request a correction, send the publication URL, the exact passage, the proposed factual correction and supporting primary sources to abuse@phishdestroy.io. A report of an error is a request for review, not an automatic change to a published finding.

When a material error is confirmed, explain the correction, record its date and link it to the affected publication. Preserve the distinction between a factual correction, a later development and a change to presentation or navigation. Do not silently rewrite documentary evidence.

Protected dossier material follows its own review and versioning process. Requests concerning existing Steam dossier text go to human review; its corrections register and edition history remain the records for that publication.

Disclose relevant relationships

PhishDestroy is an independent, non-commercial anti-phishing research operation. Contributors should disclose financial, employment, personal or other relationships that could materially affect a reader’s assessment of a publication.

Relevant conflicts belong with the affected material. A person with a material conflict should not be the sole reviewer of the disputed claim. Requests for payment, sponsorship or reputation management must not determine whether supported findings are published, corrected or removed.

Make a specific, evidenced challenge

Subjects of research and readers can challenge a finding through our contact page. Identify the claim and provide evidence that contradicts it or supplies missing context. Review the merits of the evidence independently of whether the sender agrees with the publication.

Domain listing disputes use the appeals process. Vulnerability reports use security.txt. These routes serve different purposes; an appeal does not automatically resolve a disagreement about an article.

A dated record of this policy