Why impersonation matters to small businesses
A fraudulent email can look like an ordinary supplier invoice, customer request or message from a manager. The attack may try to obtain a password, redirect a payment, collect private information or persuade someone to open a harmful file. Small teams are vulnerable because one person may handle sales, finance and support without a separate approval department. The safest response begins by recognising unusual requests and checking them through a known independent channel. A familiar logo, professional writing style or apparent previous conversation does not establish authenticity. Train staff to verify the action requested, not merely the visual appearance of the message.
Understand phishing versus business email compromise
Phishing broadly uses deceptive communication to induce a harmful action, often through a link, attachment or request for credentials. Business email compromise may involve an attacker impersonating an executive, supplier or customer to redirect money or sensitive data. Sometimes the attacker controls a real mailbox rather than a lookalike address, making the message harder to distinguish. Microsoft describes compromised accounts being used to send fraudulent messages and to create forwarding rules. Do not assume a message is safe because it came from a previously trusted address. Focus on whether the requested change is legitimate and independently authorised.
Look for pressure to bypass a normal process
Fraudulent requests often create urgency: a payment must be completed before a deadline, a director cannot be reached by phone, or an account will supposedly close unless someone signs in immediately. Urgency alone is not proof of fraud, because real business emergencies exist. The warning is the combination of pressure and a request to bypass established verification or approval. A well-designed process should work even when a sender claims to be senior. Staff can acknowledge the request without transferring money, disclosing passwords or opening unfamiliar attachments. Verification should use a previously established contact route, not the number supplied in the suspicious message.
Examine the full sender address carefully
An email client may display a friendly name prominently while hiding the actual address. Attackers can choose a display name resembling a colleague or supplier, or register a domain with a subtle spelling difference. Expand the sender details and compare the domain with a known legitimate record. This check is useful but not conclusive: an attacker can sometimes send from a compromised genuine account, and legitimate businesses may use third-party sending platforms. Do not rely on the display name, profile image or address alone. If the message requests a new payment destination or credential action, verify the request through an independent channel regardless of how familiar the sender looks.
Treat unexpected payment changes as high risk
A supplier email asking to change bank details can be especially consequential because a single payment may be difficult to recover. Verify the request using a phone number or other contact route established before the message arrived, and follow the company's approved finance controls. Do not trust a new telephone number in the same email as the changed account. Keep a record of who requested, independently verified and authorised the change. The same principle applies when a customer asks for an unusual refund destination. This is a workflow safeguard, not a claim that every account-change request is fraudulent or that any payment has actually occurred.
Verify links without opening an unknown destination
Phishing messages may use link text that looks like a familiar service while the underlying destination is different. On some devices, the full address is not visible until a link is inspected. Even a correctly spelled domain can host a malicious page if the service or account is compromised. The safest approach for an unexpected sign-in or payment request is to open the known service directly through a trusted bookmark or app, not through the message. Do not enter passwords or one-time codes on a page reached from an unverified email. A padlock or HTTPS indicator only describes connection security, not the trustworthiness of the sender.
Handle attachments according to business context
An unexpected attachment may contain malicious code, a misleading document or instructions to visit a fraudulent site. File names and icons are not reliable proof of safety, and a familiar format does not guarantee harmless content. If the attachment is unrelated to an expected transaction, confirm its purpose with the sender through a known independent route before opening it. Use the organisation's approved scanning and document-handling process, especially for files that request macros, software installation or changes to device settings. Avoid forwarding suspicious files casually to colleagues, which can spread risk. Preserve evidence for authorised security review when necessary.
Recognise fake account and password alerts
An email claiming that a mailbox will be suspended unless the user confirms a password is a common type of social engineering. The message may imitate the logo and layout of a real email provider. A legitimate account issue should be checked through the provider's known sign-in page or administrative console, not through an unexpected link. Staff should never share a password, recovery code or authenticator approval with someone who contacts them by email. If a warning appears within the actual provider application, follow the provider's documented process. Train employees to report confusing prompts rather than guessing under pressure.
Understand why good grammar is not a guarantee
Older phishing examples often emphasised spelling mistakes, but professional-looking writing is now easy to produce. A fraudulent message may use accurate business terms, an appropriate signature and a convincing thread subject. Conversely, a genuine supplier may write imperfectly. Language quality should therefore be a supporting clue, not the deciding test. Compare the request with established purchasing, password and approval procedures. Ask whether the action is expected, whether the contact channel is trusted and whether the requested destination has changed. A policy that relies only on obvious typos will miss more convincing impersonation attempts.
Do not treat an existing thread as proof
Attackers who gain access to a mailbox may read past conversations and reply within a genuine thread. The message can then contain accurate invoice numbers, names and previous decisions. That context makes the fraud more persuasive but does not independently authorise a changed bank account or new file-sharing destination. Apply the same verification controls to material changes even when the conversation history appears correct. Ask a known contact through a separate established route and record the confirmation. This is especially important when the request differs from the original contract or ordinary workflow. Trust in a thread should not override control of a transaction.
Distinguish lookalike domains from display names
A display-name spoof uses a familiar visible name while the actual address may be unrelated. A lookalike-domain attack uses a newly registered or otherwise controlled domain whose spelling resembles the genuine business domain. Both can mislead someone who checks only the first few characters. Maintain a reliable internal directory of supplier and colleague contact details, including the correct domains where practical. Do not assume every unfamiliar domain is fraudulent; legitimate companies may operate several brands or service addresses. Verify a surprising address change directly with the known organisation rather than relying on a search result or the contact information supplied in the message.
Know what SPF, DKIM and DMARC can establish
Email authentication records can help receivers evaluate whether a sending system is authorised and whether the relevant domain identities align. They do not prove that the human who wrote the message is honest. An attacker controlling a real authenticated account can still send convincing fraudulent requests. A message can also pass a technical check for a domain that is merely similar to a trusted company's name. Treat authentication results as useful technical evidence alongside business-process verification, not as a substitute for it. Staff do not need to interpret every header manually; they need a safe escalation path when a transaction looks unusual.
Use independent verification for high-impact requests
Define which requests require a second channel before action: new supplier bank details, unusually large payments, confidential data exports, account recovery or urgent access changes. The verifier should use a phone number, internal directory or approved contact method that existed before the suspicious message. A reply to the same email is not independent if the mailbox may be compromised. Record the verified person, date and decision according to company policy. This control should be proportionate and practical, not an invitation to delay every ordinary enquiry. Clear thresholds help staff act consistently even when the apparent sender is senior or demanding.
Report suspicious messages without spreading them
An employee who notices a possible phishing email should know exactly where to report it. Many mail platforms offer a built-in reporting action; Google documents reporting phishing from Gmail, and Microsoft provides user-reporting workflows in supported environments. The company's internal procedure should specify whether staff report through the mail application, a designated security contact or both. Avoid forwarding dangerous attachments to an entire team as a warning. Preserve relevant evidence under authorised access while minimising unnecessary exposure of customer data. Reporting is useful even when the user has not clicked anything, because administrators may need to check whether colleagues received similar messages.
If a suspicious link was opened
Opening a link does not always mean an account was compromised, but it deserves a careful assessment. The next questions are whether credentials were entered, a file was downloaded, a permission was granted or an MFA prompt was approved. Staff should stop interacting with the suspicious page and report the event promptly using a known channel. The authorised security owner can determine whether account containment, device scanning or session review is necessary. Do not conceal the event because nothing obvious happened immediately. Equally, avoid declaring a breach without evidence. A timely factual report helps distinguish a harmless visit from an incident requiring urgent action.
If credentials or an MFA code were shared
Sharing a password, recovery code or one-time authentication code with an unverified page or person increases the likelihood of account compromise. The employee should promptly contact the authorised administrator through an independent route and describe what was entered and when. Depending on the provider, incident response may require blocking access, changing credentials, revoking sessions and checking newly registered authentication methods. Microsoft documents these measures for compromised cloud mailboxes. Do not send replacement credentials through the potentially affected email account. The response should preserve evidence and be coordinated, because an attacker may have created forwarding rules or application permissions that survive a password change.
If an invoice or payment was affected
When a fraudulent instruction may have influenced a payment, the business needs a separate finance incident path in addition to technical email investigation. Preserve the original message, payment instruction, approval record and transaction details under controlled access. Contact the relevant bank or payment provider promptly through verified official channels according to the organisation's procedures. Do not promise that money can be recovered or claim a loss before records confirm it. Notify affected internal decision-makers and follow applicable reporting requirements based on verified circumstances. A mailbox password reset cannot reverse a completed transfer, and a finance control cannot by itself remove an attacker from a compromised account.
Keep mail filters and account security in perspective
Spam and phishing filters can block many suspicious messages, but no filter catches everything. A false negative may reach the inbox, while a legitimate message may be quarantined for review. Email authentication, account MFA, software updates and careful business verification each address different parts of the risk. Do not disable protective controls because one important message was blocked without investigating the reason. Likewise, do not assume an inbox message is trustworthy because it passed the filter. Staff should know how to report both suspicious mail and false positives through supported channels. The goal is a layered process with clear ownership and evidence.
Run realistic training without shaming staff
Training should reflect the business's actual workflows: supplier quotations, renewal notices, customer attachments, invoice approvals and mailbox sign-ins. Use clearly authorised examples and explain the independent verification route for each situation. Staff should be able to ask for help without being blamed for reporting uncertainty. Measure whether they know the escalation channel and can distinguish routine requests from changes requiring approval. Do not conduct covert phishing simulations, collect passwords or contact external parties without separate authorisation. The purpose is better judgement and timely reporting, not a competition to catch colleagues making mistakes. Refresh examples when the organisation changes systems or processes.
A concise response procedure for a small team
On receiving a suspicious email, do not follow its links, open unexpected attachments or act on a payment change. Verify the claimed sender through a contact route already trusted by the business. Report the message using the designated internal process and preserve relevant details without broadly sharing sensitive content. If anyone entered credentials, approved an MFA prompt or sent money, escalate immediately to the appropriate security or finance owner. Record what happened, when and which systems may be affected. Use provider-specific incident guidance for technical containment. No general checklist can prove that an incident is resolved; closure requires actual evidence and authorised review.
Sources & further reading
Ready to explore a related service?
See the related OnHypp service and decide whether it fits your business needs.
Email & hostingWebsite CareDomains