Impersonation Protection: Users to Protect should also be Trusted Senders
Hey all, sort of a weird question here. Teaching my staff about Impersonation Protection, and it's kind of occurred to me that any external sender added to 'Senders to Protect' sort of implicitly should also be a 'Trusted Sender'. Example - we're an MSP, and we want our Help Desk (email address removed for privacy reasons) to be protected from impersonation. Specifically, we want to protect the 'Help Desk' name. So we add email address removed for privacy reasons to Senders to protect. However, we ALSO want to make sure our emails come thru. So we've ALSO had to add email address removed for privacy reasons to Trusted Senders on other tenants. Chats with Copilot have sort of given me an understanding that this is essentially a 'which is more usefuI' scenario. But CoPilot makes things up, and I want some human input. In theory, ANYONE we add to 'trusted senders' we ALSO want protected from Impersonation. Anyone we protect from Impersonation we ALSO want to trust. Copilot says you SHOULDN'T do both. Which is better / more practical?Microsoft Defender EOP
We have been experiencing an issue since last week where we are unable to view the details of quarantined emails. Could you please confirm if this is related to a known backend service issue, or if there are any specific troubleshooting steps we should perform on our end? Any guidance or updates would be greatly appreciated.
No URL Detection in Emails with Extensive %2580 Encoding
Hi Community, I encountered a concerning issue where emails containing URLs with extensive encoding (%2580) completely bypassed all detection and security mechanisms. These encoded URLs weren’t identified as links, which allowed them to evade security scanning. Issue Details: The email contained malicious URLs encoded with %2580. The URLs were not flagged or identified as links, allowing the payload to bypass filters entirely. Questions: Has anyone else encountered similar issues with encoded URLs bypassing detection? What’s the best process to submit this email to Microsoft for analysis and improvements to detection mechanisms, since no URL's were identified? Looking forward to your input and recommendations. Thanks in advance!
capability to detect password protected files to during the email delivery and ZAP process of the e
Does M365 Defender & EOP has capability to detect password protected files to during the email delivery and ZAP process of the email in user mailbox? If yes how we can configure to stop such emails and put them into quarantine and stop the email delivery to end users? I have another follow-up question on this is that if we deploy this Transport rule to quarantine false or parked domains emails like phishing or spam and unwanted emails then how we would filter and allow the legit email domains to send out such files like .PDF, Docs, excel and other password protected files to users mailbox without putting them into Quarantine?How to classify E-Mails with *.html or *.htm attachments as spam?
A tenant is receiving currently an enormous amount of phishing emails with *.html or *.htm attachments. 99% of the e-mail which contain such an attachment are phishing e-mails. What's the best approach to filter out those e-mails? They are using the standard protection threat policies.Fastest workflow to block a phished user?
If a user gets phished, or his credentials get leaked - what's the first thing you do, before you start investigating the issue? A few questions concerning this issue: - Is it enough to block the user in the Office 365 Admin Center? - Should I reset his password, or is blocking the user enough? - If the user is blocked, and he still has an active Exchange Online session, can the blocked user still send e-mails?
