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 (18)
  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.

    1. Phil M says:

      Why would Microsoft code this to send as a blank sender when recognising that email with a blank sender is an issue !!? They’ve essentially broken a level of protection. Do I disable the filtering on my Edge servers so that we can receive the notifications or not …… what a pain.

  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?

  13. Lloyd says:

    This works well for inbound messages. But what about outbound? I realised today I had not scoped this rule for inbound only; an internal user sent a message which ended in quarantine and the external recipients received notifications from the postmaster that their message was blocked.

    In this case, I want to “Notify the sender with a message…”
    Is there anything like this?

    [I tried with Policy Tips and got this error: “The NotifySender action isn’t compatible with ‘AttachmentHasExecutableContent’ predicate.” And I’m not sure it would have worked on mobile clients either.

  14. Anonymous says:

    Thank you for your article, Andrew. I configured our notification to our needs and it works good. But I miss one thing: We block i. e. old Office file formats like DOC or XLS. But the recipients don´t know the exact reason for the blocked email, so that they can decide to communicate with the sender before they contact the local IT.

    When I look at the quarantined email in EOP interface, I can see the attachments. Do you know, if there is also a variable for the attachment which I can use in the recipient notification to inform the users, which files are the reason for blocking the particular email?

    1. I don’t believe there is a variable which links to the attachment name unfortunately. I’look into this though and post back here if I find one.

  15. Thx for the article, Andrew. The content is still interesting, three years on. I’m replying to agree with John Willoughby’s comment below; MSFT could give us the best of both worlds if a sender-notification action were available. This would be great to notify internal senders that their content contained (e.g.,) PCI data and was acted upon in whatever way. Security & Compliance Center allows the admin to create lengthy notice messages to the sender, but doesn’t allow dynamic content of the sort available here — the %%parameter%% attributes. I’ll post this over at User Voice as well, as an alternate means to get some traction for this requirement.

Comments are closed.

Skip to main content