In Microsoft 365 organizations with mailboxes in Exchange Online or standalone Exchange Online Protection (EOP) organizations without Exchange Online mailboxes, inbound email messages are automatically protected against spoofing. EOP uses spoof intelligence as part of your organization’s overall defense against phishing.

When a sender spoofs an email address, they appear to be a user in one of your organization’s domains, or a user in an external domain that sends email to your organization. Attackers who spoof senders to send spam or phishing email need to be blocked. But there are scenarios where legitimate senders are spoofing. For example:

• Legitimate scenarios for spoofing internal domains:
  • Third-party senders use your domain to send bulk mail to your own employees for company polls.
  • An external company generates and sends advertising or product updates on your behalf.
  • An assistant regularly needs to send email for another person within your organization.
  • An internal application sends email notifications.
• Legitimate scenarios for spoofing external domains:
  • The sender is on a mailing list (also known as a discussion list), and the mailing list relays email from the original sender to all the participants on the mailing list.
  • An external company sends email on behalf of another company (for example, an automated report or a software-as-a-service company).

You can use the spoof intelligence insight in the Microsoft 365 Defender portal to quickly identify spoofed senders who are legitimately sending you unauthenticated email (messages from domains that don’t pass SPF, DKIM, or DMARC checks), and manually allow those senders.

By allowing known senders to send spoofed messages from known locations, you can reduce false positives (good email marked as bad). By monitoring the allowed spoofed senders, you provide an additional layer of security to prevent unsafe messages from arriving in your organization.

Likewise, you can review spoofed senders that were allowed by spoof intelligence and manually block those senders from the spoof intelligence insight.

The rest of this article explains how to use the spoof intelligence insight in the Microsoft 365 Defender portal and in PowerShell (Exchange Online PowerShell for Microsoft 365 organizations with mailboxes in Exchange Online; standalone EOP PowerShell for organizations without Exchange Online mailboxes).

• You open the Microsoft 365 Defender portal at https://security.microsoft.com. To go directly to the Spoofed senders tab on the Tenant Allow/Block List page, use https://security.microsoft.com/tenantAllowBlockList?viewid=SpoofItem. To go directly to the Spoof intelligence insight page, use https://security.microsoft.com/spoofintelligence.
• You need to be assigned permissions before you can do the procedures in this article. You have the following options:
  • Microsoft 365 Defender role based access control (RBAC): configuration/security (manage) or configuration/security (read). Currently, this option requires membership in the Microsoft 365 Defender Preview program.
  • Exchange Online RBAC:
    • Allow or block spoofed senders or turn on or turn off spoof intelligence: Membership in one of the following role groups:
      • Organization Management
      • Security Administrator and View-Only Configuration or View-Only Organization Management.
    • Read-only access to the spoof intelligence insight: Membership in the Global Reader, Security Reader, or View-Only Organization Management role groups.
  • Azure AD RBAC: Membership in the Global Administrator, Security Administrator, Global Reader, or Security Reader roles gives users the required permissions and permissions for other features in Microsoft 365.
• You enable and disable spoof intelligence in anti-phishing policies in EOP and Microsoft Defender for Office 365. Spoof intelligence is enabled by default.

1. In the Microsoft 365 Defender portal at https://security.microsoft.com, go to Email & Collaboration > Policies & Rules > Threat policies > Tenant Allow/Block Lists in the Rules section. To go directly to the Spoofed senders tab on the Tenant Allow/Block List page, use https://security.microsoft.com/tenantAllowBlockList?viewid=SpoofItem.
2. On the Tenant Allow/Block Lists page, the spoof intelligence insight looks like this:

   

   The insight has two modes:

   • Insight mode: If spoof intelligence is enabled, the insight shows you how many messages were detected by spoof intelligence during the past seven days.
   • What if mode: If spoof intelligence is disabled, then the insight shows you how many messages would have been detected by spoof intelligence during the past seven days.

