When a client verifies a server's certificate, it knows the domain name of the server, then it can check whether the domain name exists in the SAN (Subject Alternative Name) field of the server's certificate.
When a server verifies a client's certificate, it doesn't know the domain name of the client. Does it mean SAN in client certificate is useless?
Generally speaking it is up to the server (and its administrator) to define the requirements for the client authentication/validation in mutual TLS.
I've seen range of the solutions to this problem. The certificate or the public key can be pinned. You may validate the user against directory like LDAP (the DN can be registered). In some scenarios you only care about the issuing CA. There are options to mix and match different details provided in the certificate. The one thing that is really ill-advised is to use the SAN DNS entry, SAN IP or combination of both in client certificates. We should never assume that the client is present in DNS or has a static IP. The identity shouldn't be based on dynamic factors.
SANs for client certs can be domain names, or IP addresses, or email addresses, and sometimes other information. There's no requirement that they are domain names only
Client auth often uses IPs and emails. Keep in mind, though, that the CN (common name) will be checked first.
Also, keep in mind that some implementations will attempt a reverse DNS (PTR record) lookup of the connecting IP address and validate that against the SAN field.
As referenced in this answer, a SAN value listing UPN specifies the domain name as part of the User Principal Name (UPN) suffix value, or it may not if the SAN values populated with other alternate identifiers such as OID, UID or other GUIDs for PKI/endpoint access management, but I think all would provide an auditable trail of some piece of information to follow-up on if needed.
