Hi,

I use Google for Apps to manage the email for my domain (say - example.com).

Everything works fine (registered, set appropriate MX etc.) except that the custom URLs to access the services (ie. instead of mail.google.com/a/example.com) sometimes work, and sometimes not.

Precisely: there are environements (at work for instance) where I can type and it gets resolved correctly (and the appropriate mail page opens) and others (at home for instance) where the customized URL is not recognized. The enviroments where it works and where it does not work are roughly 50/50% (I tested about 20-30 worldwide when travelling). This happens on different and unrelated clients and OSes.

General name resolution (in all environemnts) for anything else works fine (eg. cnn.com or others are always correctly resolved).

Other sites (not pointing to google for apps) registered in example.com are resolved correctly.

My domain is registered at xname.org.

Frankly, I am clueless. The fact that this behaviour is consistant (in some places it works, in some other not) and that general resolution is correct makes me wonder if resolvers on the way (form my client to the Google DNS) are not limited by the convoluted way customized URLs are finally turned into the actual mail.google.com/a/... URLs.

This is not a critical issue as it impacts only the address to type into the web browser but it is a curious problem on its own.

Any ideas? :)

Thanks!
Wojtek

Dani AI

Generated

A focused summary and practical checklist that ties the answers from , and together.

Intermittent success across many networks usually points at DNS inconsistency rather than a browser bug. Short-lived propagation is possible (), but persistent ~50/50 worldwide behavior most often means some resolvers see a different answer (unsynchronized or misconfigured authoritative name servers) or there is a record-type conflict. Switching DNS hosts can fix that (as hinted) if the current provider does not reliably publish the same zone everywhere.

Checks to run (replace example.com/mail.example.com with the real names):

dig mail.example.com CNAME +short
dig example.com NS +short
dig @<each-authoritative-NS> mail.example.com CNAME
dig +trace mail.example.com
dig @8.8.8.8 mail.example.com
curl -I http://mail.example.com
(Windows) ipconfig /flushdns

What to look for and fixes

  • If different authoritative NS return different CNAME/A answers, the zone is not synchronized; contact the registrar/DNS host or move the zone to a provider with consistent servers.
  • Confirm the CNAME target is the exact value required by Google (the standard setup uses Google’s host for web addresses), and that the same name has no other records (a CNAME must not coexist with A, MX, etc.).
  • If all public resolvers show the correct CNAME but some networks still fail, check for local caching (flush DNS), hosts-file overrides, corporate split-horizon DNS, transparent proxies or outbound firewall rules that block/alter access.
  • As a temporary fallback, an HTTP 301 redirect from mail.example.com → mail.google.com/a/example.com will reach the service from networks that cannot resolve the vanity name—but this does not preserve the custom hostname in the browser address bar and is only a workaround.

If authoritative servers are consistent and the DNS values are correct, the remaining suspects are caching/proxying at ISP or corporate edges and should be investigated with the network/operators who control those resolvers.

When were the changes made? Perhaps some of the changes have not propigated throughout the DNS network.

Hi,
My domain is registered at xname.org.

The key is your DNS-provider. I'm recomend to use FreeDns.ws .

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.