Microsoft 365 Email Security for Law Firms: What I Found After an Email Account Was Compromised

A small business owner usually does not find out there is a problem with email security by looking at a Microsoft dashboard. More often, a client, vendor, employee, or business partner receives a suspicious email and calls to ask, “Did this really come from you?”

That immediately raises another question: Does this mean someone hacked our email?

The answer is not always simple. Someone can spoof your domain without ever logging into your Microsoft 365 account. An attacker can register a similar looking domain and impersonate your business. Someone can also gain access to a real mailbox and send messages as the actual employee. To the person receiving the email, those situations can look very similar. What is happening behind the scenes, and what needs to be fixed, can be very different.

I dealt with exactly this problem for a small law firm. What initially appeared to be an email spoofing problem turned into a much deeper investigation. When I reviewed the firm's Microsoft environment and sign in activity, I found evidence that an attorney's email account had actually been compromised for several months.

As I continued investigating, I found another important piece of the firm's email environment. Microsoft 365 was not the only system sending email using the firm's domain. A separate mail server was also sending email as that domain.

At that point, I was no longer dealing with one suspicious email or one missing security setting. Before I could properly secure the firm's email, I needed to understand how its email environment actually worked.

“The suspicious email was what got my attention. Understanding how their email environment actually worked was how I found the bigger problem.”SNL Tech Services

Why Are People Getting Fake Emails That Look Like They Came From My Business?

This is not only a law firm problem. I have had other small business clients reach out to me with similar concerns. A customer, vendor, employee, or business partner receives a suspicious message that appears to come from the company's domain or from a particular employee. Sometimes the message asks for money. Sometimes it asks the recipient to open a file, follow a link, provide information, or respond to a conversation.

From the business owner's perspective, the immediate assumption is often that the employee's mailbox must have been hacked. That is one possibility, but it is not the only one.

There are multiple technologies and security layers designed to help receiving email systems determine whether a message is legitimate. Understanding what actually happened still requires investigation. I do not want to start changing Microsoft settings based only on what the suspicious email looked like. I want to determine whether I am dealing with domain spoofing, impersonation, an actual account compromise, or some combination of problems.

Does Email Spoofing Mean My Microsoft 365 Account Was Hacked?

No. Spoofing by itself does not prove that someone accessed your Microsoft 365 account.

With email spoofing, sender information can be forged so a message appears to come from a trusted source. An attacker can therefore create a message that appears to come from your company without necessarily knowing an employee's password or logging into that employee's mailbox.

Impersonation can work differently. An attacker might register a similar looking domain or use an address designed to resemble an attorney, owner, executive, accountant, or another trusted person. The message may not technically come from your domain at all, but the difference can be subtle enough that someone reading quickly believes it does.

Then there is an actual mailbox compromise. In that situation, an attacker has obtained unauthorized access to the real account.

Those distinctions matter because the investigation and remediation are not necessarily the same.

In the case of this law firm, I did not assume the problem was limited to spoofing. I reviewed Microsoft sign in activity as part of my investigation and found evidence that an attorney's actual account had been compromised for several months.

That changed the direction of the investigation.

How Can You Tell Whether a Microsoft 365 Account Was Actually Compromised?

This is where logs and visibility become extremely important.

A suspicious email tells me that something deserves investigation. It does not necessarily tell me what happened. When I am investigating a possible Microsoft 365 account compromise, I want to look at the available evidence rather than assume that what the recipient saw tells the entire story.

Depending on the incident, that can mean reviewing sign in activity, unexpected forwarding, suspicious Inbox rules, mailbox activity, authentication methods, connected applications, account changes, and other behavior that does not match what I would expect from the legitimate user.

For this particular client, reviewing the sign in activity gave me evidence that I was not looking at spoofing alone. The attorney's actual account had been compromised.

This is an important distinction for any small business owner. If somebody tells you your company's email is being spoofed, do not automatically assume spoofing is the entire problem. It may be. But I would still want to determine whether there is evidence that somebody accessed the real account.

The opposite is also true. A fake email that looks like it came from your company does not automatically prove somebody got into Microsoft 365.

You have to investigate what actually happened.

What I Found When I Looked Deeper Into the Firm's Email

Once I knew there had been an account compromise, I kept digging into the email environment.

That is when I discovered that Microsoft 365 was not the only system sending email using the firm's domain. A separate mail server was also sending messages as that domain.

