Attribution guide
How to find what is really behind a scam email
A display name is a costume. Reliable attribution climbs from the preserved message to domains, provider roles, account records and only then—when evidence supports it—to a person.
Start with the identity the message claims
Record the visible name, From address, subject, brand and requested action. These explain the story presented to the recipient. They do not establish who sent the message. A copied name or logo is evidence of impersonation, not evidence against the person or company being copied.
Identify the technical sender
Use the envelope sender, authenticated DKIM domain, SPF result, Message-ID domain and earliest trustworthy Received hop. These fields may connect the delivery to a mail platform or account domain. A passing result proves control of the authenticated domain or account path at sending time; it does not prove the message was honest.
Map the action infrastructure
Extract the destination from the original source without asking the recipient to click. Separate tracking, redirect, reverse-proxy, landing, checkout and file-hosting roles. Record exact URLs privately, then publish only the domains, IPs and observations needed to explain the case.
Name providers by role
Public DNS, RDAP and IP-allocation records can identify a registrar, DNS provider, network, cloud platform or toll-free administrator. Those companies provide infrastructure and may have records that identify a customer. Their appearance in the chain is not evidence that they authored or approved the scam.
Ask for records that can bridge the gap
A useful provider report asks for preservation of subscriber, payment, authentication, access and change records tied to the exact object and time. Providers and lawful authorities can correlate private records that a recipient cannot see. This is the point where two domains on the same network may—or may not—connect to one account.
Treat a person's name as the final claim
A natural person should be named only when independent records connect that person to control of the abusive account or service. A Gmail profile, sender label, writing style, phone listing, shared IP or reused template is not enough. State the strongest supported conclusion and state the missing evidence plainly.
Use an attribution ladder in every report
Label each fact as claimed identity, authenticated sender, observed action domain, public provider attribution, provider-confirmed subscriber or independently verified person. This prevents an infrastructure clue from turning into a false personal accusation and tells the next investigator exactly what remains to be established.
Action checklist
- Preserve the original message before making an identity claim.
- Separate claimed identity, technical sender, action host and provider role.
- Name a person only when independent evidence connects them to control.
Questions people ask
Can a shared IP prove two scam sites have the same owner?
No. Shared hosting can place unrelated customers on one address. A shared IP supports correlation work, but account and access records are needed to prove common control.
Can I publish the domains and providers I found?
You can publish accurate technical indicators and provider roles when they are relevant and safely redacted. Explain the observation date and avoid presenting an infrastructure provider as the perpetrator.
Why not publish the sender's personal-looking name?
Because it may be invented, copied or attached to a compromised account. Publishing it as the operator without independent evidence could accuse the wrong person.