I have a customer who recently ran some SPN commands for some SQL servers and was completed successfully, and the AD object was updated properly as per SPN results. Later on, client restarted the server, however, still not able to connect to sql named instances because the Kerberos authentication still not working, see errors from one named instances below. We are using different IPs but all pointing to the same port number 1433 (sql default port).
Sql Alias: DEV04
2015-07-22 23:17:49.77 spid10s Server is listening on [ X.X.X.X <ipv4> 1433].
2015-07-22 23:17:49.77 spid10s Server local connection provider is ready to accept connection on [ \\.\pipe\SQLLocal\APPDEV ].
2015-07-22 23:17:49.77 spid10s Server named pipe provider is ready to accept connection on [ \\.\pipe\MSSQL$DEV\sql\query ].
2015-07-22 23:17:49.77 Server Server is listening on [ ::1 <ipv6> 50089].
2015-07-22 23:17:49.77 Server Server is listening on [ 127.0.0.1 <ipv4> 50089].
2015-07-22 23:17:49.77 Server Dedicated admin connection support was established for listening locally on port 50089.
2015-07-22 23:17:49.88 spid10s SQL Server is now ready for client connections. This is an informational message; no user action is required.
2015-07-22 23:17:49.88 Server SQL Server is attempting to register a Service Principal Name (SPN) for the SQL Server service. Kerberos authentication will not be possible until a SPN is registered for the SQL Server service. This is an informational message. No user action is required.
2015-07-22 23:17:50.02 Server The SQL Server Network Interface library could not register the Service Principal Name (SPN) [ MSSQLSvc/sqlservername.domain.com:APPDEV ] for the SQL Server service. Windows return code: 0x2098, state: 15. Failure to register a SPN might cause integrated authentication to use NTLM instead of Kerberos. This is an informational message. Further action is only required if Kerberos authentication is required by authentication policies and if the SPN has not been manually registered