When you have multiple email aliases associated with your Exchange or Office 365 based email account, it can be useful to know which email address it was sent to. However Outlook does not show this information.
I can think of a couple of ways to resolve this:
- Use an Office 365 transport rule to modify the message subject so that emails sent to a particular email address can be easily recognised.
- Use an Outlook rule to examine the message header and display an alert or perform some other action when an email to an alias is received.
The advantage of using a transport rule is that the rule is always executed, it does not depend on the Outlook client running. This is useful because mobile devices or other clients will not execute any rules.
There are a couple advantages of using Outlook the Outlook method:
- Greater flexibility over what you want to do with the message.
- No need for Office 365 administrator rights to set up.
As the transport rule method has already been documented, this post is about how to use an Outlook rule to determine which email alias an email was sent to.
Using an Outlook rule to determine which email alias an email has been sent to
-
- Go to File and then “Manage Rules and Alerts” and then click on “New rule”.
- Click on “Apply rule on messages I receive” from the “Start from a blank rule” section and click Next.
- Choose “with specific words in the message header”.
- In the “Step 2” section at the bottom of the page, click on the “specific words” link:
- Type in the email address that you want to identify and click on “Add” and then click OK.
(Note: You can add multiple email addresses here to use this rule for multiple aliases.)
- You will drop back to the main rule creation dialog box, click next.
- On this page you have lots of options about what to do with the identified message, the options are quite self explanatory.
- I am going to choose “display a specific alert in the New Item Alert window” as below:
- This means that when I receive an email to the alias specified, Outlook will show an alert to inform me.
- Finish creating the rule with any other options or exceptions that you require.
- You should get an alert when messages are sent to the alias:
I hope this post was helpful, if you did, I would really appreciate it if you rated it 😀
Jay says
Thank you for the post
Robyn says
This is awesome, thanks!!
Victor says
Alternatively you can use ShowAlias freeware tool: https://www.ivasoft.com/showaliasowa.shtml
Lance says
Very helpful and worked perfectly. Exactly what I was looking for!
??? says
An outstanding share! I’ve just forwarded this onto a colleague who has been doing
a little homework on this. And he in fact bought me dinner
simply because I stumbled upon it for him… lol.
So let me reword this…. Thank YOU for the meal!!
But yeah, thanks for spending some time to talk
about this issue here on your internet site.
Paulie says
No worries – enjoy your meal!
Stefano Guardigli says
Thank you very much
I have tried and it works but i have noticed that if another alias exists whose email address contains that address, than the rule maage it in the same way.
For example if arrive a message that send to alias “[email protected]” the rule manage it too.
Does exists a delimiter chracter for avoit this ?
Jake says
Stefano, or anyone else with the same issue:
Use an exception – “except when header includes…”, and include the alternative. I had the same issue, youth@ was an alias of childandyouth@ so the rule filtered both of them, so I added an “except when” and it cured it.
Trish says
Thank you. This doesn’t seem to work for people within your organization. I’ve tested a few alias’ with a person within my org and it doesn’t catch the rule. Assuming because the exchange knows it’s my alias. This will likely still be the best solution to my problem. Really wish we could see who it was sent to before the fwd in the header.
Mitchell S says
This is the exact scenario i was looking for… well documented Thank you very much
Peter A says
As Trish mentioned, this works for external senders, but internal senders bounce to the inbox – unfortunately, this makes this otherwise perfect process not work in my situation – as it was going to be used for employees emailing me… As she mentioned, seems that Microsoft is too “smart” to let the rule work internally.
me says
thank you.
Shaun says
Does this work if the alias is BCC’d?