The Common Attachment Types Filter

The Common Attachment Types Filter is a feature that was rolled out to Exchange Online earlier this year. If you haven’t opened your malware filter for a while, you may not even know this new filter is there!

With this filter, you no longer need to create transport rules to block file types as attachments (for example, .exe, .reg, .bat, etc…). While attachments are always scanned for malware, organizations typically prevent certain file types from entering their environment through email.

If your organization currently uses transport rules to block certain file types, moving that configuration over to the Common Attachment Types Filter can provide benefits like user notifications and reducing your number of transport rules.

If you were an Exchange Online customer prior to the roll out of this filter, by default it will be disabled. For organizations that signed up for Exchange Online after this filter was rolled out, you will find this filter enabled by default.


Enabling and Configuring

The Common Attachment Types Filter can be found in the malware filter. In the Exchange Online portal, browse to Protection, and then Malware Filter.


malware filter


In the settings of the malware filter, you will find the Common Attachment Types Filter configuration.


malware filter settings


By default the File Types list will be pre-populated with file extensions that can be dangerous. This list can of course be modified to your hearts content.

With transport rules, it's not possible to strip an attachment while still allowing the message to be delivered. Because the Common Attachment Types filter is part of the malware filter, this is possible by enabling an end user response.


malware detection response


With the above response enabled, if a user receives a message with a file attachment type that is on the filter list, the attachment will be replaced with a text file which contains information about the block. The body of the original message will remain intact and be delivered along with the replacement text file. This is an example of a text file that would replace a stripped attachment.


text file


Another benefit is that this is a True-Type filetype filter. This means that we try to detect the file type based on its contents, not just by the extension. For example, if an executable file has its extension renamed from .exe to .txt, it will still be detected as an executable file and stopped.



If you have been using transport rules to prevent certain attachment types from being sent, I would recommend you check out the Common Attachment Types Filter in the malware filter. There are many benefits from using this filter to block file types as opposed to transport rules.

Please let me know what your thoughts are in the comments below.



Comments (14)
  1. mombu says:

    Good feature. Want to block zip files, but there is no Zip extension.

    1. Good find. You won’t find extensions to common file types in that list. To block anything that is not in that list, you would need to use a transport rule.

  2. Just Karl says:

    This is a step in the right direction, but a little too draconian.
    Suppose an email comes through with 10 attachments, and only 1 is a .exe file. I want the other 9 delivered, and the .exe blocked.

    1. Brent Quick says:

      If one is an EXE the risk of the rest being a threat justifies the response. If the recipient got a notice and as admin you get a notice you can release the mail or if sender is to be trusted whitelisted.

  3. Brent Quick says:

    Is there a way to view the entire list of extensions. I can see the list but not simply export it to text. I have to log into CMDB the rules and the extensions being blocked so having a text file of types is needed.

    1. Hi Brent, the file types can be obtained with PowerShell, and from there could be exported to text. The following PowerShell would export the file types in my malware filter named “Default.”

      $variable = Get-MalwareFilterPolicy Default
      $variable.FileTypes > FileTypes.txt

  4. eastcoast says:

    Will this do file inspection or will it only strip based on filename?
    So in the scenario where someone renames example.exe to example.txt and sends it along, I want my filter to be smart enough to recognize the .txt file as an executable. Can it do that? Thanks.

    1. Hi EastCoast,

      The service inspects the file contents, and not just the file name. If example.exe is renamed to example.txt, as long as you have EXE in the Common Attachment Types Filter, this file would get stripped.

      1. RobertL says:

        I have enabled this feature and added the complete list of file extensions. I tried the file rename trick with a .exe file (to .txt) and the filter correctly triggered. But when I tried with a couple of other file types (specifically .msi and .vbs files renamed to .txt) the files came through and bypassed the filter. Am I missing something?

        1. Hi Robert, I believe that we only “true detect” executable files. If I find anything different I’ll post back here.

  5. Chris Sohns says:

    The country of Estonia has a standard document format, BDOC. BDOC is a new digital signature format developed to replace the DDOC (DigiDoc) digital signature format specific for Estonia only.

    Currently, EOP identifies BDOC files as Java archives (.jar), this prevents us from transmitting BDOC document attachments to and from Estonian customers and government entities when we block the JAR file types in EOP. Zipping the file is also caught by EOP. Transport rules can match file extension, but do not appear to have a method to bypass EOP.

    Do you have any suggested guidance?

    1. Hi Chris, this is really interesting. You could zip the file in a password protected zip file, and then zip that in another password protected zip file. This would prevent EOP from seeing the file type… although not super practical to have everyone do this. I would recommend opening up a support case so that we can get this up to our product engineering team for investigation.

  6. JimK says:

    Question: How does this compare to a transport rule that checks the file attachment based on “Any attachment has executable content” option? The challenge is always based on external vs. internal messages and the Malware filter triggers on both. Can that be set to focus on only External messages?

    Also, what other options are out there for creating more trust (slightly more vs. full trust) for internal only docs like Word “docm” files? For example, would this work? In a simplistic fashion you might have two rules. One rule for External Senders that blocks/quarantines any matches and another rule that does something else for Internal Senders (prepended warning, increasing SCL, other).

    What are the “gotchas” you see?

    1. Hi Jim, I think that Transport Rules give you more flexibility. You can easily report on them, and quickly add exceptions. For example, maybe you want to allow IT people to send executable files, and so you could add them as an exception. As the common attachment types is located in the malware filter, if there is a trigger, the message will be treated as malware and quarantined in the malware quarantine. With a transport rule, you could choose any action you like (dropping the message, quarantine it, forward it to an admin for review, etc…).

      The malware filter will also apply to all messages, both internal and external. Where as with a transport rule, you can decide with predicates who it applies to. I personally prefer transport rules as I think they are more flexible.

Comments are closed.

Skip to main content