There are several restrictions when Windows do not even attempt Kerberos authorization.
1. SPN point to PTR, not web alias
If your non-domain-member webserver have an alias you have no need to assign SPN on that alias. It would be checked against real DNS record of that server.
Let's say you have this:
A record server.example.org -> 10.0.0.1
PTR record 10.0.0.1 -> server.example.org
CNAME record webapp.example.org -> server.example.org
Accessing webapp.example.org you do not need SPN HTTP/webapp.example.org, you should assign HTTP/server.example.org to the service record ONLY. I believe it should be an IP address if there is no PTR record as well.
2. Domain members should NOT be called by any other name.
I have a domain member server with IIS and Windows Integrated Authentication enabled. Due to my network setup it has DNS setup in both non-domain and domain network:
srv.example.org -> 10.0.0.1
10.0.0.1 -> srv.example.org
And it also registered in domain:
srv.tdm.example.org -> 10.0.0.1
This server would not allow Kerberos if being accessed as srv.example.org, Kerberos will work only if it is been accessed as srv.tdm.example.org. It even will not work if it is accessed via IP address.
I guess the nature of this fact caused by windows name resolution in domain which usually happens before DNS.
I will continue searching and will update this answer.