A finance director receives an apparent message from the chief executive asking for an urgent payment. The sender name is familiar, the wording is plausible and the request lands in the middle of a busy working day. Yet the message did not come from the chief executive at all. Understanding how to stop email spoofing starts with recognising that this is not only a mail-filtering problem. It is an identity, configuration and response problem.
For UK organisations using Microsoft 365, the objective is to make it difficult for attackers to impersonate your domains, detect messages that bypass preventative controls, and give people a dependable route to report what looks wrong. Technical authentication is essential, but it does not remove the need for phishing triage, remediation and informed employee reporting.
What email spoofing is, and what it is not
Email spoofing occurs when an attacker falsifies the sender identity presented to a recipient. Most commonly, this means sending a message that appears to come from your organisation's domain, such as `finance@yourorganisation.co.uk`, without authorisation. The attacker may be pursuing invoice fraud, credential theft, malware delivery or a conversation that can later be used for business email compromise.
The term is often used more broadly to describe display-name impersonation, lookalike domains and messages sent from compromised legitimate accounts. These threats overlap, but they require different controls. SPF, DKIM and DMARC can help receiving systems identify unauthorised use of your genuine domain. They cannot, by themselves, stop an attacker registering `your-organisati0n.co.uk`, using a convincing display name, or sending mail from a supplier whose account has been compromised.
That distinction matters when assessing risk. A successful DMARC deployment reduces one material route for impersonation, but it should be treated as part of a phishing defence lifecycle rather than a complete answer to social engineering.
How to stop email spoofing at the domain level
The technical foundation is email authentication. Your organisation needs accurate Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM) and Domain-based Message Authentication, Reporting and Conformance (DMARC) records for every domain that sends email.
Start with a complete sending inventory
Before changing a DMARC policy, establish every service permitted to send as your domain. This commonly includes Microsoft 365, marketing platforms, HR and recruitment systems, service desks, finance applications, customer communications tools and third-party suppliers. Forgotten systems are the usual reason legitimate mail fails authentication after controls are tightened.
SPF specifies which servers may send for a domain. Keep the record precise and avoid an excessive number of DNS look-ups, as SPF evaluation has a defined limit. Do not use an overly permissive record simply to avoid delivery issues. A policy that effectively authorises the internet to send on your behalf provides little protection.
DKIM cryptographically signs outbound messages so the receiving service can verify that the message has not been altered and is associated with an authorised sending domain. Enable DKIM for Microsoft 365 and for relevant third-party sending platforms. Where possible, use aligned domains rather than allowing services to sign only with their own domains.
Use DMARC to enforce alignment
DMARC tells receiving mail systems what to do when SPF and DKIM checks fail, while requiring alignment with the domain visible in the From address. That alignment is what makes DMARC particularly effective against direct domain spoofing.
A sensible implementation normally begins with a monitoring policy (`p=none`). DMARC aggregate reports then reveal which systems are sending mail, whether they authenticate correctly and where failures occur. This evidence should be reviewed carefully, especially for business-critical communications and services managed outside the security team.
Once legitimate senders are authenticated, move towards quarantine and then reject. Quarantine asks recipients to treat failing messages with suspicion, while reject asks them to refuse them. The right pace depends on the complexity of your sending estate, the quality of report analysis and the business impact of a false positive. For a tightly controlled domain, progress may be quick. For an organisation with many legacy applications and decentralised communications, it may require a phased programme.
DMARC reporting is not a set-and-forget exercise. New SaaS services, acquisitions, supplier changes and marketing activity can introduce new mail streams. Governance should ensure that a sending-domain review is part of procurement and change control.
Strengthen Microsoft 365 protection around authentication
DMARC protects your domain reputation beyond your own tenant, but Microsoft 365 configuration determines how effectively you handle the malicious mail that still reaches your users. Review anti-phishing and anti-spoofing policies, impersonation protection, mailbox intelligence and outbound controls in line with your licensing and risk profile.
Pay particular attention to protection for high-risk identities. Executives, finance teams, payroll, procurement, IT administrators and staff who manage supplier changes are frequent targets. Impersonation policies should cover priority users and appropriate domains, including key suppliers where the volume and fraud risk justify it.
Microsoft 365 should also be configured to treat external messages clearly. External sender labelling can provide useful context, although it is not a substitute for judgement. Overly prominent warnings may become background noise; meaningful controls are those that support a consistent decision process when a message requests payment, credentials, sensitive data or an urgent change to routine practice.
Mailbox forwarding controls deserve equal attention. A compromised mailbox can be used to monitor conversations, intercept invoices and send convincing replies from a legitimate address. Restrict automatic external forwarding unless there is a defined business requirement, alert on unusual forwarding rules and investigate sign-in activity associated with suspected account compromise.
Prepare users to identify the attacks authentication cannot stop
Attackers adapt quickly. If they cannot spoof your exact domain, they may register a lookalike, compromise a trusted supplier or exploit a genuine internal account. This is where human risk management becomes operationally significant.
Training should use realistic examples relevant to the organisation's roles and processes, not generic warnings alone. Finance users need practice identifying changed bank details and payment-authorisation pressure. HR teams may see malicious CVs or payroll requests. Senior leaders and their support staff are more likely to face targeted impersonation. Simulated phishing can identify patterns of risk, but its value comes from targeted coaching and measurable improvement, not from attempting to catch people out.
Make reporting simple inside Outlook. A reporting button gives employees a clear action when they are uncertain and sends potential threats into a workflow that the security team can assess. It also creates valuable visibility: the messages users report show which lures are reaching the organisation, which controls are failing and which departments may need more support.
Build a phishing triage and remediation workflow
A reported spoofed message should not disappear into a shared mailbox without ownership. Define who triages reports, what evidence they collect, how urgent cases are escalated and how users receive feedback. If staff report suspicious messages but never learn whether they were malicious, reporting rates and confidence will decline.
Triage should establish the real sender path, authentication results, URLs and attachments, recipient scope, related messages and any user interaction. Analysts also need to consider whether the message is part of a wider campaign, whether an account has been compromised and whether a supplier should be contacted through a verified channel.
When a message is confirmed as malicious, remediation must be rapid. Search for matching messages across mailboxes, remove or quarantine them where supported, block known indicators where appropriate and identify recipients who clicked or replied. For credential-harvesting incidents, reset credentials where necessary, revoke active sessions, review multi-factor authentication status and inspect mailbox rules. For invoice fraud, involve finance and legal stakeholders early, because the response may extend beyond technical containment.
A managed phishing response capability can be particularly valuable where internal teams lack capacity for sustained analysis. The important measure is not merely how many messages are classified, but how quickly a threat is understood, contained and used to improve controls.
Measure whether your controls are reducing exposure
Email spoofing protection should be evidenced through operational measures. Track DMARC coverage and enforcement across domains, authentication pass rates for authorised senders, spoof and impersonation detections, reported-message volumes, triage times, remediation times and repeat user-risk themes. Metrics should distinguish between direct-domain spoofing, lookalike domains, compromised accounts and supplier impersonation so that investment decisions are based on the actual attack mix.
Wise Fish supports this lifecycle through specialist phishing protection, Microsoft 365 expertise, Cofense-enabled reporting and response workflows, and the practical analysis needed to turn reported messages into stronger defences.
The most useful test is simple: when a convincing message reaches a busy employee, can they report it in seconds, can your team determine its scope quickly, and can you remove it before it becomes a fraud, credential or data-loss incident? Build your controls around that moment, then keep refining them as attackers change their methods.