That was important because I could not responsibly start locking down email authentication until I understood what systems were legitimately supposed to send email for the business. If I changed the domain configuration without understanding the mail flow, I could potentially stop legitimate business email along with the traffic I did not want.

This is something a business owner may never have had a reason to think about. You may use Outlook every day and think, “Our email is Microsoft 365.” That does not necessarily tell me everything sending email as your domain. Websites, applications, multifunction printers, marketing platforms, line of business applications, and other servers can sometimes send email using a company's domain.

Before I make the domain more restrictive, I want to know what is supposed to be there.

“I can't properly secure an email environment until I understand what is legitimately sending email from it.”SNL Tech Services

What Do SPF, DKIM and DMARC Actually Do?

Small business owners often encounter these three acronyms after something goes wrong with email. They are frequently discussed together, but they do different things.

SPF, or Sender Policy Framework, identifies sources authorized to send email for a domain. If multiple legitimate services send email using your domain, those sending sources need to be considered when SPF is configured.

DKIM, or DomainKeys Identified Mail, uses cryptographic signing so a receiving system can validate information about a message and the domain that signed it. For a custom Microsoft 365 domain, properly configuring DKIM provides another authentication mechanism for legitimate mail.

DMARC, or Domain based Message Authentication, Reporting and Conformance, builds on SPF and DKIM and introduces alignment with the domain visible to the recipient in the From address. In simplified terms, DMARC helps a receiving system determine whether the authentication behind a message appropriately aligns with the domain the message claims to represent. The domain owner can also publish a policy indicating how messages that fail DMARC should be handled.

These technologies are important, but I do not describe them to clients as a magic anti phishing switch. They are different pieces of a layered email security strategy.

How I Stopped the Other Mail Server From Successfully Sending as the Firm

Once I understood the firm's legitimate mail flow, I could start tightening the domain without blindly breaking services.

The firm's DNS did not have the DKIM and DMARC configuration I wanted in place. I configured DKIM for the legitimate Microsoft 365 mail environment and implemented DMARC. After validating what should legitimately be sending email for the firm, I ultimately moved the firm's DMARC policy to p=reject.

That requires an important explanation.

Setting DMARC to p=reject does not make it physically impossible for someone on the internet to create an email and put your company's domain in the visible From field. What it does is publish a policy for receiving mail systems. If a message claims to be from your domain but cannot pass DMARC through appropriately aligned SPF or DKIM authentication, the published policy tells receiving systems that the message should be rejected.

For this law firm, the separate mail server was no longer supposed to be an authorized sending source for the firm's domain. Once I identified the mail environment we actually wanted, configured the legitimate authentication, and published a p=reject DMARC policy, receiving systems honoring DMARC had explicit instructions from the domain owner to reject messages that failed DMARC.

That is more accurate than saying, “I turned on DMARC, so nobody can spoof the company anymore.”

Security does not work that way.

Why Didn't SPF, DKIM and DMARC Solve Everything?

Because an attacker does not have to use your exact domain to fool someone.

This is where the difference between spoofing and impersonation becomes important. An attacker can register a similar looking domain that they actually own. Because they control that domain, they can configure valid SPF, DKIM, and DMARC records for it. Their email can authenticate correctly for their domain while still being intentionally designed to make the recipient believe it came from your business.

That is one reason I took the firm's protections further.

I upgraded the firm's Microsoft licensing and configured Microsoft Defender for Office 365 anti phishing protections around domain impersonation and user impersonation. Domain impersonation protection provides another layer for identifying messages that imitate protected domains, while user impersonation protection can help identify messages that imitate specific people the organization wants to protect.

For a law firm, an attorney can be an obvious person to consider protecting. For another small business, it might be the owner, controller, bookkeeper, executive, office manager, or another employee whose identity could be particularly useful in a fraudulent conversation.

The technology changes with the environment. The process of understanding who and what needs protection does not.

I Also Reduced Authentication Methods the Firm Did Not Need

As part of hardening the Microsoft environment, I reviewed the ways users and applications could authenticate to email.

I disabled POP and IMAP where the firm did not need them and restricted authenticated SMTP access where it was not required.

