MS365, Teams, and not using MS for email. Invite emails inside the org are missing
Posted by Kurgan_IT@reddit | sysadmin | View on Reddit | 18 comments
I'm a Linux admin, but I'm currently trying to find a solution to a MS365 issue.
I have a MS365 tenant that we use just for Teams. Our email is hosted in-house on our own Linux email server. We have set up our 365 config so that the email addresses that are used in Teams are the ones in our own domain (not onmicrosoft.com).
When someone creates a Teams invitation, emails to external domains are fine. They get delivered (they are generated and delivered by MS, not by us, and this causes an issue with SPF, but this is a different issue).
But emails that should be delivered inside our own domain (emails that are sent to coworkers instead of external people) simply get lost. No errors, no nothing. If they are actually created, they don't get to our server (which is the MX for our domain) and don't appear anywhere.
So I googled and found that you should probably make a filter on 365 to explicitly deliver these to our mail server. The idea is this: In O365, Exchange Admin Center, Mail Flow, Create an Outbound Connector pointing to local mx, Then Create a Transport Rule for all messages Where the Recipient is your SMTP Domain, Forward the message to the Outbound Connector.
I did it. It still does not work. I am lost. Any ideas?
Master-IT-All@reddit
This is two things. Teams requires an Exchange mailbox, so all these users have mailboxes. Exchange Online believes it is authoritative for the domain so it will never forward outside what it believes it owns. Moving to Internal Relay from Authoritative won't work in this situation as the mailbox will exist in Exchange Online, so it will never think to forward.
To work around this issue you should purchase or use a domain that isn't in 365 as the target for these, and then use forwarding via contact objects.
So get blakghalkak.com for a domain
Add these email addresses to your mailboxes in your on prem mail server
Create a contact object for each user in Exchange Online, using that email address
On the mailbox object for each user that is created (requirement for Teams!) setup forwarding. Can likely do a transport rule to do a catch everyone.
Now when a person invites internal it should go to the Exchange Online mailbox address, see that it should forward, and then deliver it to your SMTP host internally by way of MX records.
bluecollarbiker@reddit
In what way does Teams require Exchange?
Kurgan_IT@reddit (OP)
Ok, I don't know how to make most of the configs on MS365 (I'm totally ignorant about MS365) but the could work. I'll get to study this solution.
Frothyleet@reddit
You don't even need a new domain, just use a subdomain.
su_A_ve@reddit
Any reason why not moving email to the cloud? Gosh I remember the day running amavis with a dual smtp setup, feeding a local zimbra.. having email servers exposed it was a constant battle with spam..
DiligentPhotographer@reddit
For non Americans this is a big issue these days. We deal with some large EU customers and actually migrated them back to on-premises email.
Kurgan_IT@reddit (OP)
And this is very good thing to do. Business reliance on the only 3 cloud service providers in the world is not good at all.
ZeroOne010101@reddit
yuup, CLOUD act and GDPR means reallydont play together
Kurgan_IT@reddit (OP)
We have 100 mailboxes, 6 TB of storage, and a local server plus backups costs far less than any cloud solution plus cloud backup. Also my server actually has a simple and nicely working antispam system made of greylisting and RBL checks. I know that everyone is on MS these days, but I'm fine with my own server. Less expenses, less lockin, less pricing surprises, less issues overall.
And we only have about 6 365 accounts, that we use only for Teams because we are more or less forced to use Teams because everyone uses Teams. But if it was for us, we would have avoided it completely.
itskdog@reddit
Teams, Zoom, WebEx, and Meet all support guest joins to meetings. We're an M365 org, and don't have Zoom logins or Google Workspace but people can join meetings without an account.
Kurgan_IT@reddit (OP)
I know, but this particular group has requested that we buy them Teams licenses. We work with very picky customers that only allow Teams, and while we can join teams meetings created from other (licensed) users, we cannot create a meeting if we are unlicensed.
It's basically a political thing, and it's how MS is strangling the market and imposing its dominance:
Frothyleet@reddit
Is this an SPF issue that is not solved by having include:spf.protection.outlook.com in your SPF record?
Exchange does not look up MX records if it is authoritative for the recipient domain, which it believes it is based on your description.
What does message trace say is happening to your emails? Basic rule of SMTP troubleshooting, regardless of MTA - look at the logs.
This is probably a solvable problem, but given that Teams is an Exchange-reliant product, you'd save yourself some headaches by removing your primary domain from M365 and replacing it with a subdomain (like teams.yourdomain.com) or another TLD or whatever.
Kurgan_IT@reddit (OP)
For SPF: yes, I'd just prefer not to state that every MS server can send email on our behalf. I'd expect at least a way to restrict this to a specific zone, a range of addresses, not the whole MS365 systems in the whole world.
For the rest: Yes, reading the logs is the right thing to do... now if only I had an inkling on how to read logs in MS365, or where to find them...
And about setting a specific subdomain like teams.ourdomain.tld this might work, but maybe not as intended. I mean, we wanted to use our domain so when we sent an invitation to external people, it came from out "everyday" email addresses, did not generate confusion, did not come from an address that no one actually reads. I'll have to think about this and see how it actually fits.
St0nywall@reddit
in your tenant, setup a send connector to use your linux box as the outgoing smtp relay for that specific domain.
Kurgan_IT@reddit (OP)
I made a filter like this: Is this the idea? Or did I get it wrong?
In O365, Exchange Admin Center, Mail Flow, Create an Outbound Connector pointing to local mx, Then Create a Transport Rule for all messages Where the Recipient is your SMTP Domain, Forward the message to the Outbound Connector.
St0nywall@reddit
No worries, I Googled it for you and let AI write out the response.
To set up a Microsoft 365 tenant to route all outbound email through an external Linux mail server (e.g., Postfix), you must configure an outbound connector in the Exchange Admin Center (EAC). This allows Microsoft 365 to act as the sender while offloading delivery to your Linux "Smarthost".
1. Configure the Microsoft 365 Outbound Connector
Access the EAC: Log in to the Microsoft 365 Admin Center, go to Admin centers > Exchange, then navigate to Mail flow > Connectors.
Add a New Connector: Click + Add a connector.
Connection from: Select Office 365.
Connection to: Select Your organization's email server.
Define Routing: Name the connector and choose when to use it. To route all email, select Only when email messages are sent to these domains and enter an asterisk (*).
Set the Smarthost: Enter the FQDN or static IP address of your Linux mail server.
Security: Use Transport Layer Security (TLS). You can choose to verify the server using its CA-signed certificate or skip certificate validation if you are using IP-based authentication.
2. Configure the Linux Mail Server (Postfix)
Open Firewall Ports: Ensure your Linux server allows incoming traffic on Port 25 (SMTP) or Port 587 (Submission) from Microsoft 365 IP address ranges.
Trust the Tenant IP: In your Postfix main.cf, add the Microsoft 365 IP ranges to the mynetworks parameter to allow it to relay without a password.
Set Domain Identity: Ensure myhostname and mydomain in /etc/postfix/main.cf match the domain you are hosting.
3. Critical DNS and Security Updates
SPF Records: Update your domain's SPF record at your registrar to include both Microsoft 365 and your Linux server's IP (e.g., v=spf1 include:spf.protection.outlook.com ip4:YOUR_LINUX_IP -all).
DKIM/DMARC: Configure DKIM signing on your Linux server rather than in Microsoft 365, as the Linux server is the final outbound hop.
Connector Validation: In the EAC, use the Validate tool to send a test email to ensure the connection to your Linux server is successful.
Civil_Inspection579@reddit
this sounds like internal routing inside microsoft rather than actual smtp delivery. if those users exist in your tenant, exchange will try to deliver internally and never hit your mx. you might need to set them as external contacts or disable internal resolution for that domain so it forces outbound routing
Kurgan_IT@reddit (OP)
Yes, this is what I suppose is happening. But I thought that setting up an outbound connector as I stated should have been working, at least in my way of thinking, that is probably not how MS thinks.