Microsoft 365 anti-malware policy settings: what each one does

Every Microsoft 365 tenant scans email for malware, and you can't switch that off. What you can change is what happens around the scan: which file types are blocked outright, whether blocked mail bounces or waits in quarantine, who can see it, and who gets told. This guide walks through each anti-malware policy setting with its default value, Microsoft's Standard and Strict values, and the PowerShell behind it, at the time of writing (November 2026).

What does a Microsoft 365 anti-malware policy control?

A Microsoft 365 anti-malware policy controls the configurable parts of malware protection: the common attachments filter, zero-hour auto purge (ZAP) for malware, the quarantine policy for malware detections, and admin notifications. The scan itself is always on. Microsoft Learn says that "in all organizations with cloud mailboxes, anti-malware protection for email is on by default," and that Microsoft 365 "quarantines messages when malware is found in any attachment."

A few facts from Microsoft's documentation explain what the scan does without any configuration:

• Engine. Microsoft's anti-malware FAQ says that, as of July 2024, "messages are scanned with the Microsoft anti-malware engine only." You can't choose other engines.
• Updates. Each server checks for new malware definitions every hour. During outbreaks, Microsoft also publishes detection rules "every 2 hours" before a definition exists.
• Scope. The service scans "all inbound and outbound messages, including messages sent between internal recipients," and it drills into compressed files such as .zip, recursively "many layers deep."
• No bypass. "No user or admin-configurable setting can exempt email attachments from being scanned." Mail flow rules can't skip malware filtering either. The only exception is a SecOps mailbox in the advanced delivery policy.

Anti-malware policies are included with every cloud mailbox; they aren't a Defender for Office 365 feature. Sandboxing unknown attachments before delivery is a separate feature, Safe Attachments, which does need Defender. Our guide to Safe Links and Safe Attachments covers it.

Where do you find anti-malware policies?

You find anti-malware policies in the Microsoft Defender portal at Email & collaboration > Policies & rules > Threat policies > Anti-Malware, or directly at https://security.microsoft.com/antimalwarev2. Microsoft's configuration article lists the permissions: membership in the Organization Management or Security Administrator role groups to change policies, or Global Reader, Security Reader or View-Only Organization Management to read them.

The page shows three kinds of policy:

• Default. Every tenant has one. It applies to all recipients, can't be turned off or deleted, and always has the priority Lowest. It has no recipient conditions to set, but you can change every other setting.
• Standard Preset Security Policy and Strict Preset Security Policy. These appear when you use preset security policies. You can't edit them here; Microsoft sends you to the Preset security policies page instead.
• Custom policies. You create them for specific users, groups or domains.

One detail is easy to miss. Microsoft says "the default anti-malware policy applies to inbound and outbound email. Custom anti-malware policies apply to inbound email only." Outbound protection always comes from the default policy.

What does each setting do, and what is the default?

The table below lists each setting on the Protection settings page with the PowerShell parameter and Microsoft's values from its recommended settings page.

* Microsoft says the filter is on by default "in new anti-malware policies that you create in the Defender portal or in PowerShell, and in the default anti-malware policy in organizations created after December 1, 2023." Older tenants should check their default policy.

Notice that Standard and Strict don't differ here. Microsoft's presets tighten anti-spam and anti-phishing actions, but the anti-malware values are the same as a correctly configured default policy. For admin notifications, Microsoft says, "We have no specific recommendation for this setting."

Common attachments filter

The common attachments filter blocks attachments by file type, without waiting for a malware verdict. Microsoft's reasoning: "Some types of files aren't suited to email (for example, executable files). Rather than scanning these files for malware, why not block them all?" The default list has 53 types, including exe, dll, bat, cmd, scr, vbs, hta, iso, img, lnk, msi, jar, reg and docm.

The filter uses "best effort true type matching", which reads the file's characteristics (for example, its leading and trailing bytes) instead of trusting the name. Microsoft's example: an .exe renamed with a .txt extension is still detected as an .exe. If true type matching fails or isn't supported for that type, the filter falls back to the extension.

