Forum Discussion
Anonymous IP address involving one user
- Aug 18, 2025
hi GodCordial
You’re running into a limitation that a lot of admins discover with Microsoft 365: Conditional Access and anti-spam policies don’t apply to SMTP AUTH (the “basic auth” protocol used by service accounts, apps, devices, etc.). That’s why your connection filter and CA rules don’t block that one IP — SMTP AUTH bypasses most of those controls.
Here’s what you can actually do:
Options to Block / Mitigate
- Use Exchange Online Transport Rules (Mail Flow Rules)
- Go to Exchange Admin Center → Mail flow → Rules.
- Create a new rule:
- Condition: “If the message is received from IP address = x.x.x.x”
- Action: “Reject the message with explanation” or “Delete the message without notifying”
- This works at the transport layer, so it can block delivery from specific IPs.
- Connection Filtering – IP Allow/Deny list (Tenant Allow/Block List)
- In Security & Compliance → Policies → Threat policies → Tenant Allow/Block list
- Under IP addresses, add the attacker’s IP to the Block list.
- Note: For SMTP AUTH login attempts, this won’t always stop the authentication traffic, but it will stop email delivery from that IP.
Best Practice Recommendation
- Migrate away from SMTP AUTH if you can. Microsoft is pushing everyone toward Modern Auth (OAuth 2.0) and Graph API / authenticated SMTP submissions.
- If you must keep it:
- Limit SMTP AUTH usage to only the accounts that truly need it.
- Restrict those accounts by IP at your perimeter firewall.
- Rotate that service account’s password and consider enabling App Passwords with MFA.
Quick Fix for your case:
Since it’s always the same IPv4, the Mail Flow Rule (block sender IP) in Exchange Online is your best shot to stop the actual mail flow from that IP. But the sign-in alerts will still appear, because Microsoft doesn’t let you block authentication attempts from specific IPs at their service edge. To truly stop the login attempts, you’d need to disable SMTP AUTH or enforce app firewall rules on your end.
hi GodCordial
You’re running into a limitation that a lot of admins discover with Microsoft 365: Conditional Access and anti-spam policies don’t apply to SMTP AUTH (the “basic auth” protocol used by service accounts, apps, devices, etc.). That’s why your connection filter and CA rules don’t block that one IP — SMTP AUTH bypasses most of those controls.
Here’s what you can actually do:
Options to Block / Mitigate
- Use Exchange Online Transport Rules (Mail Flow Rules)
- Go to Exchange Admin Center → Mail flow → Rules.
- Create a new rule:
- Condition: “If the message is received from IP address = x.x.x.x”
- Action: “Reject the message with explanation” or “Delete the message without notifying”
- This works at the transport layer, so it can block delivery from specific IPs.
- Connection Filtering – IP Allow/Deny list (Tenant Allow/Block List)
- In Security & Compliance → Policies → Threat policies → Tenant Allow/Block list
- Under IP addresses, add the attacker’s IP to the Block list.
- Note: For SMTP AUTH login attempts, this won’t always stop the authentication traffic, but it will stop email delivery from that IP.
Best Practice Recommendation
- Migrate away from SMTP AUTH if you can. Microsoft is pushing everyone toward Modern Auth (OAuth 2.0) and Graph API / authenticated SMTP submissions.
- If you must keep it:
- Limit SMTP AUTH usage to only the accounts that truly need it.
- Restrict those accounts by IP at your perimeter firewall.
- Rotate that service account’s password and consider enabling App Passwords with MFA.
Quick Fix for your case:
Since it’s always the same IPv4, the Mail Flow Rule (block sender IP) in Exchange Online is your best shot to stop the actual mail flow from that IP. But the sign-in alerts will still appear, because Microsoft doesn’t let you block authentication attempts from specific IPs at their service edge. To truly stop the login attempts, you’d need to disable SMTP AUTH or enforce app firewall rules on your end.
Thx. I think we must do best practice in this case and use OAuth for external smpt use. In the Tenant Allow/Block list under ip addresses you can only use ipv6 - ipv4 addresses are not possible to set