Explore anti-spoofing protection provided by Exchange Online Protection
Microsoft designed EOP for both Microsoft 365 organizations with mailboxes in Exchange Online and standalone Exchange Online Protection (EOP) organizations without Exchange Online mailboxes. EOP includes features to help protect both types of organizations from spoofed (forged) senders.
Attackers typically combine two attack vectors - spoofing and phishing. Spoofing is the fraudulent practice of sending emails purporting to be from reputable companies. Attackers usually send spoofed emails with the intent of gaining a user's personal information, such as passwords and credit card numbers. Attackers engage in the practice of "phishing," which is the technical equivalent of "fishing" for personal information by masquerading as someone they're not. If we continue with the fishing analogy, spoofing is the bait attackers use to get the user to believe the email is credible. The more legitimate looking the bait, the greater the chance of getting the user to bite and reveal personal information.
Spoofing is a common technique that attackers use. Spoofed messages appear to originate from someone or somewhere other than the actual source. Attackers often use this technique in phishing campaigns that are designed to obtain user credentials. The anti-spoofing technology in Exchange Online Protection (EOP) specifically examines forgery of the From header in the message body. Email systems use the From header to display the message sender in email clients. When EOP has high confidence the message has a forged From header, it identifies the message as spoofed.
The following anti-spoofing technologies are available in EOP:
Email authentication. An integral part of any anti-spoofing effort is the use of email authentication (also known as email validation) by SPF, DKIM, and DMARC records in DNS. You can configure these records for your domains so destination email systems can check the validity of messages that claim to be from senders in your domains. For inbound messages, Microsoft 365 requires email authentication for sender domains. For more information, see Email authentication in Microsoft 365.
Some mail systems still can't authenticate messages even when they combine standard email authentication methods and sender reputation techniques. However, EOP can analyze and block those messages.
Spoof intelligence insight. Review spoofed messages from senders in internal and external domains during the last seven days. You can allow or block those senders.
Allow or block spoofed senders in the Tenant Allow/Block List. Organizations can override the verdict in the spoof intelligence insight. When they do so, the spoofed sender becomes a manual allow or block entry that only appears on the Spoof tab in the Tenant Allow/Block List. Organizations can also manually create allow or block entries for spoof senders before spoof intelligence detects them.
Anti-phishing policies. In EOP and Microsoft Defender for Office 365, anti-phishing policies contain the following anti-spoofing settings:
- Turn spoof intelligence on or off.
- Turn unauthenticated sender identification in Outlook on or off.
- Specify the action for blocked spoofed senders.
Anti-phishing policies in Microsoft Defender for Office 365 contain other protections, including impersonation protection. For more information, see Exclusive settings in anti-phishing policies in Microsoft Defender for Office 365.
Spoof detections report. For more information, see Spoof Detections report. Microsoft Defender for Office 365 organizations can also use Real-time detections (Plan 1) or Threat Explorer (Plan 2) to view information about phishing attempts. For more information, see Microsoft 365 threat investigation and response.
How spoofing works in phishing attacks
Spoofing messages have the following negative implications for users:
Spoofed messages deceive users. A spoofed message is designed to:
- Trick the recipient into selecting a link and giving up their credentials.
- Downloading malware.
- Replying to a message with sensitive content.
The following message is an example of phishing that uses the spoofed sender msoutlook94@service.outlook.com.
This message didn't come from service.outlook.com. However, the attacker spoofed the From header field to make it look like it did. This spoofed message was an attempt to trick the recipient into selecting the change your password link and giving up their credentials.
The following message is an example of an email with sensitive content that uses the spoofed email domain contoso.com:
The message looks legitimate, but the attacker spoofed the sender.
Users confuse real messages for fake ones. Even users who know about phishing might have difficulty seeing the differences between real messages and spoofed messages.
The following message is an example of a real password reset message from the Microsoft Security account:
The message really did come from Microsoft. However, given the increase in attacks over the past several years, many users are highly suspicious. It can be difficult to identify the difference between a real password reset message and a fake one. As such, users might ignore the message, report it as spam, or unnecessarily report the message to Microsoft as phishing.
Different types of spoofing
Microsoft differentiates between two different types of spoofed messages:
Intra-org spoofing. Also known as self-to-self spoofing. For example:
The sender and recipient are in the same domain:
From: chris@contoso.com
To: michelle@contoso.com
The sender and the recipient are in subdomains of the same domain:
From: laura@marketing.fabrikam.com
To: julia@engineering.fabrikam.com
The sender and recipient are in different domains that belong to the same organization. In other words, the attacker configured both domains as accepted domains in the same organization. For example:
From: sender @ microsoft.com
To: recipient @ bing.com
The attacker uses spaces in the email addresses to prevent spambot harvesting.
Messages that fail composite authentication due to intra-org spoofing contain the following header values:
Where:
- reason=6xx indicates intra-org spoofing.
- SFTY is the safety level of the message. 9 indicates phishing, and .11 indicates intra-organizational spoofing.
Cross-domain spoofing. The sender and recipient domains are different, and have no relationship to each other (also known as external domains). For example:
From: chris@contoso.com
To: michelle@tailspintoys.com
Messages that fail composite authentication due to cross-domain spoofing contain the following headers values:
Where:
- reason=000 indicates the message failed explicit email authentication. reason=001 indicates the message failed implicit email authentication.
- SFTY is the safety level of the message. 9 indicates phishing, .22 indicates cross-domain spoofing.
Note
If you've received a message like compauth=fail reason=###, and you need to know about composite authentication and the values related to spoofing, see Anti-spam message headers in Microsoft 365.
Problems with anti-spoofing protection
Anti-spoofing protection practices often have problems with mailing lists (also known as discussion lists). This issue is due to the way in which they forward and modify messages.
For example, Holly Dickson is interested in bird watching. Holly joins the mailing list birdwatchers@fabrikam.com, and sends the following message to the list:
The mailing list server receives the message, modifies its content, and replays it to the members of the mailing list. The replayed message has the same From address (hollyd@contoso.com), but the mailing list server applied the following changes:
- It added a tag (BIRD WATCHERS) to the subject line.
- It added a footer ("This message was sent to the Bird Watchers Discussion List. You can unsubscribe at any time.") to the bottom of the message. This type of modification is common in mailing lists, and might result in false positives for spoofing.
Pass anti-spoofing checks for mailing list messages
To help mailing list messages pass anti-spoofing checks, complete the following steps based on who controls the mailing list:
- Your organization owns the mailing list:
- Check the FAQ at DMARC.org: I operate a mailing list and I want to interoperate with DMARC, what should I do?
- Read the instructions at this blog post: A tip for mailing list operators to interoperate with DMARC to avoid failures.
- Consider installing updates on your mailing list server to support Authenticated Received Chain (ARC). See ARC Specification for Email.
- Your organization doesn't own the mailing list:
- Ask the maintainer of the mailing list to configure email authentication for the domain that the mailing list is relaying from.
- When enough senders reply back to domain owners about setting up email authentication records, it spurs them into taking action. While Microsoft also works with domain owners to publish the required records, it helps even more when individual users request it.
- Create inbox rules in your email client to move messages to the Inbox. You can also ask your admins to configure overrides as described in Spoof intelligence insight in EOP and Manage the Tenant Allow/Block List.
- Use the Tenant Allow/Block List to create an override for the mailing list to treat it as legitimate. For more information, see Add allows in the Tenant Allow/Block List.
Tip
If all else fails, you can report the message as a false positive to Microsoft.