To view information about the spoof intelligence detections, click View spoofing activity in the spoof intelligence insight.

On the Spoof intelligence insight page that appears after you click View spoofing activity in the spoof intelligence insight, the page contains the following information:

• Spoofed user: The domain of the spoofed user that’s displayed in the From box in email clients. The From address is also known as the 5322.From address.
• Sending infrastructure: Also known as the infrastructure. The sending infrastructure will be one of the following values:
  • The domain found in a reverse DNS lookup (PTR record) of the source email server’s IP address.
  • If the source IP address has no PTR record, then the sending infrastructure is identified as <source IP>/24 (for example, 192.168.100.100/24).
  • A verified DKIM domain.
• Message count: The number of messages from the combination of the spoofed domain and the sending infrastructure to your organization within the last 7 days.
• Last seen: The last date when a message was received from the sending infrastructure that contains the spoofed domain.
• Spoof type: One of the following values:
  • Internal: The spoofed sender is in a domain that belongs to your organization (an accepted domain).
  • External: The spoofed sender is in an external domain.
• Action: This value is Allowed or Blocked:
  • Allowed: The domain failed explicit email authentication checks SPF, DKIM, and DMARC. However, the domain passed our implicit email authentication checks (composite authentication). As a result, no anti-spoofing action was taken on the message.
  • Blocked: Messages from the combination of the spoofed domain and sending infrastructure are marked as bad by spoof intelligence. The action that’s taken on the spoofed messages is controlled by the default anti-phishing policy or custom anti-phishing policies (the default value is Move message to Junk Email folder). For more information, see Configure anti-phishing policies in Microsoft Defender for Office 365.

You can click selected column headings to sort the results.

To filter the results, you have the following options:

• Click the Filter button. In the Filter flyout that appears, you can filter the results by:
  • Spoof type
  • Action
• Use the Search box to enter a comma-separated list of spoofed domain values or sending infrastructure values to filter the results.

When you select an entry from the list, a details flyout appears that contains the following information and features:

• Allow to spoof or Block from spoofing: Select one of these values to override the original spoof intelligence verdict and move the entry from the spoof intelligence insight to the Tenant Allow/Block List as an allow or block entry for spoof.
• Why we caught this.
• What you need to do.
• A domain summary that includes most of the same information from the main spoof intelligence page.
• WhoIs data about the sender.
• A link to open Threat Explorer to see additional details about the sender under View > Phish in Microsoft Defender for Office 365.
• Similar messages we have seen in your tenant from the same sender.

An allowed spoofed sender in the spoof intelligence insight or a blocked spoofed sender that you manually changed to Allow to spoof only allows messages from the combination of the spoofed domain and the sending infrastructure. It does not allow email from the spoofed domain from any source, nor does it allow email from the sending infrastructure for any domain.

For example, the following spoofed sender is allowed to spoof:

• Domain: gmail.com
• Infrastructure: tms.mx.com

Only email from that domain/sending infrastructure pair will be allowed to spoof. Other senders attempting to spoof gmail.com aren’t automatically allowed. Messages from senders in other domains that originate from tms.mx.com are still checked by spoof intelligence, and might be blocked.

Be diligent about spoofing and phishing protection. Here are related ways to check on senders who are spoofing your domain and help prevent them from damaging your organization:

• Check the Spoof Mail Report. You can use this report often to view and help manage spoofed senders. For information, see Spoof Detections report.
• Review your Sender Policy Framework (SPF) configuration.
• Review your DomainKeys Identified Mail (DKIM) configuration. You should use DKIM in addition to SPF and DMARC to help prevent attackers from sending messages that look like they are coming from your domain. DKIM lets you add a digital signature to email messages in the message header.
• Review your Domain-based Message Authentication, Reporting, and Conformance (DMARC) configuration. Implementing DMARC with SPF and DKIM provides additional protection against spoofing and phishing email. DMARC helps receiving mail systems determine what to do with messages sent from your domain that fail SPF or DKIM checks.