An integrated threat protection solution designed to detect, investigate, and respond to cyber threats across Microsoft 365 services.
The pattern described matches sender reputation and filtering behavior in Microsoft 365 more than a single configuration fault.
Most relevant factors from the scenario:
- New domain / low sending history New sending sources usually have little or no reputation. Microsoft 365 states that new IPs commonly experience delivery issues until they build a positive reputation, and ramp-up can take a couple of weeks or more depending on volume, list accuracy, and complaint rates.
- Cold outreach increases complaint risk Microsoft 365 identifies junk complaint rate as one of the principal factors that lowers sender reputation and deliverability. Even if the messages are legitimate business outreach, cold leads can still generate spam complaints or low engagement that hurts reputation.
- Authentication is necessary but not sufficient SPF, DKIM, and DMARC should be correct, but Microsoft 365 also evaluates sender reputation, reverse DNS, content, complaint rates, and bulk characteristics. A good result in another provider’s dashboard does not mean Microsoft 365 will make the same decision.
- Conversation replies can still go to Junk If the sender or message is still being classified poorly, even legitimate replies in an existing thread can be filtered.
Actionable next steps:
- Check whether this is bulk classification or spam classification
Review message headers for affected messages and look for the BCL value.
- If BCL is greater than the configured threshold, Microsoft 365 is treating the message as bulk.
- If BCL is below the threshold, check whether the message was identified as spam instead.
- If messages are being treated as bulk, tune the anti-spam policy
In the Microsoft Defender portal, adjust the anti-spam policy:
- Raise the BCL threshold to reduce bulk classification.
- Or change the Bulk complaint level (BCL) met or exceeded action to No action if appropriate.
- If the issue is limited to specific recipients or senders, allow the sender
- Submit the message as a false positive in the Submissions page in the Microsoft Defender portal.
- Create an allow entry in the Tenant Allow/Block List if needed.
- Have recipients add the sender to Safe Senders.
- Do not add entire domains to Safe Senders lists, because that increases risk.
- Verify authentication and DNS again Confirm that SPF, DKIM, and DMARC are correctly configured and that the sending IP has valid reverse DNS (PTR). Microsoft 365 treats unauthenticated mail with higher suspicion.
- Make sure the sending server is not presenting a private/nonroutable IP
Microsoft 365 might reject or distrust mail if the sender advertises itself as a private IP range such as:
-
192.168.0.0/16 -
10.0.0.0/8 -
172.16.0.0to172.31.255.255
-
- If any NDRs are returned, use the exact error If any recipients generate an NDR, follow the instructions in the NDR. For example, if the sending IP is blocked, Microsoft’s delist process is the documented path.
- Reduce reputation damage while recovering Based on the described history, the safest operational change is to stop or sharply reduce cold outreach from this domain and focus on recipients who expect the mail. Complaint rate is a major reputation factor, so continuing broad cold outreach can prolong the problem.
For Outlook.com recipients specifically, Microsoft also notes that new IPs and poor complaint rates affect deliverability, and reputation improves over time with clean sending.