We block Authentication by Country ( Manage -> Settings -> General ) -- set to block all countries except where your clients would login from. For ours, we block everything except our US and a couple EU countries.  

In the case of your situation - sometimes you can block more than just the /24 -- like this IP from your list above:

Blocking the /14 would get you 260k blocked IPs instead of 255

We utilize a 3rd party application that allows us to block entire ASNs at our edge - and that makes a world of difference - plus as their IP ranges change, our rules update.

Does blocking authentication by country block webmail logins as well?

As far as we can tell --

What should I see in the smtp log? I see no difference after setting up block all except US, MX and CA.

In the SMTP log they'll just show as failed logins.  On our end, we use 3rd party to catch these log hits and block the IP at our edge.

The downside is they are persistent - and if they somehow have "leaked credentials" they found - or they figure out a password - the next thing they'll do is try from various countries until they get in - but it still slows them down. We had that happen with one user they were trying to run a BEC scam on.

The best result would be if SM "never admits" that a login is blocked on country purposes only - but I'm almost positive that if authentication is bad from a bad country, it just responds with "invalid login" - and I'm pretty sure if the user has a valid password but is blocked by country that SM says "login blocked by country restrictions" - which, IMO, gives away too much information - because that would literally be an invitation to keep trying until you found the right country.

Something SM devs should take note of.

Do you see anything in the smtp log? I mean, does it say anything that indicates it was geo blocked?

Sadly, I would expect to see these kinds of attacks ramping up given the current political situation. Good luck to us all!

@Patrick  -> this is what we get in our logs (both set to detailed). In this case, the domain was valid, but the user account doesn't even exist. 

In the Administrative log, it shows the failure being on blocked country code - and not "missing user" or "bad password".

In the SMTP log, it just shows the user login failed - with no reason other than "authentication".

My suggestion is to setup a test account on your server, fire up a VPN, and attempt to login to that test account with a valid password but from one of your blocked countries and check the log results for both Administrative and SMTP logs to see what the full results are. Also try with an invalid password - this will show you the different logging results based on your attempts to login.

This is the most fool-proof method of testing for a solution as it will reflect your logs and configuration/server version (in case there are differences between server versions, etc).

** you should be able to right-click and open the images in a new tab to see them "not downsized" if they're hard to read.

*** edited: images were in wrong order.