What a Security-Vendor False-Positive Report Must Contain (Checklist + Example)

unflagdomain Team·UPDATED September 24, 2026
// ANSWER

A security-vendor false-positive report for a website must contain the exact URL, the vendor's detection name if shown, one line on what the site is, what was found or that nothing was, what was removed and when, what changed so it stays clean, how that was verified from outside, and one contact email. Five to seven sentences, plain text, no attachments, one report per vendor. Reports are rejected for vagueness far more often than for anything else.

The checklist

  1. The exact URL or URLs. With protocol, exactly as the vendor shows them. A domain-level report for a URL-level flag is routed nowhere; a URL-level report for a domain-level flag is fine.
  2. The vendor's own detection name or category. If the vendor, its block page or VirusTotal shows one — 'URL:Phishing', 'Malicious Websites', 'Suspicious' — quote it. It routes the report to the right queue.
  3. What the site is. One sentence: a bakery in Ghent, a SaaS login page, a WordPress blog. Reviewers triage faster when they can picture the legitimate site.
  4. What was found — or that nothing was. If there was a compromise, say what: an injected redirect in a theme file, a phishing directory, spam pages. If the site was never compromised, say it was reviewed and is clean. Do not invent a cleanup that did not happen.
  5. What was removed and when. Paths and dates. 'Malicious files removed on 12 September; wp-content/uploads/2024/x.php deleted; theme restored from a clean copy.' This is the line most rejected reports lack.
  6. What changed so it stays clean. CMS and plugins updated to named versions, credentials rotated, unknown admin users removed, a WAF or 2FA added. Vendors and Google both weigh this — it is the difference between 'cleaned' and 'fixed'.
  7. How it was verified from outside. Fetched from another network and a mobile user agent on a date; the URLs return 404 or the clean page. Cloaked malware is invisible to the owner and visible to the vendor's crawler.
  8. A reply address, and nothing else. One contact email. No attachments, no screenshots of the warning, no marketing language, no urgency, no follow-up every hour. One report per vendor, plain text.

Why reports get rejected

  • “The site is clean now.” No paths, no dates, no verification. The reviewer has nothing to check except the live site — and if their crawler still sees something, the report loses.
  • The content is still reachable on a URL that was not mentioned, a subdomain, or only for a mobile user agent. Reviewers re-scan; owners test from their own desk.
  • The wrong channel: a website flag reported through a file-submission form, a Norton rating sent to Symantec's enterprise form, a VirusTotal comment instead of a report to the engine.
  • Pressure instead of facts: lost revenue, legal threats, a list of other vendors that already cleared it. None of it changes what the crawler finds.

Example: a site that was never compromised

The shape our dispatch generator produces for a false-positive case — an illustration on example.com, not a customer's message. Note what it does not do: it does not claim a cleanup that never happened.

Subject: Request to re-evaluate example.com — false positive on a clean site

example.com, a small online shop for handmade leather goods, is currently flagged by your service as a malicious website.

The site was reviewed after the flag appeared and is clean. There was no compromise: no injected scripts, redirects or unexpected files were present. The CMS and all plugins are on their current versions and administrator access is protected with two-factor authentication.

The pages can be checked at https://example.com/ from any network. Please re-evaluate the domain and remove the classification.

Contact for this request: [email protected]

Example: a site that was hacked and cleaned

Same length, different second paragraph: what was found, what was done, when, and how it was verified.

Subject: example.com — cleaned, please re-scan

example.com is flagged by your service as hosting malware.

The cause was an injected JavaScript redirect in the active theme's header file and a spam directory under /old/, introduced through an outdated contact-form plugin. On 12 September 2026 the theme was restored from a clean copy, the /old/ directory was deleted, the plugin was updated to 5.9.2, all administrator passwords and API keys were rotated, and a web application firewall was enabled. The affected URLs now return 404, verified from an external network on 13 September.

Please re-scan https://example.com/ and remove the flag.

Contact for this request: [email protected]

Per-vendor variations

Some vendors add a required detail: ESET wants the subject line Domain whitelist <domain>; Sophos wants the URL in the subject written as hxxps:// and the body to name the correct category; Google wants the description per listed issue inside Search Console. The vendor guides carry those specifics and a template each.

// CHECKLIST FAQ
  • No. Each vendor reviews its own verdict and does not care about the others; mentioning them reads as pressure. Send one report per vendor, each about that vendor's flag only.

  • No. Attachments get email reports filtered and forms rarely accept them. A vendor re-scans the live URL itself; what it needs from you is the URL, what changed and when. If the vendor's form has a screenshot field, it is optional.

  • Five to seven sentences. A short, specific, plain-text message reads as written by the owner; a long one reads as templated. The two examples on this page are the right length.

  • If the site was reviewed and nothing was found, say exactly that and describe the review — do not guess at a cause or claim a cleanup. If you have not reviewed it, do that first: vendors re-scan on review, and a flag on a site that still hosts something will be renewed, not removed.

  • A contact email is enough and is what most vendors ask for. The report is about the site, not the sender; a signature block, a job title or 'on behalf of' adds nothing a reviewer uses.

  • Yes, in shape: one plain-text message per flagging vendor, written from your cleanup description in the format that vendor accepts, with your address as the contact, no attachments and no marketing language. Form-only vendors get the same text as a prepared card for you to paste.