Defanged malicious URLs in SOC security notification emails still classified as High Confidence Phishing by Defender for Office 365

Question

Defanged malicious URLs in SOC security notification emails still classified as High Confidence Phishing by Defender for Office 365

Mohd Irzani Bin Wahid 0

Hi, SOC security notifications may contain threat-intelligence indicators such as malicious domains, URLs and IP addresses.

Throughout my years of using Microsoft email services across different organisations, I have regularly handled similar security notifications. However, this is the first time I have encountered recurring quarantine of such messages in this manner.

As part of normal security practice, potentially malicious indicators are defanged before being included in the email, for example:

example[.]com hxxps://example[.]com

Despite being defanged, some SOC security notification emails are still being classified by Microsoft Defender for Office 365 as High Confidence Phishing and quarantined.

The internal Microsoft 365/email security team has simulated the situation and advised that, even when the email content has been defanged, Microsoft Defender for Office 365 Machine Learning (ML) may still classify the message as phishing because the potential risk associated with the malicious URL remains.

I would like to validate whether this is the expected behaviour of Microsoft Defender for Office 365 and understand the recommended approach from Microsoft for this type of security communication.

A similar concern has also been observed with legitimate threat-intelligence reference links. For example:

https://www.virustotal.com/gui/domain/example[.]com

In this case, the actual destination is virustotal.com, while the potentially malicious domain appears only as part of the URL path for threat-intelligence lookup purposes. However, such references may still contribute to the message being classified as phishing.

The security team has suggested the following workarounds:

Use Plain Text format without embedded hyperlinks.
Remove or mask malicious URLs from the email body and provide the advisory as a PDF attachment.
Use a password-protected PDF where the original hyperlink needs to be retained.

I would appreciate Microsoft’s clarification on the following:

Is it expected behaviour for Defender for Office 365 ML to recognise and evaluate defanged indicators such as example[.]com and consequently classify the email as High Confidence Phishing?
How does Defender evaluate legitimate threat-intelligence URLs where a potentially malicious domain appears only within the URL path, such as a VirusTotal domain-report link?
Are Plain Text, PDF attachments, or password-protected PDF attachments the Microsoft-recommended approach for SOC/security advisories containing potentially malicious indicators?
Is there a Microsoft-supported method to safely include defanged domains, URLs and threat-intelligence references in security notifications without causing recurring High Confidence Phishing classification?
Is there any recommended configuration or best practice for trusted security notification emails containing threat indicators, without broadly bypassing anti-phishing protection?
Have there been any recent changes to Defender for Office 365 ML, URL analysis or phishing-detection behaviour that may explain why this is occurring more frequently now, despite similar security notifications having been sent for many years?

These are often time-sensitive security notifications, and repeated quarantine may delay the delivery of important security information to customers.

I would appreciate Microsoft’s or other SME clarification on whether the observed ML behaviour is expected and any official recommendation or documented best practice for safely distributing defanged threat indicators and threat-intelligence references through Microsoft 365 email.

Thank you.

Chris Hailes 155 Reputation points MVP

2026-09-08T22:55:41.08+00:00

Thanks for the detailed examples. Before concluding whether this is expected Defender for Office 365 behaviour, could you clarify the message’s origin and delivery path?

Is the notification generated by a mailbox or application in the same Microsoft 365 tenant?

Or is it sent by an external SOC platform, security provider, or partner?

If it is external, is it delivered directly to Exchange Online, or routed through a connector or relay service?

If possible, please also provide redacted message-header or message-trace details, including the Authentication-Results values for SPF, DKIM, and DMARC, the sender and return-path domains, and the specific anti-phishing or URL verdict shown in Explorer or quarantine.

These details matter because the supported remediations differ depending on the message’s authentication and delivery path. They can also help distinguish a verdict based on sender authentication or reputation from one based on URL, attachment, or message-content analysis. I would avoid broadly allowlisting the sender or domain until that distinction is confirmed, as doing so could weaken anti-phishing protection.

1 answer

Your answer

Chris Hailes 155 Reputation points MVP

2026-09-08T22:55:41.08+00:00

Thanks for the detailed examples. Before concluding whether this is expected Defender for Office 365 behaviour, could you clarify the message’s origin and delivery path?

Is the notification generated by a mailbox or application in the same Microsoft 365 tenant?

Or is it sent by an external SOC platform, security provider, or partner?

If it is external, is it delivered directly to Exchange Online, or routed through a connector or relay service?

If possible, please also provide redacted message-header or message-trace details, including the Authentication-Results values for SPF, DKIM, and DMARC, the sender and return-path domains, and the specific anti-phishing or URL verdict shown in Explorer or quarantine.

These details matter because the supported remediations differ depending on the message’s authentication and delivery path. They can also help distinguish a verdict based on sender authentication or reputation from one based on URL, attachment, or message-content analysis. I would avoid broadly allowlisting the sender or domain until that distinction is confirmed, as doing so could weaken anti-phishing protection.

Answer 1

Thank you for the clarification and for explaining why the message authentication and delivery path are relevant.

Just to clarify my position, I am raising this from the perspective of an SOC team using an email platform managed by a separate email security/administration team. I am not an administrator of the Microsoft 365 environment, so I do not have direct access to Defender Explorer, message trace, connector configuration, or the complete authentication information requested.

I have raised the issue internally; however, the detailed backend investigation information available to me remains limited.

For this reason, I would like to focus on one aspect that should be independently reproducible and publicly testable: legitimate VirusTotal URLs containing a malicious domain as part of the URL path.

For example:

https://www.virustotal.com/gui/domain/example[.]com

In this case, the actual destination is virustotal.com, while the potentially malicious domain appears only as part of the URL path for threat-intelligence lookup purposes.

The email security team has advised, based on its simulation, that Microsoft Defender for Office 365 Machine Learning may still recognise the malicious indicator within the URL and classify the message as phishing, even though the destination itself is VirusTotal.

This is the specific behaviour I would like to validate.

Is Defender for Office 365 expected to analyse the domain appearing within a VirusTotal URL path and use that indicator as part of the phishing verdict?

If so, is there a Microsoft-recommended way for SOC/security teams to include legitimate VirusTotal references in security notifications without those references contributing to a High Confidence Phishing classification?

I understand that sender authentication, reputation and delivery path can also influence the overall verdict. However, the VirusTotal example may provide a more generic scenario that can be tested independently without relying on access to our specific Microsoft 365 environment.

The clarification would also help us determine the appropriate next step internally whether this behaviour should be pursued further with Microsoft Support as a product-level detection issue, or whether there is a tenant-side configuration, policy, or mail-flow setting that should be reviewed and adjusted by the Microsoft 365 administration team.

Any clarification on how Defender handles this type of threat-intelligence URL, or any Microsoft-recommended configuration or best practice for this scenario, would be greatly appreciated.

Thank you again for your guidance.