How we analyse a scam email

Every post on this site is a case study of one real message. This page explains how that message becomes an analysis, what the analysis can and cannot prove, and how to tell us when we got something wrong.

What we capture​

• The headers as received. The display name, the sending address, any reply-to, the domain that actually relayed the message (Mailed by / Signed by), and the time it arrived. These come from the mail client's "show original" view, not from the text of the email.
• The body, verbatim. Typos, machine-translation artefacts, broken formatting and emoji are kept, because they are evidence. Where a message is not in English, the original is reproduced and translated alongside.
• A screenshot of the message as it appeared in the inbox.
• Attachment names and sizes, taken from the mail client. The attachments themselves are not opened.

What we look up​

Only passive, registry-side records that never touch the attacker's systems:

• whois on every domain and IP address in the headers and links: registration date, registrar, hosting provider.
• dig for DNS records: mail records (or their absence), name servers, where a domain actually points.
• Public facts that the email relies on: whether a cited law, section, officer, company or prize exists, and whether it works the way the message claims.

What we never touch​

Links, attachments and landing pages are treated as live malware and are not opened, downloaded, fetched, previewed or scanned - not in a sandbox, not "just to see". Contacting a scammer's server tells them the address is live and hands them a visitor to profile. When a link or attachment looks worth investigating, the post says so and stops there. One post (the court-notice disk image, September 2026) followed a link to its payload and read the file without running it; it says so in its own "At a glance" box, and that is not how analyses are done now.

Redaction​

The recipient is not the story. Recipient addresses are blurred in screenshots or omitted from the header block, and a recipient's personal name or personal mailbox in a subject line is replaced with [recipient]. Role mailboxes such as info@ and the names of the organisations that received the messages are kept, because attackers often spoof them and that is part of the evidence. Everything on the attacker's side - addresses, domains, phone numbers, reference numbers, wallet addresses - is published exactly as sent.

What the email proves, and what we infer​

Analyses written since 2026, and a few from 2025, separate two kinds of statement:

• Red Flags cite evidence in the message itself or in the registry records: a domain registered nine days earlier, a reply-to on a different service from the sender, a section of law that does not say what the email says, a fee that has not existed since 2021. These are observations.
• How This Scam Works describes how this family of scam typically progresses after the first reply, based on the many previous specimens of the same template and on published reporting. It is an inference from the scam's genre, not a record of what this particular sender did next - we do not reply.

Posts from 2024 and most of 2025 predate this split: they stop at Red Flags and a Conclusion, and any inference about what follows a reply is folded into those sections. They gain a separate How This Scam Works section when they are re-reviewed (see Last reviewed, below).

Where a claim is inferred rather than observed, the post says "typically", "in most variants" or "is built to"; if you find an inference stated as fact, that is a correction we want to make.

Dates on a post​

• Published - the date in the post, shown under the title.
• Received - the date the email arrived, from the header block, shown in the "At a glance" box. Older posts did not record it, and say so.
• Last updated - shown at the foot of the post; the date the post's source file last changed in version control. This includes formatting and metadata edits, so it is not a review date: many posts share the same date because they were re-tagged in one pass.
• Last reviewed - set by hand only when the whole analysis has been re-checked end to end. If a post does not show one, it has not been re-reviewed since publication.
• Corrections - listed at the top of the post with a date and what changed.

Corrections​

If a post contains an error - a fact, a date, a claim about how something works, a misattributed name - write to security@dewiride.com with the post's link and what is wrong. Changes to a published claim are always made in the post and noted in its Corrections list with the date; nothing is corrected silently.

Who writes this​

The analyses are written by Jagdish Kumawat, founder of Dewiride Technologies, the company that receives most of the messages published here. Readers contribute the rest through the report form.