How it works
You upload an .eml email or a screenshot and verdict runs it through an analysis pipeline. Each stage contributes signals; they are combined into a 0-100 risk score. The six steps below are the email path; what changes with a screenshot is at the end.
-
1
Parsing
Headers, addresses, body and attachments are read. Hashes (MD5, SHA-1, SHA-256) are computed for each attachment to identify it without opening its content.
-
2
Headers
The
Receivedchain and the SPF, DKIM and DMARC authentication results are reviewed. This is where sender spoofing and thread hijacking hints show up. -
3
Body
URLs are extracted and the text is checked for social engineering patterns, brand impersonation and hidden HTML designed to fool the reader or the filters.
-
4
Attachments
Macros, dangerous extensions and mismatches between the declared extension and the file's real MIME type are detected.
-
5
Enrichment
Optionally, the indicators (hashes, IPs, domains, URLs) are checked against threat intelligence services. In "offline" mode this stage is skipped and nothing leaves your server.
-
6
Score
All signals are weighted into a 0-100 score with three levels: Clean (0-29), Suspicious (30-59) and Malicious (60-100).
What if you upload a screenshot?
An image has no headers and no attachments, so steps 1, 2 and 4 don't apply: there is no SPF or DKIM to check. What we do is read the text with OCR (Spanish and English) and hand it to step 3 unchanged. That is why a screenshot and an email that say the same thing score the same: same impersonated brands, same urgency wording, same domains.
If there is a QR code, it gets decoded. Any URL inside is analyzed like any other URL from the body, step 5 included. And if it is a payment request (Pix, Yape/Plin, CoDi, Bre-B) we verify its checksum: a payment QR with a broken CRC gives away that someone edited the payee by hand.
No AI vision: the OCR and the QR reader run on our server, in an isolated process, and the image is not stored.