We had a weird issue like that when we tried logging in as a system level admin directly to the 17017 port on the Kestrel server using a browser on localhost. When we opened the webmail from the public facing addresses, it let us in (even though the username and password was a match) - and in the error logs - we had something similar but it was reversed.
00:14:20.765 [127.0.0.1] Webmail Attempting to login user: REDACTED
00:14:20.765 [127.0.0.1] Webmail Login failed: Domain [localhost:17017] not found
I originally attributed this to to the fact that we had upgraded from a version that required IIS and we never configured "localhost" as a valid header in SmarterMail's bindings. So the server was "installed" using the public urls before we unlocked the firewall. When it moved to the .NET Core app, Kestrel responds to localhost. When we tried using the URLs we originally had bound, it worked.
Another time, there was this. Happened when changing the password but with a previously used password entered that had been rotated out (for some testing):
09:35:05.230 [REDACTED] User REDACTED@ calling change sysadmin password, username: REDACTED
09:35:05.233 [REDACTED] Webmail Login failed: Domain [net:####] not found
09:35:05.233 [REDACTED] Webmail Login failed: Domain [REDACTED:####] not found
09:35:05.233 [REDACTED] Webmail Login failed: Domain [SUBDOMAIN.REDACTED.net:####] not found
When we had the right "old password" in the dialog to change it, there were no errors in the logs.
Looking closer at this, I think what we're seeing in the logs is the loops SM is going through checking the password when attempting to validate it. When a sysadmin account (which isn't associated with any domains fails), it looks like it's looping through the host name passed to the server in the request, deleting one subdomain level at a time until there's nothing left.
Which doesn't explain why your password is becoming invalid x number of days after being changed but at least explains what we're seeing in the logs (maybe ?)...
I would go backwards in the administrative log and search for this -- ones that are proper and successful on 9518 and later have the username included in the log entry - entries from 9511 and older would be different.
User REDACTED@ calling change sysadmin password
but that might take a little refining...