I forwarded Claude a suspicious email with one line: “i fw email to you, i assume spam, can you review.” The email was an introduction request.
Claude called it spam, a lead-gen bait email, and said not to reply. It gave three reasons.
Three things it checked
The email named nothing specific. It didn’t name the partner, my firm or anything I’ve done. Claude’s point was that the whole purpose is to get me to write back “yes, that’s me.”
The .co domain redirected. The sender’s domain was a .co, and the .com version of the same name is a separate site. When Claude visited the .co address, it redirected to a different company name. A real partner firm’s site doesn’t forward to another brand.
The mail ran on Microsoft 365. Claude said plainly that this is normal for lots of companies, but it’s also the usual setup for a throwaway cold-outreach domain.
What a reply would have done
Claude said a reply usually marks your address as live and leads to a “growth partner” or financing pitch. It added that this last part is its read of the pattern, not something it could prove from this one email.
What got logged
I closed the session, and about 24 minutes were logged for it. The review also produced a finding: inbox-watch ignores forwards from an email address.
AI Skills
Use this lesson with the AI assistant you already use
The author forwarded an introduction request email they assumed was spam and asked Claude to review it. Claude called it lead generation bait and advised not replying, based on three observable signals.
Paste the prompt, share only the context needed to answer it, and treat the result as a draft for your review. Do not include confidential information or let an AI assistant make changes without your approval.
The prompt works in any AI assistant as it is. We are also building a /dxdev skill for visual reports and saved memory.
It is not released yet: see what you can use today.
dxdev LESSON · paste into your AI coding agent
LESSON: Judge A Cold Introduction By What It Names And Where Its Domain Leads Before You Reply
SOURCE: dxdev.com/blog/stranger-intro-request-is-spam
WHAT HAPPENED: The email named no partner, no firm and nothing the author had done, so its only purpose was to get a reply confirming the author was the right person. The sender used a .co domain, and visiting it redirected to a different company name, which a real partner firm's site would not do. The mail also ran on Microsoft 365, which Claude noted is common for legitimate companies but is also the usual setup for a throwaway outreach domain. Claude said a reply would likely mark the address as live and lead to a growth partner or financing pitch, while flagging that this last part was its read of the pattern and not provable from one email. The review also surfaced a gap in the author's tooling, because inbox-watch ignores forwards from an email address.
THE RULE: Before replying to an unsolicited introduction, check whether it contains anything specific and verifiable, and whether the sender's domain behaves like the business it claims to be. Treat a reply as a signal you are giving the sender, and label inferences about intent separately from facts you confirmed.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
1. The message names a specific person, firm or past work that you can independently confirm, not just a generic request to connect.
2. The sender's domain, when visited directly, resolves to the same brand the email claims and does not redirect to a differently named company.
3. No reply is sent to a stranger until the first two checks pass, and any weak signal such as the mail provider is recorded as supporting evidence only, not as proof.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.