I want to be precise about that because saying “I disabled SMTP” would be technically misleading. SMTP is fundamental to how email is transported. SMTP AUTH is a specific authenticated client submission method. Microsoft recommends disabling SMTP AUTH at the organization level and enabling it only for mailboxes that still require it.

The same general principle applies to other access methods. I do not want to leave something available merely because Microsoft provides a setting for it. I want to understand whether the business actually needs it.

That does not mean POP, IMAP, or SMTP AUTH caused this particular compromise. I did not establish that, so I am not going to claim it. They were part of the environment I reviewed and hardened after discovering that the firm's email security needed considerably more attention.

I Took the Security Work Beyond Email

The email incident also exposed a larger question: What happens if somebody has valid credentials and tries to access the firm's Microsoft environment from a computer I do not trust?

I implemented Conditional Access policies that required managed devices to meet the firm's compliance requirements before they could access the protected Microsoft 365 resources covered by those policies.

There was substantial backend work required to make that possible. The devices, identities, compliance requirements, and Microsoft environment had to be configured so those access policies could make meaningful decisions. I am intentionally not turning this email article into a complete Intune and Conditional Access deployment guide because that is a separate subject.

For a business owner, the important part is easier to understand. I did not want possession of a username, password, and even MFA to automatically mean someone could access protected firm information from any computer. Device compliance became another part of the access decision.

If you want to understand the broader work I look at behind Microsoft 365 security, I cover that in What I Check During a Microsoft 365 Tenant Security Review. I also explain why those settings need ongoing attention in Microsoft 365 for Small Businesses: Is Anyone Actually Managing Your Environment?.

Isn't Microsoft 365 Supposed to Protect My Email?

Microsoft 365 includes email security protections. But this is where I think small business owners need to distinguish between having Microsoft 365 and having Microsoft 365 properly configured and managed around their business.

Microsoft provides built in anti spoofing protection for cloud mailboxes and uses email authentication along with additional signals to evaluate suspicious senders. Depending on licensing, Defender for Office 365 provides additional anti phishing capabilities, including user and domain impersonation protection.

That does not mean every Microsoft 365 tenant automatically has every available protection configured exactly the way a particular business needs it.

Licensing matters. Configuration matters. DNS matters. Identity matters. Mail flow matters. The applications and servers sending email matter. The people being impersonated matter. Devices matter. After all of that is configured, somebody still needs to manage the environment as the business changes.

That is one reason I perform a Microsoft 365 Audit, which I also refer to as a Microsoft 365 Tenant Security Review. I am not just checking whether Outlook opens and MFA exists. I want to understand how the environment is actually configured and whether that configuration makes sense for the way the business operates.

Is This Mainly a Law Firm Problem?

No. The client story in this article happens to involve a law firm, and law firms have particular reasons to take email security seriously. They communicate with clients and other attorneys, exchange confidential information, and may be involved in transactions where a convincing fraudulent email can have serious consequences.

But I have dealt with similar email security problems in other small businesses. In one case, a small general construction company had an email security issue that became a concern for its prime contractor. The business was not getting paid until it could demonstrate that its email security had been reviewed and strengthened.

For that client, I performed a broader Microsoft 365 security review, documented the gaps I found, implemented the appropriate technical changes, and documented the updated environment so the company had something concrete to provide to its prime contractor. That documentation was important not only for resolving the immediate payment issue, but also for the company's ability to continue bidding on other contracts.

The business consequences were different, but my technical process started in much the same place. I needed to understand the Microsoft environment, determine what was actually configured, document the gaps, implement the appropriate changes, and document what had been completed. The specific controls will vary based on the business, its technology, contractual requirements, licensing, and risk, but I do not assume an email security problem is isolated to one setting simply because that is where the problem first appeared.

That is why I think this law firm's experience is relevant beyond the legal industry. A compromised or poorly configured email environment can become a security problem, a customer trust problem, a contractual problem, or, as I have seen firsthand, a problem that affects whether a small business gets paid.

What's the Difference Between Spoofing, Impersonation and Business Email Compromise?

These terms get mixed together frequently, but I would not use them interchangeably.

Spoofing generally involves forging sender information so a message appears to come from a trusted source.

Impersonation involves mimicking a trusted person, domain, or brand. That can include using a lookalike domain the attacker actually controls.

Mailbox compromise means someone has gained unauthorized access to the real account.

