Sitecore CMS user authentication depends on client cookies. The browser associates cookies with hostnames. If a CMS user authenticates against cms.domain.tld, unless you take steps to associate the authentication cookie with the domain (domain.tld) instead of the subdomain (cms.domain.tld), the browser will not send the cookie in HTTP requests for domain.tld or other subdomains such as en.domain.tld, and mobile.domain.tld.
Additionally, when a user invokes a command that opens a new browser windows for Preview or the Page Editor, Sitecore uses the current hostname, which is the hostname against which the user authenticated (cms.domain.tld). This may be good for authentication cookies, but you might need to configure managed sites in the CMS environment to use paths for site resolution instead of using hostnames. You can implement a processor in the httpRequestBegin pipeline to override the default SiteResolver, for example to determine the context site from the path in the requested URL rather than the hostname. Such a solution could iterate the managed sites to determine which has a path that matches that of the requested item, potentially based on existing logic that applies the Rendering.SiteResolving setting. Such an effort is not specific to cookies and hostnames and is therefore beyond the scope of this post. If someone requests such an example of this approach, and maybe even if nobody does, I may try to implement something.
I know the cookies also in 6.6 is domain dependendat. On Sitecore 6.5 I don't know exactly how was it.
You can find more here: