As you may know, NSGs are a vital component of Azure’s security architecture that allow you to filter network traffic based on source and destination IP addresses, ports, and protocols. However, NSGs do not support filtering based on URLs or FQDNs. Although NSGs do offer Service Tags, the Defender for Endpoint Service Tag is not yet available for productions and does not cover all of the Microsoft Defender for Endpoint (MDE) – As of today (May 1st 2023). As shown below. Azure service tags overview | Microsoft Learn

Therefore, I suggest two potential workarounds to implement a solution to allow MDE to connect to the cloud service.

1. Configure device proxy and Internet connectivity settings: This workaround requires you to configure device proxy and Internet connectivity settings on the client devices. You can find the detailed steps to configure this on Configure device proxy and Internet connection settings | Microsoft Learn
2. Replace NSG with Azure Firewall: Azure Firewall is an advanced security solution that offers FQDN filtering in network rules. It replaces the basic NSG and offers more robust security features. You can find the detailed steps to implement Azure Firewall on Azure Firewall FQDN filtering in network rules | Microsoft Learn

The MDE URLs are specified as required for MDE in the mde-urls.xlsx (live.com) .

Have you ever received a lot of email in your Exchange service that are tagged as “spoofed DMARC”, and is your SOC concern about the increase of spam and phishing attacks? Well, let me try to clarify by sharing some details on what how Microsoft 365 handles inbound email that fails DMARC. If the DMARC policy of the sending server is p=reject, Exchange Online Protection (EOP) marks the message as spoof instead of rejecting it. In other words, for inbound email, Microsoft 365 treats p=reject and p=quarantine the same way. Admins can define the action to take on messages classified as spoof within the anti-phishing policy.

Microsoft 365 is configured like this because some legitimate email may fail DMARC. For example, a message might fail DMARC if it’s sent to a mailing list that then relays the message to all list participants. If Microsoft 365 rejected these messages, people could lose legitimate email and have no way to retrieve it. Instead, these messages will still fail DMARC but they’ll be marked as spam and not rejected. If desired, users can still get these messages in their inbox through these methods:

• Users add safe senders individually by using their email client.
• Admins can use the spoof intelligence insight or the Tenant Allow/Block List to allow messages from the spoofed sender.
• Admins create an Exchange mail flow rule (also known as a transport rule) for all users that allows messages for those particular senders.

An allowed spoofed sender in the spoof intelligence insight or a blocked spoofed sender that you manually changed to Allow to spoof only allows messages from the combination of the spoofed domain and the sending infrastructure. It does not allow email from the spoofed domain from any source, nor does it allow email from the sending infrastructure for any domain.  For example, the following spoofed sender is allowed to spoof: Domain: gmail.com and Infrastructure: tms.mx.com

Only email from that domain/sending infrastructure pair will be allowed to spoof. Other senders attempting to spoof gmail.com aren’t automatically allowed. Messages from senders in other domains that originate from tms.mx.com are still checked by spoof intelligence, and might be blocked.

Some additional links for your to review

Spoof intelligence insight – Office 365 | Microsoft Learn

Use DMARC to validate email, setup steps – Office 365 | Microsoft Learn