Business Email Compromise, or BEC, is a broader form of fraud in which attackers use email and trusted business relationships to manipulate people into sending money, changing payment information, revealing information, or taking other actions. BEC can involve a compromised mailbox, impersonation, spoofing, or other techniques.

Because that subject deserves more than a few paragraphs, I cover it separately in Cybersecurity for Small Law Firms: Microsoft 365 and Business Email Compromise. That article also goes further into something technology alone cannot solve: how a business verifies financial instructions before money actually moves.

What Should I Do If Someone Is Sending Fake Emails From My Business?

If a client, vendor, or employee tells you they received a suspicious email that appears to come from your company, I would not dismiss it simply because the message is not visible in the employee's Sent Items.

The specific response depends on what happened, but these are some of the questions I would want answered:

• Can we preserve a copy of the suspicious message, including its headers?

• Did the message actually use your domain, or is it coming from a lookalike domain?

• Is there evidence that the employee's real account was accessed?

• Are there suspicious sign ins, forwarding configurations, Inbox rules, or account changes?

• What systems are legitimately authorized to send email using your domain?

• Are SPF, DKIM, and DMARC configured correctly for the environment you actually use?

• Are authentication methods enabled that the business does not need?

• What anti spoofing and anti phishing protections are currently configured?

• Are important users and domains appropriately protected against impersonation?

• If the incident involved money, payment instructions, or sensitive information, what additional incident response steps need to happen immediately?

The answer may be that the message was spoofed and the real account was never compromised. Or, as happened with this law firm, investigating what initially appeared to be one email problem may uncover something considerably larger.

How Do I Know If Microsoft 365 Email Security for Law Firms Is Configured Correctly?

I would start by asking questions rather than buying another product.

Who manages your Microsoft 365 tenant? What systems send email as your domain? Are SPF, DKIM, and DMARC configured? What DMARC policy are you using? Does anyone review sign in activity and security alerts? Which employees have administrative access? What authentication methods are enabled? What Defender protections are included in your licensing and actually configured? Can employees access company information from unmanaged devices? What happens when an employee leaves? Who reviews these settings after Microsoft or your business changes?

If the answer to most of those questions is “I don't know,” that does not automatically mean your environment is compromised.

It does mean there is more to understand.

This is where my Microsoft 365 Tenant Security Review can provide a much more useful starting point than randomly changing security settings. The goal is to establish what is actually configured, understand how the business uses Microsoft 365, identify technical gaps, and determine which changes are appropriate for that environment.

The same principle applies when somebody outside the business starts asking for evidence. A customer, prime contractor, cyber insurer, or another organization may want more than a verbal assurance that security is being handled. They may need documentation showing what is actually in place.

If cyber insurance is the reason you are being asked these questions, I cover that separately in Cyber Insurance Requirements for Small Businesses: Can You Answer the IT Questions on Your Application?.

The Biggest Lesson From This Email Incident

The most important lesson from this project was not that every small business needs the exact same collection of Microsoft settings I implemented for this law firm.

It was that the first visible symptom was not the whole problem.

A suspicious email led me to investigate. The investigation showed that an attorney's account had been compromised for several months. Digging deeper exposed another mail server sending as the firm's domain and email authentication that needed to be corrected. From there, I strengthened the environment through properly configured domain authentication, a DMARC p=reject policy, Defender impersonation protections, reduced unnecessary authentication methods, and additional access controls.

I also did broader work behind the scenes to get the Microsoft environment and devices into a state where stronger Conditional Access policies could be enforced. That work matters, but it belongs within the larger Microsoft 365 management story rather than being treated as another email setting.

That is how I approach similar problems for other small businesses too. I do not want to assume that the first thing we see is the only thing wrong. I want to understand how the environment actually works, determine what happened based on the evidence available, document what I find, and then build the security around the business that is actually there.

If your clients, vendors, or employees are receiving suspicious messages that appear to come from your company, or you simply do not know how your Microsoft 365 email security is currently configured, SNL Tech Services Business IT Solutions can help you understand the environment before deciding what needs to change.

Frequently Asked Questions

Can Someone Spoof My Business Email Without Knowing My Password?

Yes. Spoofing can involve forging sender information without gaining access to the real Microsoft 365 account. That is why a suspicious message appearing to come from your domain does not by itself prove the mailbox was compromised.

Does Email Spoofing Mean My Microsoft 365 Account Was Hacked?

