Most of the links in the answers do not work any longer and none of the answers are entirely correct.
Here is one correct answer: Kerberos Error APP_MODIFIED when using a CNAME DNS record
And here is another one: https://argonsys.com/microsoft-cloud/library/using-computer-name-aliases-in-place-of-dns-cname-records/
Sum-up: you need to register SPNs for the machines behind your A-records, not your CNAME-records. For a Windows-box, aliasing is better done with this command instead of CNAME-DNS entries:
netdom computername <HOST> /Add:<ALIAS>
this keeps both DNS and SPNs automatically up-to-date.
A possible reason CNAMES may have "worked" for some is because they either did not notice the automatic fallback to NTLM or they had DisableStrictNameChecking enabled. Or they had the SPNs registered to both the CNAME and the A-record, which then of course works as well.
To prove my answer, here is a test done in my environment. The screenshot is obfuscated for privacy reasons.
![SPN CNAME test](../../images/3814263913.webp)
we can observe
- browser is opening testgrc.domain.local
- DNS contains a CNAME entry pointing to grc.domain.local
- DNS lookup is asking for testgrc.domain.local, DNS server responds with the target of the CNAME-record "grc.domain.local", and the IP of this host
- browser initates a kerberos request to the domain controller for grc.domain.local (NOT grctest.domain.local)
i ran the same test with MS SQL Management studio, and the same result can be observed. Kerberos works correctly when the SPN is registered to the host that the CNAME is pointing to (the A-record), not the CNAME itself.