Forum Discussion
Jack_Chen1780
Sep 23, 2022Brass Contributor
Weird behavior of Exchange Online for none-existing email address
I am see a weird behavior of Exchange Online for none-existing email address, wondering if anyone can explain it.
I am setting up a Fortimail Cloud service ( third party email protection service ) to Exchange Online, but noticed one function "Recipient address Verification" (using RCPT method) doesn't work as I thought. I did some troubleshooting, my understanding is Fortimail will send a "RCPT TO:" to Exchange Online to verify if the recipient is a valid email.
I did traffic capture from Fortimail to Exchange Online :
Somehow Exchange Online replied with "250 2.1.5" for the fake email !
But when I do a manual test from a random azure machine, with all the same input, same recipient, Exchange Online return "550 5.4.1" :
Now I am really confused why this is happenning.
I tested with a second test M365 tenant with a different email domain and it behave same way, the test domain 's MX and TXT SPF record doesn't have any reference to Fortimail Cloud, so there shouldn't be any reason it's treated differently.
- Jack_Chen1780 - This behavior is expected. The DBEB functionality can reject on either RCPT TO or on "End Of Data". The latter happens when the sending IP is shared between multiple tenants, and in order for EOP to correctly attribute to the recipient tenant, we need to traverse the headers which are available only after EoD.
- Jack_Chen1780Brass ContributorI am wondering if there are anyone from Exchange Online support team can verify this behavior ?
I opened support ticket with Fortinet and Microsoft, Fortinet support 's attitude is "not my problem, ask Microsoft"; The Microsoft support working on my case doesn't seem understand the issue so far.
Now I see other customers are having same problem:
https://www.reddit.com/r/fortinet/comments/un12cw/fortimail_recipient_verification_using_rcpt/
"I’ve come across an interesting issue that support from either side has been unable to solve so far"
This doesn't look promising.
The result is Fortimail will count any bogus email as a valid user account and consume a user license.- Arindam_Thokder
Microsoft
It can very well be an issue with attribution. Jack_Chen1780 - If you share the ticket number with e, I can have a look internally.
- Jack_Chen1780Brass ContributorThanks Arindam, I have PMed you with the ticket number, let me know if you need any other information.
Arindam_Thokder might be able to help, if support gets you nowhere.
- MS is likely handling messages coming from Fortimail differently. The second scenario is what you'd expect to happen (or a 550 5.7.64 TenantAttribution; Relay Access Denied depending on whether the domain is known to EOP and how its configured). In any case, best open a support request.
- Jack_Chen1780Brass Contributor
Indeed, It looks like a issue with Exchange Online Canada service, it might have some special rules for Fortimail Cloud.
I searched Microsoft Partners and found two partners using Exchange Online and does send 550 for none-existing users :
Sherweb.com : MX sherweb-com.mail.protection.outlook.com, Canada.
carahsoft.com: MX carahsoft.mail.protection.outlook.com. US.Test result from Fortimail Cloud :
Opened a ticket with Fortinet, they are investigating, hopefully they can work it out with Microsoft.