The request for “catch all mailbox” feature is very popular among Office 365 customer’s.The term “catch all mailbox“, define a concept of mail services, in which a dedicated mailbox is designated as a special mailbox that will “accept” all the E-mail messages that was sent to “non-existing organization recipients”.
The “business need” is the avoid from a scenario of “losing business mail” that was sent to a legitimate organization recipient while the recipient name includes spelling mistake.
For example: our accounts manager E-mail address is BobTheBbuilder@o365pilot.com
In case that someone send to bob E-mail message but, make a spelling mistake and send the E-mail message to the following address – BobBbuilder@o365pilot.com , the mail server (Exchange Online in our scenario) will replay with an NDR message notifying the source sender that there is no such recipient.
For example:
DB3FFO11FD027.mail.protection.outlook.com rejected your message to the following email addresses:
BobBbuilder@o365pilot.com (BobBbuilder@o365pilot.com)
The address you sent your message to couldn’t be found at the destination. It might be misspelled or it may not exist. Try to fix the problem by doing one or more of the following:
- Retype the entire email address manually and resend it – if your mail program automatically suggests an address to use don’t accept it.
- Contact the recipient by some other means (by phone for example) to confirm you’re using the right address. Also ask them to check that any mail forwarding they’ve set up is working correctly.
- Clear the recipient nickname cache in your mail program by following the steps in this article: Status code 5.4.14 in Outlook.com and Office 365.
To be able to avoid this scenario, we would like to set some “organization mailbox” that will accept all of these E-mail messages.
The Exchange administrator or other organization user, will have access permission to that specific “catch all mailbox” and from time to time, they will peek at the “catch all mailbox” to look for a legitimate mail that was supposed to be sent to a specific recipient organization.
Office 365, Exchange Online and “Catch all mailbox” option
The interesting news is that the Office 365 services (Exchange Online as the mail infrastructure) don’t include the feature of “catch all mailbox” by default.
There is no formal information published by Microsoft regarding the reason for not supporting this feature but, the reasonable assumption is that the Office 365 service tries to avoid from this type of service, which can serve as “back door” for spam E-mail that will flood and load Office 365 mail infrastructure.
The current article describes “detour” to this lack of “catch all mailbox” feature and, it’s very important to me to say that this is not a “supported” or “formal” solution that is offered by Microsoft and Office 365 support!
In addition, it’s important to me to make a Full Disclosure; I didn’t invent or think about the solution that will be provided later on the article but instead, write my article based on the following articles that I have found:
The purpose of my article is – to elaborate on the suggested solution and provide “step by step” instruction that is accompanied by screenshots.
Implementing “catch all mailbox” in Exchange based environment – the building blocks
The “trick” that we use for implementing the configuration of “catch all mailbox” in the Exchange Online environment is based on three different components:
1. Change the default domain setting
We will need to change the default public domain settings that is registered at Office 365 from the default settings of Authoritative to internal relay.
2. Use a Dynamic distribution group
We will need to create a new Dynamic distribution group, that will include all of our organization Office 365 recipients.
3. Create an Exchange Online transport rule
We will need to create a new Exchange Online transport rule that will implement the “logic” of the “catch all mailbox“.
Authoritative versus internal relay domain setting
Before we begin with the “technical instructions” it’s very important that we pause for a minute to understand the concept of Authoritative versus internal relay domain setting.
When we register our public domain name in Office 365, the domain considers as “accepted domain”.
By default, when we register our public domain name in the Office 365 portal, from the perspective of Exchange Online, the domain considers as Authoritative
The meaning of this concept is that Exchange Online server considers himself as the only authority for the specific domain.
In case that Exchange Online is addressed by a recipient who tries to send E-mail message to a recipient from the domain that is registered at Office 365, Exchange Online will look at the GAL (Global address list).
Case 1 – in case that the recipient E-mail address appears in the GAL, Exchange Online will “delver” the E-mail message to the destination recipient.
For example, in case that Exchange Online is “responsible” for the domain name – o365pilot.com, when the source recipient tries to send E-mail message to bob@o365pilot.com Exchange Online will check if the specific E-mail address exists.
In our specific scenario, the E-mail address exists and Exchange Online will “forward” the E-mail message to the destination recipient.
Case 2 – in case that the recipient E-mail address doesn’t appear in the GAL, Exchange Online will “reply with an NDR message informing the source recipient, that there is not such recipient. The Exchange Online server can be “sure” that there is a mistake because his only authority who uses for managing the specific domain name.
The configuration of internal relay
An additional option that we can use in Exchange Online environment for configuring the registered domain name is – internal relay
When we configure a specific domain as an internal relay (instead of the default setting of Authoritative), we are “telling” to the mail server (Exchange Online on our scenario) that he is not the only authority for the specific domain name but instead, that the specific domain is “shared” between Exchange Online and “other mail infrastructure”.
When we configure a specific domain name as an internal relay in case that someone addresses Exchange Online and asks to send E-mail to “non-existing recipient” (recipient who is not existed as part of the Exchange Online recipient list), Exchange will understand that he needs to “forward” the mail to the “other mail infrastructure”.
For example – In a scenario in which our domain name is hosted at two separated mail infrastructure, we can configure the domain as internal relay
In this case when “source recipient” address Exchange Online is asking to “delver” E-mail message to the recipient who is not hosted at Exchange Online infrastructure, Exchange Online “understand” that he needs to “forward” the E-mail message to the “other mail infrastructure”.
The way that Exchange Online uses for “locating” the mail server that represents the “other mail infrastructure” is by using a standard DNS query looking for the MX record of the mail server that represents the “shared domain” or another option is to create a dedicated mail connector that will “instruct” Exchange Online to address “smart host” meaning the “destination mail server that shares the domain with Exchange Online.
Multiple public domain infrastructure
In a scenario in which the organization registered a couple of public domain names at Office 365, we will need to change the default setting of Authoritative to the internal relay to each of the domain separately.
The “workaround” of using “catch all mailbox in the Exchange Online environment
As mentioned, Exchange Online is not supported by default the feature of “catch all mailbox“.
To implement this option, we will need to “Bend” the Exchange Online infrastructure by “telling” Exchange Online that he is not Authoritative for our specific domain name.
In a scenario in which “source recipient” address Exchange Online and ask to deliver an email message to non-existing Exchange Online recipient, Exchange Online will need to “forward” the E-mail message to the other mail infrastructure but, the “trick” is that we don’t really have the other mail infrastructure.
Instead, the E-mail message will be “forwarded” or delved to a specific mailbox that will be set as the “catch all mailbox“.
It’s very important to declare that this “tweak” cannot be used or implemented in an Exchange hybrid environment but, only on a “cloud only” environment, meaning an environment in which the organization mail infrastructure is hosted only by Exchange Online and no other mail infrastructure is involved.
When we implement the “catch all mailbox” workaround that we will review in the next sections, each time that Exchange Online will get a request for delivering E-mail message to non-existing Exchange Online recipient, instead of using the mechanism in which Exchange Online will look for the MX record of the other mail infrastructure or address “Smart host”, Exchange Online will use a transport rule (that we will create later on) that “enforce” Exchange Online to deliver the E-mail message to the designated catch all mailbox.
Catch all mailbox | Specific scenario description
The characters of our scenario are as follows:
Our public domain name who was registered at Exchange Online is – o365pilot.com
We would like to create a “catch all mailbox” which will be used as a “container” for all the E-mail message that will be sent to non-existing Exchange Online recipients.
In our specific scenario, we will designate “bob mailbox” as the catch all mailbox. In a real-life scenario, we can choose any other type of mailbox that will serve as a catch all mailbox.
For example – shared mailbox, Public folder mailbox and so on.
In the following diagram, we can see the concept of the catch all mailbox
Every “legitimate E-mail message” that will be sent to Bob (Bob@o365pilot.com ) will reach the bob’s mailbox and in addition, every E-mail message that includes an E-mail address on non-existing Exchange Online recipient will be also sent to Bob mailbox.
Step 1 – create a dynamic distribution group that will include all Office 365 recipients
In this step, we will create a dynamic distribution group that will include all the existing organization recipients.
The purpose of this dynamic distribution group is – to define the logic of “negate” in the Exchange Online transport rule that will be created later on.
We will need to define a “logic sentence” that says something like:
Every time, that “source recipient” sends E-mail message that includes E-mail address other than the “will know” E-mail address (the E-mail address of the dynamic distribution group that represent all the existing organization recipient), “do something”!
The “action” will be – delivering the E-mail message to the catch all mailbox.
In our specific scenario, we will create a new dynamic distribution group and name it –
All of Office 365 recipients.
- Login to Exchange Online admin center
- On the left bar menu, choose the recipients menu
- On the top bar menu, choose the groups menu
- Click on the plus sign and choose the menu – Dynamic distribution group
In our specific scenario, we will use the display name – All of Office 365 recipients, and the alias will be – AllOffice365recipients@o365pilot.com
When we create a Dynamic distribution group, the Dynamic group is based on a specific filter which uses for “gather” the group members.
In our scenario, we will choose – All recipient type.
This option will include all the existing Exchange Online recipients.
Step 2 – Convert Office 365 domain names to the internal relay instead of Authoritative
In this phase, will we change the setting of the o365pilot.com domain setting from – Authoritative to internal relay.
- Login to Exchange Online admin center
- On the left bar menu, choose the mail flow menu
- On the top bar menu, choose the accepted domain menu
- Choose the specific domain name that you would like to update his settings. In our scenario, we choose the domain name – o365pilot.com and choose the pencil icon for editing the domain settings.
Choose the option – Internal Relay
In the following screenshot, we can see a warning message that informs us that in case that we change the domain setting to Internal Relay we will need to “instruct” Exchange Online how to “find” the additional mail infrastructure which will “share with us” the domain name.
In our scenario, we will not need to address “other mail infrastructure” but instead, use an Exchange Online transport rule that will redirect E-mail message to catch all mailbox.
In the following screenshot, we can see the result – the domain type was changed to Internal Relay
Recap and next article
In the next article – Part 2 – Catch mailbox in Office 365, we will review the rest of the process in which we will create a new transport rule that will “use” the Dynamic distribution group that we have created.
Additional reading
We really want to know what you think about the article
The post Configuring Catch all Mailbox in Office 365 | Part 1#2 appeared first on o365info.com.