Teams email notifications quarantined as phish

Highlighted
Occasional Contributor

We subscribe to Office 365 and use both Teams and Outlook/Exchange. Some email notifications from Teams (e.g. when message is posted in a Channel) get quarantined due to phishing suspicion. These are emails sent by noreply@email.teams.microsoft.com. I checked our Anti-phishing policy (from Security & Compliance dashboard) and I can't see anything that would cause Teams notification to be quarantined.

 

Appreciate if anybody can help.

10 Replies
Highlighted

Probably a case of a false-positive, but you need to check the headers and message trace to get additional info. Report the messages to Microsoft, so they adjust the filters.

Highlighted

@Andre Siregar 

 

We just migrated to Teams and our notification emails are also quarantined by Office 365...

Highlighted

@Andre Siregar 

 

We just started using Teams more heavily, and when researching a different issue, i also noticed that all emails from noreply@email.teams.microsoft.com have been being quarantined the whole time.  Seem odd that Microsoft would not have a fix for this.

Highlighted

On or about March 19'th, There was some sort of issue on some of the servers sending the mails.  I had to open a ticket with MS to have them make changes on their side. Evidently there was some problem with DMARC or DKIM in their DNS or servers that caused missing info in the e-mail headers. We had many mails being rejected from others when our users had forwarding turned on.

Highlighted

We are experiencing this issue too in our tenant for a couple weeks now. Support said issue should be resolved after they update our tenant to new code, well that was 2 weeks ago. Hope they fix this soon frustrating when you have users trying to adopt new technology and be foster more collaboration but the tool they are trying to use fails to deliver messages that users have not clue weren't delivered. @Forrest Hoffman 

Highlighted
This is still happening to us. Even though Microsoft advised to not allow well known domains as trusted Senders, I may need to add this email.teams.microsoft.com so the notifications do not get hung in Quarantine.
Highlighted

This is still a huge issue. I'm seeing hundreds of Teams notifications every business day route to Junk or Quarantine going back as far as I can in the reports (mid March). No update from Microsoft. I'll open a case with Support and see if I can get anywhere on this.

Highlighted

We experienced this issue as well, created a support case at Microsoft and where advised to exclude noreply@email.teams.microsoft.com from the ATP anti-phish policy. 

 

To be honest I don't think it's a real solution, but a temporary fix -  Microsoft should do better on this subject. 

 

/Kenneth

Highlighted

Whitelisting that email address and the domain does not help, in our case mails with voice messages still go to Quarantine! 

 

Anybody any other idea?

Highlighted

@stefanbeyerffmI had a case with MS Support open through the beginning of June 2020. I managed to get the issue escalated to the Program Manager for ATP. Took quite a bit of pushing on my part. When the case was taken over by a T3 engineer with a communications channel to the Product Group, they then had the ability to bring the PM in to the discussion.

Here is the note I received from the PM :

“Messages are being blocked for User Impersonation.  This is a known but considered working 'by design' from an AntiSpam team perspective.  The AntiSpam team is working with the 'Teams' team to try to improve this experience ( teams mails like those attached should be marked as intra-org and hence bypass the impersonation stack entirely) but there is currently no ETA.  The UIMP detection is to be expected and is caused by MailboxIntelligenceProtection because the Teams sender (noreply@email.teams.microsoft.com) is impersonating the actual sender.

 

The recommended solution for the short term is to add "noreply@email.teams.microsoft.com" to the ExcludedSenders property of their AntiPhishPolicy.  This will bypass impersonation calls for this sender only. Spoof, and other antiphish / antispam features will not be affected by doing this.   I would also recommend that perhaps they consider changing their "MailboxIntelligenceProtectionAction" to MoveToJMF in their AntiPhishPolicy- this is the SUGGESTED "standard" setting for this feature  https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/recommended-settings-for....  This way end-users can more easily manage false positives by simply looking in their junk mail folder and moving them out to inbox when it is a false positive.

 

I would NOT recommend they add "noreply@email.teams.microsoft.com" to AllowedSenders in SpamFilterPolicy nor add the sender to allowedsenders in recipients JunkEmailConfiguration as this will bypass other parts of the AntiSpam stack.”

 

For now I'm following this advice. I added this address and the address used for SharePoint notifications as both have the same issue. Hoping to hear in the future this issue has been fixed in a way that allows me to confidently remove this exclusion from our ATP policy.