Dr.Who
← blog

Google Workspace MX records are set but email isn't arriving

· google-workspace · mx · dns · email · troubleshooting

google-workspacemxdnsemailtroubleshooting

If your Google Workspace MX records are configured but mail still isn't arriving, the problem is almost always a DNS mismatch rather than anything inside Google. The usual culprits are leftover MX records from your previous host competing with Google's, MX published on the wrong hostname, a typo or missing trailing dot in the target, or a stray A/AAAA record where the MX should be. Less often, SPF or DMARC is causing recipients to reject your outbound mail. Work through the checklist below and confirm each fix with an MX lookup.

Verify the MX records themselves

Google Workspace today provisions a single MX host. A correct lookup on your domain should return exactly one record:

example.com.   IN MX   1 smtp.google.com.

Older tenants were set up with five hosts at mixed priorities, and these still work:

example.com.   IN MX   1  aspmx.l.google.com.
example.com.   IN MX   5  alt1.aspmx.l.google.com.
example.com.   IN MX   5  alt2.aspmx.l.google.com.
example.com.   IN MX   10 alt3.aspmx.l.google.com.
example.com.   IN MX   10 alt4.aspmx.l.google.com.

Check for these problems:

  • Leftover or duplicate MX from the old provider sitting at a lower (more preferred) number, so senders deliver there instead of Google.
  • Only some of the five legacy hosts present — partial setups deliver intermittently.
  • Typos like aspmx.1.google.com (the digit one instead of the letter l) or a wrong target on smtp.google.com.
  • A missing trailing dot in DNS UIs that require it, which makes the target relative — e.g. smtp.google.com.example.com.

Don't mix the single smtp.google.com record with the legacy aspmx set. Use one scheme, not both.

Confirm the records are on the right name

MX records must live on the exact domain that receives mail, which is almost always the apex. A common mistake is publishing them on www.example.com or another subdomain while users send to @example.com. The apex is written as @ or the bare domain in most DNS editors:

@   IN MX   1 smtp.google.com.

If you receive mail at a subdomain such as mail.example.com, the MX records have to be on that subdomain specifically.

Rule out conflicting and blocking records

Two more failure modes:

  • A stray A/AAAA record where MX is expected. If the receiving name has an address record but no MX, some senders fall back to delivering to that A record — a host that isn't your mail server. Remove the stray record or add the correct MX.
  • SPF or DMARC rejecting your outbound mail. If recipients bounce mail you send, the cause is authentication, not MX. Make sure your SPF record authorizes Google with include:_spf.google.com, and that your DMARC policy isn't failing on alignment.

Give DNS time to propagate

After you edit records, resolvers keep serving the old answer until the previous TTL expires — anywhere from a few minutes to a day. If a lookup still shows the old MX, wait out the TTL before assuming the change failed, then re-check.

Look up your MX records →

Further reading