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

If you are deploying Microsoft Defender for Cloud (MDfC) on your servers (previously known as Microsoft Defender for Servers) you are probably using the built-in vulnerability assessment tool as described in the Integrated Qualys vulnerability scanner for virtual machines article. This Qualys tool is built-in into Defender for Cloud and doesn’t require any external licenses. However, if your company is already utilizing Qualys as your primary threat and vulnerability scanner, you should be able to leverage the BYOL solution, as this will provide Qualys Vulnerability Assessment in both your Qualys subscription and in the Azure Security Center. The Azure Security Center handles the deployment of Qualys Cloud Agent for this solution to work. Agents installed via other methods (extensions, baked into images, or deployed manually) will not report their findings into the associated ASC.

Some considerations to review before comparing the options.

• Cost: The built-in scanner is included with MDfC has no added cost in Azure Defender for Cloud. BYOL option requires maintaining a Qualys license.
• Coverage: The built-in scanner supports Azure ARC machines, while the Qualys BYOL option will not cover on-prem and multi cloud machines. The BYOL option only works with Azure Virtual Machines.
• Deployment: The built-in scanner has more deployment options through API making it almost automatically deployment for Azure Virtual Machines (see official docs)
• Vulnerability findings: The built-in scanner findings in Azure Security Center are richer with data, comparing to BYOL findings in ASC, whereas BYOL findings are also reflected in the Qualys platform. For instance, while you will find the same CVE and Security Recommendations, the metadata passed to ASC will not be as complete as using the build-in agent.