We’re currently using a traditional third party email gateway for spam/phishing scans etc, and we’re using that gateway to redirect a few hundred (don’t ask) email addresses to Zendesk and few other places. Now we’re moving to an integrated solution that means having 365 handle incoming emails directly and we’re struggling with the best approach to porting those redirects.
As it stands, with our domains marked as Authoritative, email is bouncing before any mail flow rules are evaluated due to not having existing mailboxes or contacts. I suppose “best practice” is to create contacts or mail users for all of the support addresses we need to use, followed by either mailbox-level forwards or mail flow rules for all of those addresses (or lump them into a group where appropriate). But that way seems like a big pain in the ass to administer.
The other option is to set the domains as Internal Relay, which will allow 365 to skip checking whether an address exists, and then just use mail flow rules to handle the redirections directly, which we can script easily enough. But that way seems unsupported at best, and raises big questions about what happens when someone emails an actual non-existent address.
Googling didn’t come up with much in the way of useful documentation so I asked a couple of AIs and they’ve been similarly inconclusive. Copilot thinks that misdirected email will simply bounce with a “no route found” NDR, and gave me error code 5.4.312 that appears to be made up, while ChatGPT thinks that it’ll result in a mail loop and eventual 5.4.6 error, “routing loop detected”.
ChatGPT’s explanation seems more plausible and its suggestion of using a catch-all rule to either redirect or bounce mis-addressed emails sounds good on the surfacce, but again, I can’t find anything written by actual humans to confirm or deny.
So I come to you, denizens of sysadmin! Is there any suggested or best practice configuration for the redirection of large amounts of email addresses? Is using Internal Relay on what is actually the final hop a supported configuration? Or is the only supported/sane option to use an Authoritative domain along with the additional overhead of mail contacts?
Hugely appreciate any thoughts!
Most 365 mail admin work doesn’t end up touching the routing stuff, domains, or DNS records too often, so I’m by no means an expert. Last year I got rid of the last on-prem exchange servers in our environment. Here are my thoughts anyway, for what its worth.
At my workplace, domain as internal relay was used as part of our hybrid exchange setup, where we still had an on-prem exchange server largely for recipient management (for stuff connected to AD objects and thus mastered on-prem instead of in the cloud) and for a mail relay for internal recipients so that automated emails coming from legacy systems bypassed all filtering. I’m not familiar with other use cases.
Stuff that may not apply (minimize the lift)
I would approach this by using it as an opportunity to raze those hundreds of redirects. Surely the recieving systems have other ways to categorize incoming email than destination address. Stuff like system to system you could probably add shit in the body text and change the filters on the recieving end. So each external system would only have one destination address. That’s ideal world though and probably touches a lot of shit outside your control.
Second thing is that I would look into setting the destination email addresses directly in the sending system. It takes management out of your hands, but why does any of this need to hit your infra in the first place? Again, that’s ideal world and also probably touches shit you don’t control.
Point is, I’d look to minimize how many of these things you actually have to deal with, because they’ll just keep being a problem and a pain in the ass to manage forever otherwise. That’s the real underlying problem, if you can do anything about it.
Stuff that more directly lines up with your ask:
If you can script routing rules you can probably figure out scripting the creation of contact objects in 365, and export of them to csv for verification.
PowerShell is going to be your friend with Exchange Online/365, and most things Microsoft. Exchange Online has a dedicated module (think library if you’re used to terminology for other languages).
You can make a csv with the internal email address, external destination address, internal contact name, display name, and whether or not it’s hidden from the address book (do end users need to send to it?). I’d reccomend using some clear prefix in the internal name to keep them obvious compared to any other contacts not related to this fuckery.
You could use full mailboxes and forwarding rules on each one but that increases complexity significantly.
In PowerShell, you’d connect to exchange, import the csv, then foreach over the csv contents throwing the values from it into New-MailContact.
If you want to be fancy you could wrap New-MailContact in a try/catch to spit failed ones out into an array and export that back to csv at the end for review.
Thanks, yeah, as much as it feels like an overly complicated way of doing things, I think I’m erring towards just biting the bullet and making contacts. Appreciate your detailed reply!