Office 365: How to create a catchall wildcard address in Office 365


Catchall eMails in Office 365

Catchall / wildcard email addresses, e.g. <anything>@yourdomain.com isn’t really a great way to deal with email as it means the email server is more prone to spam and high workloads.  As such, Microsoft do not support catch-alls on hosted Exchange or Office 365 and indeed their responses to questions are – “No – you cannot set up a catchall email address”, and in truth it isn’t best practice.

There may be a legitimate need for a catch all, for me for instance, I use unique email addresses for each company – like amazon@mydomain.com or Microsoft@mydomain.com – so I have hundreds of addresses I want to receive and just don’t know what they all are.

EDIT:  I’ve just been informed by a Mr Deck from Oz that MS now have their own version of this post created a year later (copy cats!) – so feel free to use that as well http://social.technet.microsoft.com/wiki/contents/articles/30462.catch-all-mailbox-office365.aspx

How to set up catch all email address on office 365

In order to do this you need to use a transport rule which imposes a couple of restrictions:-

  • This only works on Office 365 Medium business and Enterprise plans and the new “Business” rane.  It will NOT work on the Small Business plan as that does not support transport rules.
  • This only works if all your mailboxes are on Office 365 – it will not work in split scenarios, e.g. Hybrid or mid-staged-migration
  • It needs the MX records to point to Office 365

It is easy to implement, and easy to disable later.

Theory

The theory is simple – tell Office 365 it is not authoritative for your domain, so it thinks mailboxes exist on other systems. In this way, Office 365 will accept all emails, and if the mailbox does not exist it will forward it (via MX or transport rule) to the next system where the mailbox resides.  But, we implement a rule which intercepts the emails before they are sent on, and forwards it to a known email address on office 365.  Simple!  But be careful to do it correctly.

Disclaimer

I have tested this on my own Office 365 system – your system may differ or have different settings that prevent this working.  So test, test and test again and I hope this article helps but it does not guarantee it will for you!

Part 1 – Tell Office 365 it is not authoritative

domain2

  • Log onto Office 365 admin portal
  • Go to Admin–>Exchange
  • (1) Click “Mail Flow” icon
  • (2) Click “Accepted Domains”
  • (3) Highlight your vanity domain and then click the pen (edit) button
  • (4) Change the pop-up from “Authoritative” to “Internal Relay”
  • (5) Click SAVE
  • Ignore any warning about needing to set up transport rules.

At this point, any message sent to <anyaddres>@mydomain.com will be received, then bounced back to the MX records and you will probably get a mail loop, so now need to set up rule…

Part 2 – Set up divert rule

You need to have a mailbox, shared or normal which is going to receive the catchall mail.  Hopefully you have this set up already 🙂 You can also use a “group” if you require the catch-all going to multiple people (not recommended, but you can use a group and just put a single target person in it)

You also need to create a group (e.g. “All”)  that directly contains all mailboxes and groups which you do NOT want diverted.  Add users/groups individually to this group (do not nest groups).  This group MUST contain the catch-all mailbox or catch-all group.

rule2

 

  • Log onto Office 365 admin portal
  • Go to Admin–>Exchange
  • (1) Click “Mail Flow” icon
  • (2) Click “Rules”
  • (3) Click the “+” icon, then “Create a new rule”
  • As soon as the new rule box appears, click “More Options…” link towards the bottom of the page
  • (4) Give rule a name, e.g. Catchal
  • (5) Change the “apply this rule if…” to “The Sender is…”–>”Internal/External”–>”Outside this organisation”
  • (6) Change the “do the following…” to “Redirect the message to…”–>”These recipients”–> then select your catch-all mailbox
  • (7) *OPTIONAL*  Click “Add Action” and then “Modify the message properties”–>”Set a message header”, then set the header to “X-Catchall-Rule” and value to “Yes”
  • (8) Under “Except if”, Click “Add action” and then “If Recipient…”–>”Is this person”–>and select the “all” Group which contains all exclusions (note – image above incorrectly shows an exclusion of CatchAllMailbox – this should be the “All” group which contains all users/groups INCLUDING the Catchall mailbox/group that you don’t want diverted)
  • Save

Wait a couple of minutes for rule to apply, and then test.

Part 3 – Testing

  • You can send an email to validaddress@mydomain.com and it should still get through and be delivered unaffected (as recipient exists)
  • Send email to <anyrandomaddress@mydomain.com> and it should be delivered to the catch-all email address you specified.  If you look at the header of the delivered email, (and you did optional step 7 above), you can see it was the rule that was responsible.

header

That’s it – I’ve not found any downsides to this, so bemused why Microsoft say it is not available functionality…. Apart from the extra email load on their servers of course!

 

(Note:  Thanks to information on Forums and LinkedIn which suggested this was achievable, as I’d have given up had I believed most googled answers!  Hope this is the clearest how-to guide available)

Update :  Thanks to Katie for highlighting a mistake in this document which I hope is now updated – thanks!

Update 18 July 2015: eMail from Chris Ingeholm highlighting a possible issue and enhancement to this solute, thanks Chris

Hi there,

We implemented the solution you suggested in the following article here and I found it to cause a routing issue with forwarding external calendar invites to internal or external users. Honestly, I am not well read into how the underlying forwarding mechanism works for calendar invites on Exchange. I suspect that it retains the sender properties of the original invite when the message is forward causing it to trip the catch-all rule.

We worked around it by adding an exception for email type “calendaring,” which is less than perfect since it allows any calendar invite to slip through the rule (now a catch-most-things instead of a catch-all!).

If I am completely off-base here, please just let me know, however I wanted to pass along the info in case you ever run into something similar. Thank you for posting the article, it really helped me out!