Automate Email reported by user as malware or phish

Agreed that it would be nice if the Defender for Office API offered the possibility to trigger an AIR investigation based on a Network Message ID parameter. This would be infinitely useful in Sentinel Playbooks as an extension of Analytics Rules that detect suspicious email delivery.

One problem you will have is that spam is something of a spectrum, from cheeky advertising from companies your organisation has an active, ongoing relationship with through to highly suspect offers for products and services that may not even be lawful in your jurisdiction. In the middle there are items that one recipient will say is spam and another will say is useful. Now spare a thought for the EOP team who have to reach a balance for the entire EXO customer base. Also bear in mind the action you are taking with spam verdicts, because up beyond the unlawful end of this spectrum you will find phishing and malware droppers that are not detected as phishes or malware, but do fall foul of the anti-spam filter.

1. Do you have Outlook Report Message set up and running?
Where it is a subjective decision as to whether an item is spam or not, this lets your users manage the decision themselves. I take a SecOps copy but I don't bother to analyse every sighting; I just look to see if the same domain names or IP ranges are frequently appearing.

2. Have you tuned your SCL and BCL thresholds?
You probably have, but if you have particular users who are vehement that you are not doing enough / are interfering too much then you can put them in a group with a separate AS policy. A separate AS policy also allows you to experiment with some of the Advanced Spam Filter features. When changing a policy setting, don't forget to think of the action so if the change goes horribly wrong you will be able to recover the situation. As always, test if possible.

3. Does your global address list have a lot of unnecessary legacy aliases?
If your organisation has changed name or been involved in various mergers or acquisitions then it is quite probable that some or all of your users have a number of aliases. Old aliases are often complete spam magnets. Try a 90-day extended summary to see how much rubbish an old domain is attracting compared to the genuine mail it receives, and if you cannot move at the organisation level then offer to relieve the pain of individuals by wiping out just their aliases. Don't release the domain itself! Old domains are purchased by organisations that will publish a new MX and wildcard everything into a harvesting system. It's for honeypot analysis, honestly!

4. Do you trust your users to root around their Junk folders?
Bearing in mind the danger of more hazardous material appearing in Junk, you can take a much more aggressive stance on some of the bulk email service providers and use a mail flow rule to apply a higher SCL to mail from their IP ranges or any item that bears a distinctive header. This generally needs testing with a non-intrusive action first, as the genuine items will only be evident if you go looking for them. The KQL evaluate ipv4_lookup function will allow you to access IP ranges, but for headers you have no alternative but to run an MFR in test for a few weeks to see what it catches.

You can configure spam setting by configuring in office365 portal
https://security.microsoft.com/antispam or https://security.microsoft.com/
refer this URL for more details https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/anti-spam-policies-configure?view=o365-worldwide