When working with Google Apps domains, email delivery issues often manifest in subtle ways. In this scenario, most emails arrive normally, but certain senders consistently fail to reach the recipient - with the sender receiving a "Connection timed out with ghs.l.google.com" error.
The core issue stems from improper DNS configuration where the domain's root (@) record was incorrectly set as a CNAME to ghs.google.com. This violates RFC 2181 which states that CNAME records shouldn't coexist with other records at the same domain level.
# Bad configuration (problematic)
@ IN CNAME ghs.google.com.
# Good configuration (working)
@ IN A 74.125.93.121
The inconsistent behavior occurs because different mail servers handle DNS resolution differently:
- Modern MTAs (like Gmail's) perform proper CNAME resolution chaining
- Some enterprise mail systems (like Battle.net's) strictly follow RFC standards
- Legacy systems might use different DNS lookup methods
When a sender's MTA queries your domain's MX records:
dig MX example.com
But encounters a CNAME at the root, some servers will:
- Follow the CNAME chain completely (works)
- Reject the CNAME at root level (fails)
- Fall back to A record lookup (inconsistent)
For Google Apps domains, use these DNS settings:
; Correct Google Apps configuration
@ IN A 216.239.32.21
@ IN A 216.239.34.21
@ IN A 216.239.36.21
@ IN A 216.239.38.21
mail IN CNAME ghs.google.com.
Use these diagnostic commands to verify your setup:
# Check MX records
dig MX example.com +short
# Check root record type
dig example.com +nocmd +nocomments +nostats
# Test SMTP connectivity
telnet ghs.l.google.com 25
Watch out for these configuration mistakes:
- Mixing CNAME with MX records at root level
- Using outdated Google IP addresses
- Forgetting to update all DNS record types
- Not allowing sufficient propagation time
Recently, I encountered a frustrating issue where emails from certain senders weren't reaching my Google Apps domain, while most others came through normally. After some detective work, I discovered this was due to a DNS configuration problem that's more common than many realize.
The breakthrough came when a sender forwarded their delivery failure notification:
----- Transcript of session follows -----
<myusername@GHS.L.GOOGLE.COM>... Deferred: Connection timed out with ghs.l.google.com.
This error message revealed that emails were being redirected to Google's servers rather than my domain. The root cause? An incorrect CNAME record in my DNS settings.
Here's what was happening technically:
- My domain had a CNAME record (@ → ghs.google.com) which is incorrect for email routing
- Some mail servers would follow this CNAME and try to deliver to the canonical name
- This caused emails to be addressed to myusername@ghs.l.google.com instead of myusername@mydomain.com
The inconsistency in email delivery stems from how different mail servers handle DNS lookups:
- Modern mail servers typically check MX records first and ignore CNAMEs for email routing
- Some legacy systems (like battle.net's) may perform CNAME lookups when MX records aren't immediately available
- Strictly configured servers might reject CNAME chains for email delivery due to RFC compliance
To fix this, I replaced the CNAME with an A record:
@ 74.125.93.121 (A)
Alternatively, you could use:
@ 3600 IN A 74.125.93.121
Important notes about the solution:
- Simply removing the @ record doesn't work - it must be replaced
- The specific IP address isn't critical as long as it's a valid Google IP
- Changes may take up to 48 hours to propagate fully
After making changes, verify with these commands:
nslookup -type=mx yourdomain.com
dig yourdomain.com any
You should see proper MX records and no CNAME for the root (@) record.
For comprehensive email delivery:
- Always maintain proper MX records pointing to Google's servers
- Avoid CNAME records at the root level (@)
- Set up SPF, DKIM, and DMARC records for authentication
- Regularly check your domain's configuration with tools like:
nslookup -q=mx yourdomain.com 8.8.8.8
dig yourdomain.com txt
Based on community reports, these services are particularly sensitive to this issue:
- Battle.net gaming platform
- Some corporate mail systems with strict RFC compliance
- Legacy financial institution email systems
- Certain automated notification systems
If problems persist after fixing the DNS:
# Check Google's MX records for your domain
host -t mx yourdomain.com
# Verify DNS propagation globally
dig @8.8.8.8 yourdomain.com
dig @1.1.1.1 yourdomain.com
Remember that some senders may have cached the old DNS information, so it may take time for all emails to flow normally.