Tenant Allow/Block List: allow spoofed senders and block domains safely

To let a legitimate sender that fails SPF, DKIM or DMARC reach your users, add an allow entry for the exact domain pair (spoofed user plus sending infrastructure) on the Spoofed senders tab of the Tenant Allow/Block List in the Microsoft Defender portal, or override the verdict in the spoof intelligence insight. To block a sender tenant-wide, add a block entry on the Domains & addresses tab, remembering that contoso.com and *.contoso.com are separate entries and that a domain block also stops your users from sending to that domain. The procedures below show both, in the portal and in PowerShell, with the limits that keep the list from becoming a security hole.

Who this is for and what you will have

This guide is for Microsoft 365 and security administrators who need to deal with false positives from spoof intelligence, or who want to stop a malicious or unwanted sender across the tenant. It applies to all organizations with Exchange Online mailboxes; Defender for Office 365 raises the entry limits. At the end you will have:

• A narrowly scoped allow entry for each legitimate spoofed sender.
• Block entries for domains and addresses that cover subdomains correctly and expire on purpose.
• A clear rule for when to use the Tenant Allow/Block List and when to use submissions, anti-spam policies or anti-phishing trusted senders.
• PowerShell commands to review and clean up entries.

How the Tenant Allow/Block List works

The Tenant Allow/Block List overrides Microsoft's filtering verdicts during mail flow and at time of click. Entries for domains and email addresses apply to the 5322.From address (the From address users see), not to the envelope 5321.MailFrom address. Block entries always take precedence over allow entries.

The tabs relevant to email senders behave differently:

Entries start working within 5 minutes. If Microsoft decides an allow entry is no longer needed, it removes the entry automatically and the alert policy Removed an entry in Tenant Allow/Block List raises an alert.

Entry limits

Spoofed sender entries have a separate limit of 1,024 allow and block entries combined.

Prerequisites

• Membership in the Organization Management or Security Administrator role group in Exchange Online, or the Security Administrator role in Microsoft Entra ID. The Security Operator role group (Tenant AllowBlockList Manager role) also works, but only when assigned in the Exchange admin center under Roles > Admin roles. If Defender XDR Unified RBAC is active for both Defender for Office 365 and Exchange Online permissions, you need Authorization and settings/Security settings/Detection tuning (manage) in the Defender portal.
• Access to the Defender portal at https://security.microsoft.com/tenantAllowBlockList.
• Exchange Online PowerShell for the scripted steps.
• For spoofed senders: a sample message header, so you can read the source IP address and the Authentication-Results header.

Allow a legitimate spoofed sender

Find out what spoof intelligence saw

Spoof intelligence looks at senders that fail explicit email authentication (SPF, DKIM or DMARC). If a sender still passes Microsoft's implicit composite authentication, the insight shows it as Allowed; senders it marks as bad show as Blocked. Typical legitimate cases are a SaaS platform sending as your domain, a mailing list relaying external messages, or an internal application that sends notifications.

1. Go to Email & collaboration > Policies & rules > Threat policies > Tenant Allow/Block Lists and select the Spoofed senders tab.
2. In the spoof intelligence insight, select View spoofing activity. The Spoof intelligence insight page lists seven days of detections with Spoofed user, Sending infrastructure, Message count, Last seen, Spoof type (Internal for your accepted domains, External otherwise) and Action.

In PowerShell, the same data covers 30 days:

Connect-ExchangeOnline -UserPrincipalName admin@contoso.com
Get-SpoofIntelligenceInsight

Messages from domains whose DMARC policy is p=reject or p=quarantine don't appear in this insight. Those are handled by the Honor DMARC record policy when the message is detected as spoof setting in your anti-phishing policy, so if a sender with a strict DMARC policy is being blocked, the fix is usually on the sender's side.

Option 1: override the verdict in the insight

On the Spoof intelligence insight page, select the entry and choose Allow to spoof, then Apply. The entry moves from the insight to the Spoofed senders tab as a manual allow entry.

Option 2: create the domain pair yourself

You can add an allow entry before spoof intelligence ever blocks the sender. A domain pair has the form <spoofed user>, <sending infrastructure>:

• Spoofed user: an email address (chris@contoso.com), a domain (contoso.com) or *.
• Sending infrastructure: the domain from the PTR record of the source IP address, a verified DKIM domain, the source IP as <IP>/24 if there's no PTR record, or *.

You can use a wildcard on one side but not both; *, * isn't allowed. If you use a PTR domain, it must match the PTR for the connecting IP in the Authentication-Results header, and Microsoft recommends the organizational domain: if the PTR is smtp.inbound.fabrikam.com, use fabrikam.com. If PTR resolution fails for a domain, the entry doesn't work, so use the /24 IP form instead.

In the portal, on the Spoofed senders tab select Add, enter up to 20 domain pairs (one per line), select the Spoof type and the Action Allow, and select Add. In PowerShell:

