Introduction
Business Email Compromise (BEC) continues to be one of the most financially damaging cyber threats facing organizations.
Unlike traditional malware attacks, BEC often relies on social engineering, impersonation, domain spoofing, and stolen credentials rather than malicious software. This makes these attacks particularly difficult to prevent with a single email security product.
In my previous post, I shared a real-world email compromise incident and explained how a relatively small DMARC configuration issue became an important security lesson for our organization.
Lessons From a Real Email Compromise Attack: DMARC, Mimecast, and Security Awareness
Resolving the immediate issue was only the first step.
The bigger lesson was that email security should not depend on one technology or one security product. We needed multiple layers of protection working together.
Here is how I think about a multi-layered email defense strategy for protecting a Microsoft 365 environment against BEC and related phishing attacks.
Layer 1: Domain Authentication — SPF, DKIM, and DMARC
The first layer is protecting your domain from being abused by attackers who try to send email pretending to be your organization.
SPF — Sender Policy Framework
SPF defines which mail servers or services are authorized to send email on behalf of your domain.
For example, if your organization uses Microsoft 365 and several approved third-party email services, those services should be properly represented in your SPF configuration.
However, SPF alone is not enough.
DKIM — DomainKeys Identified Mail
DKIM adds a digital signature to outgoing email.
The receiving mail system can use that signature to verify that the message was signed by an authorized sending service and that the signed content has not been modified in a way that invalidates the signature.
DMARC — Domain-based Message Authentication, Reporting & Conformance
DMARC builds on SPF and DKIM by checking whether the authentication results are properly aligned with the domain used in the visible From address.
It also allows an organization to tell receiving mail systems what to do when messages fail DMARC evaluation.
Common policies include:
p=none— monitor and collect reportsp=quarantine— treat failing messages as suspiciousp=reject— reject messages that fail the DMARC policy
One important lesson I learned is that DMARC enforcement should be approached carefully.
Before moving to p=reject, organizations should monitor legitimate sending services and make sure SPF, DKIM, and DMARC alignment are working correctly.
A small DNS or configuration mistake can potentially affect legitimate business email, so testing and monitoring are essential.
Layer 2: Secure Email Gateway — Mimecast
Even with properly configured SPF, DKIM, and DMARC, organizations still need protection against malicious messages that appear to come from legitimate sources.
This is where a secure email gateway such as Mimecast can provide another layer of defense.
In our environment, Mimecast provides additional controls around incoming and outgoing email.
URL Protection
Email security systems can inspect links contained in messages and apply additional protection when users click them.
This can help detect or block malicious websites, phishing pages, and other suspicious destinations.
Attachment Protection
Email security platforms can inspect attachments and use sandboxing or other analysis techniques to identify potentially malicious files before they reach users.
This provides an additional layer beyond the standard Microsoft 365 mailbox protections.
Impersonation Protection
BEC attackers do not always spoof an entire domain.
Sometimes they simply impersonate an executive, manager, supplier, or other trusted person.
For example:
“Hi Paul, I need you to urgently purchase some gift cards for a client.”
The sender may use a completely different external domain while using a familiar name or display name.
Impersonation protection can help identify these suspicious messages before they reach the user’s inbox.
Layer 3: Identity Protection — Microsoft Entra ID
Email security is only one part of the problem.
If an attacker obtains a user’s Microsoft 365 credentials, they may attempt to access email, SharePoint, OneDrive, Teams, or other cloud services directly.
This is where Microsoft Entra ID becomes an important part of the security architecture.
Multi-Factor Authentication
MFA adds another authentication factor beyond a password.
Even if an attacker obtains a user’s password, they still need to satisfy the additional authentication requirement.
For stronger protection against phishing, organizations should consider phishing-resistant authentication methods, such as FIDO2 security keys or passkeys, where appropriate.
Standard Microsoft Authenticator-based MFA is still an important security control, but it should not be described as inherently phishing-resistant.
Conditional Access
Conditional Access allows organizations to make access decisions based on conditions such as:
- User or group
- Application
- Location
- Device compliance
- Authentication method
- Sign-in risk
For example, an organization might require compliant devices for access to sensitive company resources or require stronger authentication when a sign-in is considered risky.
When combined with Microsoft Intune, Conditional Access can become an important part of a broader identity and device security strategy.
Blocking Legacy Authentication
Older authentication methods can create additional security risks because they may not support modern authentication and MFA requirements in the same way as modern authentication.
For this reason, organizations should review their environment and disable legacy authentication methods that are no longer required, while ensuring that legitimate applications and services continue to work correctly.
Layer 4: Human Defense & Incident Feedback
Technology can block a large number of threats, but it cannot eliminate the human element.
BEC attacks are specifically designed to manipulate people.
An attacker may create a sense of urgency:
“I need this payment processed immediately.”
Or:
“I’m currently in a meeting. Please send the information to this account.”
These situations are difficult for technology alone to identify.
Phishing Simulations
Regular phishing simulations can help employees recognize common attack techniques.
For example, organizations can simulate:
- Fake Microsoft 365 login pages
- Password reset requests
- Fake invoice notifications
- Executive impersonation
- Urgent payment requests
The goal should not simply be to catch employees making mistakes.
The goal is to teach employees what suspicious behavior looks like.
Make Reporting Easy
Employees should also have an easy way to report suspicious emails.
This could be:
- A phishing-report button
- An internal security mailbox
- A service desk ticket
- Direct communication with the IT/security team
The easier it is to report a suspicious message, the faster the IT team can investigate and warn other employees.
Internal Security Alerts
When a genuine phishing or BEC campaign is identified, quickly informing employees can prevent multiple people from falling for the same attack.
A short internal message explaining what to look for can sometimes be just as valuable as another technical security control.
Why a Multi-Layered Approach Matters
The important lesson is that no single security product can stop every BEC attack.
Consider a simplified attack scenario:
- An attacker sends a convincing phishing email.
- Email security fails to identify it.
- The employee clicks the link.
- The employee enters their credentials.
- The attacker attempts to sign in.
- MFA or Conditional Access blocks the suspicious login.
- The employee reports the phishing email.
- IT investigates and warns the rest of the organization.
In this example, the first security layer did not stop the attack.
But the other layers still had opportunities to prevent the attacker from gaining access.
That is the real value of defense in depth.
My Approach to BEC Protection
From my experience managing Microsoft 365 environments, I don’t think BEC protection should be treated as simply an email-filtering problem.
It is an identity, email, device, and human-behaviour problem.
A practical security architecture can include:
Domain Security
- SPF
- DKIM
- DMARC
- DMARC monitoring and reporting
Email Security
- Microsoft 365 email protection
- Secure email gateway
- URL protection
- Attachment protection
- Impersonation protection
Identity Security
- MFA
- Conditional Access
- Risk-based access controls
- Phishing-resistant authentication where appropriate
- Legacy authentication restrictions
Device Security
- Microsoft Intune
- Device compliance
- Endpoint security policies
- Security updates
Human Security
- Security awareness training
- Phishing simulations
- Simple reporting processes
- Rapid internal security alerts
When these controls work together, an attacker has to overcome multiple barriers rather than a single security product.
Conclusion
BEC attacks are not going away, and attackers continue to become more convincing.
The best defense is not one expensive security product. It is a multi-layered security strategy where email authentication, email filtering, identity protection, device management, and employee awareness all work together.
For organizations using Microsoft 365, a combination of SPF, DKIM, DMARC, secure email protection, Microsoft Entra ID, Conditional Access, MFA, Intune, and security awareness can significantly strengthen the overall security posture.
Most importantly, security should be treated as an ongoing process rather than a one-time configuration.
The controls need to be monitored, tested, reviewed, and improved as the organization’s technology and threat landscape change.
Leave a Reply