Recipient Notifications

The ability to send a notification to the recipient when a transport rule triggers. This is a request that we have received from a lot of customers, and I’m happy to let you know that it is now rolling out in the form of an action in EOP transport rules. Sweet!

Recipient Notifications

Let’s say you have a transport rule that quarantines all inbound messages with an executable attachment. In the past there was no way to automatically notify your users that a message destined to them had been redirected to the quarantine because of your transport rule. Now, with Recipient Notifications, your transport rules can send a notification to the recipient when they trigger.


When creating a transport rule, you will notice a new action called “Notify the recipient with a message…”

As an example, if we want to quarantine messages destined to our users that contain executable content, and want to notify them when this happens, our transport rule could look like this.

In this rule is our own domain. Here’s what the notification text looks like in the above rule.

A company policy blocked an inbound message to you – Executable content not permitted.<br><br>

Date: %%MessageDate%% UTC<br>
From: %%From%%<br>
To: %%To%%<br>
CC: %%Cc%%<br>
Subject: %%Subject%%

And here is what the notification looks like that the recipient will receive when this rule triggers.

You’ll notice that I was able to insert information from the original message into the notification using variables. Let’s look next at what customization is possible.

Notification customization

Variables can be added into the notification text to include information from the original message. The following variables are supported for recipient notifications.

Type of Information

The sender of the message for which the notification is being generated. %%From%%
The recipients listed on the "To" line. %%To%%
The recipients listed on the "Cc" line. %%Cc%%
The subject of the message for which the notification is being generated. %%Subject%%
The headers from the original message. %%Headers%%
The sent date of the original message. Time is in UTC. %%MessageDate%%


If you don’t see the recipient notification action yet in your transport rules don’t panic. This feature only just lit up in my test tenant this past week and will still be rolling out. Enjoy this new capability!


TechNet documentation has not been updated yet, but once it has I will post links here.

Comments (13)

  1. Anonymous says:

    Hi Andrew,

    The sender was outside my organisation..

    A workaround from your support team is to run this command on my on-premise server: "set-SenderFilterConfig -BlankSenderBlockingEnabled $false", This then allows it to receive messages with blank senders.

    Now i get notifications and the headers just say this:
    Sender: Microsoft Outlook

    This solution seems odd to me though, it just looks wrong having no sender address to me.

  2. Hi John, this can be accomplished with a transport rule. If you want to specifically target internal senders, you could create a transport rule that looks as follows. I’m assuming your own domain is

    If sender domain is
    Has an attachment with a file extension that matches one of these values: ‘exe’

    Reject the message and include the explanation ‘Unsupported attachment detected’ with status code 5.7.1.

    The above rule would reject message coming from your own domain ( and reject them. The sender will receive an NDR with the explanation that you specify in the transport rule.

  3. Hey Mark, that’s very interesting, I haven’t been able to replicate that behavior with my testing. In your testing, is the sender from inside or outside your organization?

  4. Anonymous says:

    ..this web form striped out the bit after to: and Message-ID:.. but the sender: line is verbatim..

  5. Hi there Erlend, I just replicated your rule in my test tenant and did not see what you experienced. In my test, the sender received the rejection and the recipient in my tenant received the notification that I had configured in the rule. Are you still
    having problems with your rule?

  6. Useful article. Thank you.

  7. Erlend says:

    Hello. I've enabled this in our "block zip/rar attachments" rule, but the notification is never sent.

    The actions in our rule is 1) reject the mail with the following message "blah blah", 2) Notify recipient .
    The mail is rejected, and the sender gets a message from postmaster explaining this, but action #2 never fires… What could be wrong?

  8. Mark Hempstead says:

    I too find the recipient never receives the notification.. looking at the logs it is failing as the sender address for the notification is missing.. logs state sender is "<>" !!

  9. John Willoughby says:

    This is frustratingly close to what we need. If one of our users is attempting to send blocked attachment types we would much prefer to notify the SENDER with a message, rather than the recipient. Is there a way to achieve that? I only see Policy Tips
    which does not allow enough characters for a proper message.

  10. Ady says:

    When will we get this same functionality in Exchange on premises? It's just what I'm looking for at the moment.

  11. Steve Fuller says:

    I was able to get around this by setting a high SCL to the message. That let me give a notification and put in in the user's Junk Folder.

  12. madhavi says:

    can we also include what kind of attachement extension was blocked by rule?

Skip to main content