New-TenantAllowBlockListSpoofItems -Identity Default -Action Allow `
  -SpoofedUser contoso.com -SendingInfrastructure fabrikam.com -SpoofType Internal

This example lets fabrikam.com's mail servers send messages that show contoso.com in the From address, which suits a service provider sending on your behalf. Only that combination is allowed: another source spoofing contoso.com is still checked, and fabrikam.com's servers sending as any other domain are still checked too. Allow entries for spoofed senders cover intra-org, cross-org and DMARC spoofing, and they never expire, so record why you created each one.

An allow entry fixes the symptom, not the cause. For your own domains, the lasting fix is to authorize the sender in SPF or have it sign with DKIM for your domain, after which the allow entry can be removed.

Block a domain or sender safely

Choose the right block

Create the block entry

In the portal, on the Domains & addresses tab select Add > Block, enter up to 20 domains or addresses, choose Remove block entry after (1 day, 7 days, 30 days, Never expire or a specific date up to 90 days ahead) and add a note. In PowerShell:

New-TenantAllowBlockListItems -ListType Sender -Block -Entries "adatum.com","*.adatum.com" -NoExpiration -Notes "Phishing campaign, ticket 4821"

Three side effects matter before you save:

1. Subdomains are separate. adatum.com doesn't block mail.adatum.com, and *.adatum.com doesn't block adatum.com. To block both, create both entries, as above.
2. Outbound mail is blocked too. Users can't send to a blocked domain or address. They get 550 5.7.703 Your message can't be delivered because messages to XXX, YYY are blocked by your organization using Tenant Allow Block List., and the entire message is blocked for every recipient, even if only one recipient matches. Blocking a partner's domain during an incident can therefore stop your own staff from replying to them.
3. The verdict is high confidence phishing. Blocked mail is marked as high confidence phishing and quarantined. If legitimate mail suddenly arrives in quarantine as high confidence phishing, check for a block entry on a domain or URL it contains. The quarantine policies guide covers how that quarantine is handled.

Addresses with special characters must be URL-encoded; for example, a space becomes %20 and a plus sign %2B.

Block a spoofing source but not the real domain

If attackers spoof a partner's domain from a specific infrastructure, a spoofed sender block entry stops that pair without blocking the partner's own mail:

New-TenantAllowBlockListSpoofItems -Identity Default -Action Block `
  -SpoofedUser fabrikam.com -SendingInfrastructure 203.0.113.0/24 -SpoofType External

Mail from that pair is marked as phishing, and the anti-spam policy for the recipient decides what happens to it.

When an allow entry for a domain is justified

Allow entries for domains and addresses are a last resort, because the filters associated with the allowed entity are skipped. The full false-positive workflow, starting with a submission, is covered in fix email false positives with submissions and the Tenant Allow/Block List. If you do need a direct allow entry:

• Direct entries only override bulk, spam, high confidence spam and phishing. For malware or high confidence phishing, submit the message on the Submissions page as I've confirmed it's clean and select Allow this message.
• Allow entries created from a submission are added for the entities that caused the verdict, such as the sender, a URL or a file.
• Messages are still delivered only if they pass the other checks, including email authentication.
• You can't use the Tenant Allow/Block List for impersonation false positives. A submission adds the sender to Trusted senders and domains in the anti-phishing policy that detected the message.

New-TenantAllowBlockListItems -ListType Sender -Allow -Entries "billing@fabrikam.com" -RemoveAfter 45 -Notes "False positive, submission 2026-10-11"

Review and clean up entries

List current entries and remove the ones you no longer need:

Get-TenantAllowBlockListItems -ListType Sender -Block
Get-TenantAllowBlockListItems -ListType Sender -Allow
Get-TenantAllowBlockListSpoofItems -Action Allow -SpoofType Internal
Remove-TenantAllowBlockListItems -ListType Sender -Entries "adatum.com"

To change a spoofed sender entry from Allow to Block, or back, use Set-TenantAllowBlockListSpoofItems -Identity Default -Ids <id> -Action Block, taking the ID from the Identity property of Get-TenantAllowBlockListSpoofItems.

A monthly review keeps the list small: spoofed sender entries never expire, and block entries set to Never expire accumulate quietly.

Verify

1. Wait 5 minutes after creating the entry.
2. Ask the sender to send a new message, or wait for the next one, and trace it with Get-MessageTraceV2.
3. For a spoofed sender allow entry, confirm the message is delivered and that the trace no longer shows it as quarantined or filtered.
4. For a block entry, confirm the message is quarantined as high confidence phishing and that a test message to the blocked domain bounces with 5.7.703, so you know what users will see.

Troubleshooting

The spoofed sender allow entry has no effect. The sending infrastructure doesn't match. Compare it with the PTR in the Authentication-Results header, use the organizational domain, or switch to the <IP>/24 form if the PTR doesn't resolve.

The sender doesn't appear in the spoof intelligence insight. Its domain publishes DMARC p=reject or p=quarantine, or spoof intelligence didn't detect it. Look at your anti-phishing policy's DMARC handling, and ask the sender to fix authentication.

You can't add an allow entry for a blocked message. It was blocked as malware or high confidence phishing; use the Submissions page.

Staff report bounces with 5.7.703 when writing to a partner. A block entry covers that domain or address. Remove or narrow it.

Mail from a subdomain still gets through after blocking a domain. Add the *.domain entry as well.

An allow entry disappeared. Allow entries expire 45 days after last use by default, and Microsoft can remove entries it no longer considers necessary.

Checklist

• Spoof intelligence insight reviewed; every allow is a specific domain pair, not * on the spoofed side unless justified.
• Each spoofed sender allow entry has a documented reason and an authentication fix in progress.
• Block entries created for both domain and *.domain where subdomains matter.
• Outbound impact of domain blocks considered before saving.
• Anti-spam blocked senders used when spam treatment is enough.
• Allow entries for high confidence phishing or malware created only through Submissions.
• Monthly review of entries that never expire.

References

• Manage allows and blocks in the Tenant Allow/Block List
• Allow or block email using the Tenant Allow/Block List
• Review and manage spoof intelligence insight
• Recommended email and collaboration threat policy settings
• Quarantined email messages in Microsoft 365