Treat an email as suspicious if the sender address is not an exact match, the message includes spelling errors, the request feels out of context, or the attachment and link do not fit the conversation. Known contacts can be impersonated, so trust should come from verification, not familiarity. When the message is unexpected, confirm through another channel before opening anything.
Why a Message from a Known Contact Can Still Be Unsafe
Attackers commonly rely on familiarity to lower your guard. A message that appears to come from a colleague, friend, client, or supplier can still be malicious if the sender identity has been spoofed, the account has been compromised, or the conversation has been hijacked after a real exchange started. The key question is whether the message fits the relationship and the moment, not whether the name looks familiar.
Signs that the message is unsafe include a sender address that is close but not exact, a tone or request that does not match the person’s normal style, and a sudden push to act quickly, bypass process, or share information. Small errors, unusual grammar, and awkward phrasing matter most when they appear alongside a request that would be unusual from that contact.
When the message asks you to open a link, download a file, approve a login, or change payment details, treat the combination of context and action as the real warning signal. A legitimate contact may still be a poor delivery channel for a message that is out of sequence, especially if it involves credentials, money, or access.
What to Check Before You Trust the Sender, Link, or Attachment
Start with the sender details, then inspect the destination and payload. An exact-match address matters more than display name, and the visible text of a link matters less than the actual destination behind it. If a link points somewhere unexpected, or an attachment type does not fit the discussion, the safest assumption is that the message is not trustworthy until proven otherwise.
Verification should be independent of the message itself. If the email says “I sent this from another account” or “just review quickly,” confirm through a separate channel you already trust, such as a known phone number, chat thread, or in-person confirmation. This is especially important when the request is urgent, unusual, or framed as confidential, because those are common pressure patterns in phishing and business email compromise.
Checking the surrounding conversation also helps. A malicious message often breaks the thread’s normal pattern by introducing a new attachment, changing banking details, redirecting a file-share link, or asking for a password reset or approval. If the action would be unusual even for a real sender, that mismatch is itself a warning sign.
How to Respond Safely Without Slowing Legitimate Work
The right response is to pause, verify, and then act only if the request is confirmed. Do not use the reply button as proof of authenticity, because attackers can place themselves inside an existing conversation or mimic a known sender closely enough that a quick reply only keeps the attack alive.
Good practice is to separate message review from action. You can inspect the header, hover over links, and assess the context without opening attachments or enabling content. If the message is work-related, use the organisation’s reporting path so security or IT can check whether the sender account is compromised and warn others who may have received the same lure.
If you already clicked, downloaded, or entered information, treat the event as potentially serious even if nothing obvious happened. The next step is to report it promptly and, where relevant, reset credentials, review recent account activity, and check whether the message led to further redirects, prompts, or login pages.
Risk and Threat Considerations
Familiarity is one of the most effective social-engineering advantages because it reduces scrutiny at the exact moment a message asks for action. The danger is not just a fake email, but also a real account that has been compromised and is now being used to send convincing internal or relationship-based requests.
Failure mechanism: The attacker exploits trust in a known sender, then uses a close-lookalike address, a hijacked thread, or a believable attachment or link to bypass normal caution and drive a harmful action.
Impact: The result can be credential theft, malware delivery, invoice fraud, account takeover, or wider lateral abuse if the recipient follows the request or forwards the message internally.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API2 — Broken Authentication | Phishing messages often aim to steal login credentials or session access. |
| Recommendation — Enforce strong authentication checks and scrutinise login prompts reached from email links. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | Suspicious messages warrant review and reporting to detect misuse and follow-on abuse. |
| Recommendation — Review and report suspicious email activity quickly to support detection and response. | ||
| CIS Controls v8 | CIS-9 — Email and Web Browser Protections | The question is about unsafe email, links, and attachments, which this safeguard directly addresses. |
| Recommendation — Harden email and browser handling of links and attachments before users open them. | ||
| MITRE ATT&CK | T1566 — Phishing | The scenario describes phishing-style social engineering through email, links, and attachments. |
| Recommendation — Map suspicious messages to phishing techniques and train detection around sender, link, and attachment cues. | ||
| NIST CSF 2.0 | PR.AA-05 — Authentication | Verification should rely on authenticated channels, not familiarity with the sender. |
| Recommendation — Use authenticated channels to confirm unexpected requests before acting on them. | ||
Practitioner Guidance
What to verify: Verify the sender outside the message before approving anything that changes access, money movement, or document handling. If the request is real, a second-channel confirmation should be easy to obtain and consistent with the request.
Common mistake: Do not treat a known name, an existing thread, or a professional-looking signature as proof. Those are exactly the cues attackers try to imitate, and they fail open when the recipient assumes familiarity equals legitimacy.
Practitioner takeaway: The practical rule is simple: trust the relationship only after you have verified the message, because the most convincing phishing attempts are the ones that borrow an identity you already recognise.
Related resources from NHI Mgmt Group
- What are the signs that email based ransomware delivery is bypassing traditional link and attachment filtering?
- What are the signs that a phishing email is using an attachment to hide a malicious link?
- Why do phishing attacks still succeed even when people know the warning signs?
- How do you know if email identity controls are actually working?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org