When given the choice between using an A DNS record or a CNAME DNS record for your SharePoint web applications, favor an A record particularly if you are using Kerberos authentication.  Reference the following TechNet article:

http://technet.microsoft.com/en-us/library/gg502606.aspx

Of particular interest in this article is the following passage:

Kerberos authentication and DNS CNAMEs

There is a known issue with some Kerberos clients (Internet Explorer 7 and 8 included) that attempt to authenticate with Kerberos enabled services that are configured to resolve using DNS CNAMEs instead of A Records. The root of the problem is the client does not correctly form the SPN in the TGS request by creating it using the host name (A Record) instead of the alias name (CNAME).

Example:

A Record: wfe01.contoso.com

CNAME: intranet.contoso.com (aliases wfe01.contoso.com)

If the client attempts to authenticate with http://intranet.contoso.com, the client does not correctly form the SPN and requests a Kerberos ticket for http/wfe01.contoso.com instead of http/intranet.contoso.com

Details regarding the issue can be found in the following articles:

http://support.microsoft.com/kb/911149/en-us

http://support.microsoft.com/kb/938305/en-us

To work around this issue, configure Kerberos enabled services using DNS A records instead of CNAME aliases. The hotfix mentioned in KB article will correct this issue for Internet Explorer but will not correct the issue for the .NET framework (which is used by Microsoft Office SharePoint Server for web service communication).

What me and my team experienced is that a customer had a customization which interfaced with Exchange.  The browser authentication to the web application appeared to be working fine, but the double-hop to Exchange was failing with a 401 error.  All SPNs appeared to be correct.  We changed the DNS records from CNAME records to A records and the authentication began to work as expected.