Select file types opens a longer list of extra types you can tick, such as js, jse, ps1, vhd, one, html and zip, or you can type your own. Which ones to add, and which are too disruptive to block, is covered in dangerous email attachment types. .svg isn't on Microsoft's extra list, so you'd have to add it as a custom value; see SVG attachment phishing.

Reject or quarantine?

When these types are found has two values: Reject the message with a non-delivery report (NDR), the default, or Quarantine the message. The Set-MalwareFilterPolicy reference adds that with Reject, "the message is not available in quarantine."

That difference matters more than it looks:

• Reject tells the sender at once, so a customer who sent a legitimate .msi knows to share it another way. But you can't recover the message, and you can't check later whether it was an attack.
• Quarantine keeps the message so an admin can review and release it. Microsoft's quarantine retention table gives 30 days for messages quarantined by anti-malware policies. The sender gets no bounce, so a genuine sender may wait for a reply that never comes.

Microsoft says that because "the block is from an admin-defined policy, these messages don't get a malware verdict," and that admin notifications "are sent only for attachments that are classified as malware." Microsoft doesn't state the combined effect, but our reading is that a file-type block alone doesn't trigger the admin notification. Don't rely on the alert for those blocks; check quarantine or message trace instead.

Zero-hour auto purge for malware

Enable zero-hour auto purge for malware lets Microsoft act on mail after delivery. If a message delivered to an Exchange Online mailbox is later found to contain malware, ZAP quarantines it, whether it was read or not. It's on by default, and Microsoft recommends leaving it on. Zero-hour auto purge explains its 48-hour window and the cases where it doesn't act.

Quarantine policy

The quarantine policy decides what recipients can do with messages quarantined as malware, and whether they're told. The default is AdminOnlyAccessPolicy, which has quarantine notifications turned off.

Even a more permissive policy has a hard limit. Microsoft says "recipients can't release messages quarantined as malware, regardless of how the quarantine policy is configured." If the policy allows release, users can only request it. If you want users told that something was held, assign a quarantine policy with notifications on; our guide to quarantine policies and notifications shows how. For the admin side, see releasing quarantined email in Microsoft 365.

Admin notifications

You can send a notification to an admin address for undelivered malware from internal senders, external senders or both, and customize the From name, From address, subject and text. Both are off by default, and Microsoft says it has "no specific recommendation" for them. In our view, the internal-sender alert is the more useful of the two for a small team: an internal user sending malware usually means a compromised mailbox or an infected device.

Who does a custom anti-malware policy apply to?

A custom anti-malware policy applies to the internal recipients you name with three conditions: Users, Groups and Domains. Microsoft's rules for combining them:

• Several values in one condition use OR.
• Different condition types use AND. A policy for user romain@contoso.com and group Executives applies to Romain only if he's in Executives.
• Exceptions always use OR.
• Dynamic distribution groups aren't supported, and a domain condition includes its subdomains unless you exclude them.

Order decides which policy wins. The Strict preset applies first, then Standard, then custom policies by priority (0 is highest), then the default. Microsoft says "anti-malware protection stops for a recipient after the first policy is applied." Settings in default or custom policies are ignored for anyone in a preset policy.

How do you set up an anti-malware policy?

Most tenants only need to fix the default policy. Microsoft "typically" recommends the Standard and Strict presets over custom policies. Our suggested order:

