This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(166.4, 44%, 26%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EFC%3C/text%3E%3C/svg%3E)
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.
If the accepted domain in the ExO tenant is set to internal relay then you will see the behavior you describe and the emails wont be rejected during the SMTP conversation, but will later if non-existent:
https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/manage-accepted-domains/manage-accepted-domains
Thanks Andy!
The production and test Exchange Online instance are all configured as Authoritative for the domain used in testing.
The issue is :
if I do the test from any random IP directly to Exchange Online service IP, it shows 550 for fakeuser and 250 for correct user ( expected ).
If I do the test from a Fortimail Cloud instance to same Exchange Online service IP, it always get 250.
It's weird why Exchange Online will treat the Fortimail Cloud IP differently.
Is there an inbound connector setup on the ExO side or any sort of safelisting of the Fortimail IPs setup for that tenant?
no. I haven't setup any inbound connector for Fortimail yet, just want to test the mailflow first. Production instance has Fortimail Cloud's IP in SPF records; The test instance doesn't have any reference to Fortimail Cloud.
After some testing, 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 :
weird!
Tell me about it :-)
@Andy David - MVP , FYI, this behavior is explained in https://techcommunity.microsoft.com/t5/exchange-team-blog/office-365-message-attribution/ba-p/749143
The reason is Fortimail Cloud ( Canada ) 's public IP is configured in one of another EXO Canada tenant's inbound connectors, so EXO Canada is treating the message as "Originating" and it's handled differently than "incoming" message.