Not necessarily. Spoofing and account compromise are different problems. In the law firm incident described in this article, however, my investigation of the sign in activity showed evidence that an attorney's real account had also been compromised.

Do SPF, DKIM and DMARC Stop All Fake Emails?

No. They are important email authentication technologies, but they do not eliminate every form of impersonation or phishing. An attacker can register a lookalike domain and properly authenticate email from that domain while still trying to deceive the recipient.

What Does DMARC p=reject Mean?

A DMARC policy of p=reject tells receiving email systems that messages claiming to be from the domain that fail DMARC should be rejected. It does not physically prevent someone from putting your domain in a forged From address. It provides receiving systems with the domain owner's published policy for handling messages that fail the required authentication and alignment.

Can Someone Impersonate My Company Even If I Have DMARC?

Yes. An attacker can register a similar looking domain that they control and configure valid email authentication for it. The message can authenticate correctly for the attacker's domain while still being designed to fool the recipient into thinking it came from your business. That is one reason impersonation protection and email authentication address different problems.

Does Microsoft 365 Already Include Anti Spoofing Protection?

Yes. Microsoft provides built in anti spoofing protection for cloud mailboxes. Defender for Office 365 can provide additional user and domain impersonation capabilities depending on licensing and configuration. Having Microsoft 365, however, does not tell you whether all of the controls appropriate for your particular environment have been configured.

Should I Disable POP, IMAP and SMTP AUTH?

That depends on what your business and applications actually require. For this client, I disabled unnecessary POP and IMAP access and restricted authenticated SMTP where it was not needed. The goal is not to disable technology simply because it exists. It is to understand which access methods the business legitimately requires and reduce unnecessary exposure.

Can I Require Employees to Use Approved Company Computers to Access Microsoft 365?

Yes, Microsoft Entra Conditional Access can use device compliance as an access requirement. When the underlying device management, compliance, and Conditional Access configuration is properly established, access to targeted Microsoft resources can require the device to be marked compliant.

Can Email Security Problems Affect Contracts or Getting Paid?

They can. The exact requirements depend on the customer, contract, and industry. I worked with a small general construction company whose prime contractor required evidence that identified Microsoft 365 email security concerns had been reviewed and addressed before payment would be released. I performed the security review, documented the gaps, implemented the technical changes, and documented the updated environment so the client could provide that information to its prime contractor and continue pursuing contract opportunities.

ADDITIONAL RESOURCES

Microsoft Learn: Anti Phishing Policies in Microsoft 365

Microsoft's current explanation of spoofing, user impersonation, domain impersonation, mailbox intelligence, and Defender for Office 365 anti phishing capabilities.Microsoft Anti Phishing Policies

Microsoft Learn: Email Authentication in Microsoft 365

Microsoft guidance explaining SPF, DKIM, DMARC, composite authentication, and how Microsoft evaluates email authentication.Microsoft 365 Email Authentication Guide

Microsoft Learn: Set Up DMARC

Microsoft documentation explaining DMARC alignment and the none, quarantine, and reject policies.Set Up DMARC in Microsoft 365

Microsoft Learn: Configure DKIM

Microsoft documentation explaining DKIM signing and configuration for custom Microsoft 365 domains.Configure DKIM for Microsoft 365

Microsoft Learn: Respond to a Compromised Email Account

Microsoft guidance for investigating and responding to a compromised Microsoft 365 mailbox.Respond to a Compromised Microsoft 365 Email Account

Microsoft Learn: Anti Spoofing Protection

Microsoft documentation explaining built in anti spoofing protections and spoof intelligence in Microsoft 365.Anti Spoofing Protection in Microsoft 365

Microsoft Learn: Configure Anti Phishing Policies in Defender for Office 365

Microsoft documentation covering user impersonation, domain impersonation, mailbox intelligence, and policy configuration.Configure Defender Anti Phishing Policies

Microsoft Learn: Require Device Compliance with Conditional Access

Microsoft documentation explaining how Intune device compliance and Entra Conditional Access can work together to require compliant devices for targeted resources.Require Device Compliance with Conditional Access

Microsoft Learn: Enable or Disable SMTP AUTH in Exchange Online

Microsoft guidance explaining authenticated SMTP submission and Microsoft's recommendation to disable SMTP AUTH unless it is still required.SMTP AUTH in Exchange Online