12-28-2018 12:21 AM
12-28-2018 12:21 AM
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 firstname.lastname@example.org. 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.
12-28-2018 11:24 AM
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.
02-04-2020 07:26 AM
We just migrated to Teams and our notification emails are also quarantined by Office 365...
03-25-2020 09:35 AM
03-26-2020 08:59 AM
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.
04-20-2020 05:45 PM
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
05-19-2020 07:03 AM
05-21-2020 09:27 AM - edited 05-21-2020 09:30 AM
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.
06-04-2020 03:50 AM
We experienced this issue as well, created a support case at Microsoft and where advised to exclude email@example.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.
07-09-2020 04:27 AM
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?
07-09-2020 08:54 AM
@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 (firstname.lastname@example.org) is impersonating the actual sender.
The recommended solution for the short term is to add "email@example.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 "firstname.lastname@example.org" 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.