1. Open https://security.microsoft.com/antimalwarev2 and select Default (click the row, not the check box).
2. In Protection settings, select Edit protection settings. Confirm Enable the common attachments filter is selected. If it isn't, your tenant predates December 2023; select it.
3. Select Select file types and add the extra types your business never receives by email. Our suggestion: start with script and disk-image types such as js, jse, ps1 and vhd.
4. Decide Reject or Quarantine. Our suggestion: quarantine if one admin reviews quarantine at least daily; keep Reject if nobody will.
5. Leave Enable zero-hour auto purge for malware selected and the quarantine policy as AdminOnlyAccessPolicy, unless you want recipients notified.
6. Select Notify an admin about undelivered messages from internal senders and enter a monitored mailbox.
7. Save, wait up to one hour (Microsoft's FAQ figure), then test as described below.

Only create a custom policy for a group that needs different handling, such as an IT team that receives .msi installers from vendors and wants them quarantined for review rather than bounced.

How do you configure anti-malware policies with PowerShell?

In Exchange Online PowerShell, a policy is two objects: a malware filter policy (the settings) and a malware filter rule (who it applies to and its priority). The portal creates both with one name; PowerShell manages them separately, and removing one doesn't remove the other.

Check the default policy:

Get-MalwareFilterPolicy -Identity Default | Format-List EnableFileFilter,FileTypeAction,ZapEnabled,QuarantineTag,FileTypes

Turn on the filter and add types without wiping the list. This mirrors Microsoft's example; -FileTypes on its own replaces the whole list:

$types = Get-MalwareFilterPolicy -Identity Default | Select-Object -ExpandProperty FileTypes
$types += "js","jse","ps1","vhd"
Set-MalwareFilterPolicy -Identity Default -EnableFileFilter $true -FileTypes $types

Switch file-type blocks to quarantine and turn on the internal-sender alert (example address):

Set-MalwareFilterPolicy -Identity Default -FileTypeAction Quarantine -EnableInternalSenderAdminNotifications $true -InternalSenderAdminAddress security@example.com

A custom policy needs both cmdlets, created in the two steps Microsoft describes: the policy first, then the rule (names and group are examples):

New-MalwareFilterPolicy -Name "IT Malware Policy" -EnableFileFilter $true -FileTypeAction Quarantine
New-MalwareFilterRule -Name "IT Malware Policy" -MalwareFilterPolicy "IT Malware Policy" -SentToMemberOf "IT Team"

-SentToMemberOf sets the group condition; -RecipientDomainIs sets a domain condition. A policy created in PowerShell stays invisible in the portal until it has a rule.

How do you test that the policy works?

Microsoft's documented test uses the EICAR test file, a harmless 68-byte text file that anti-virus products agree to detect. Follow the steps on Microsoft's configuration page, then:

1. Send it as an attachment internal to internal, internal to external and external to internal, using a client and service that don't block it first.
2. Check that each message was quarantined and that any admin notification arrived.
3. To test the common attachments filter, send a harmless file with a blocked extension and confirm you get an NDR, or find it in quarantine.
4. Look the messages up in message trace, and paste the headers of anything delivered into the Microsoft 365 Spam Header Decoder.
5. Delete the test file afterward so it doesn't alarm anyone.

What if a legitimate file is blocked?

A legitimate file is blocked for one of two reasons, and the fix differs. If the common attachments filter blocked it, the block is your own policy: release it from quarantine (if you chose quarantine), remove that type from the list, or put the affected group in a custom policy with a shorter list. If the scanner gave it a malware verdict, you can't allow it with a rule. Microsoft says to report the file as a false positive through the Submissions page instead.

Either way, ask the sender to share large or unusual files through a link to your own file storage. Business email is a poor way to move installers and disk images.

Does anti-malware still work behind a filtering gateway?

Yes. Microsoft's FAQ says the service "is server agnostic" and scans messages in transit. If your MX points to a filtering service in front of Microsoft 365, Microsoft says to turn on Enhanced Filtering for Connectors so it can use the true message source in filtering decisions. A gateway with its own attachment-type and macro filters adds a second layer; it shouldn't replace the Microsoft policy. See Microsoft 365 built-in filtering vs a gateway for how the layers divide the work.

Next steps

• Open your default anti-malware policy today and confirm the common attachments filter is on, especially if the tenant is older than December 2023.
• Add the extra file types you never need by email, and choose Reject or Quarantine deliberately.
• Turn on the internal-sender admin notification and send it to a mailbox someone reads.
• Review the related policies next: anti-phishing policy settings and anti-spam policies.
• If you want attachment-type filtering and a Microsoft Office macro filter before mail reaches your tenant, see how iBlockSpam works with Microsoft 365.