Google Workspace not receiving email: when this repair path applies
Verify the current Google MX record and remove stale conflicting MX values. Use these steps when the domain is not routing incoming mail to Google correctly, but first run the embedded diagnostic so the business-email DNS and mail authentication evidence supports this provider-specific path rather than a neighboring DNS, TLS, application or mail cause.
Find the authoritative setting before editing
Google Admin console for service/verification values and the authoritative DNS provider for MX, SPF, DKIM and DMARC publication. For Google Workspace not receiving email, confirm the active nameservers and exact service owner before changing lookup MX. A DNS-looking screen at google-workspace has no public effect when another provider is authoritative for the zone.
Evidence to save for Google Workspace not receiving email
Record the current public state for lookup MX, confirm Google destination, check activation in Admin console. This gives the repair a before/after comparison and prevents a cached answer or a separate working service from being confused with the configuration that produced the symptom.
- Lookup MX — Read the public MX priorities and targets, then verify that each target itself resolves. A visible MX record is not enough if its mail hostname is broken.
- Confirm Google destination — Verify confirm Google destination from the public Internet and compare it with the value the responsible provider says should be live.
- Check activation in Admin console — Verify check activation in Admin console from the public Internet and compare it with the value the responsible provider says should be live.
- Retest delivery DNS — Verify retest delivery DNS from the public Internet and compare it with the value the responsible provider says should be live.
Repair steps in google-workspace
Verify the current Google MX record and remove stale conflicting MX values.
- 1. Lookup MX. After this step, check the public value tied to lookup mx before changing another unrelated setting.
- 2. Confirm Google destination. After this step, check the public value tied to confirm google destination before changing another unrelated setting.
- 3. Check activation in Admin console. After this step, check the public value tied to check activation in admin console before changing another unrelated setting.
- 4. Retest delivery DNS. After this step, check the public value tied to retest delivery dns before changing another unrelated setting.
Why this order matters for google-workspace
The sequence begins with the provider/authority decision, then moves through lookup MX, confirm Google destination, check activation in Admin console. That keeps the change scoped to the failed business-email DNS and mail authentication path and avoids replacing nameservers, mail authentication or another healthy service just to make a provider dashboard indicator change.
Verify Google Workspace not receiving email
The public MX/authentication records should match the intended mail provider, required hostnames should resolve, and the relevant SPF/DKIM/DMARC check should no longer show the original failure. Compare the same lookup MX and confirm Google destination evidence used before the change; a repair is complete when the public result agrees, not merely when the google-workspace interface reports that a save succeeded.
If google-workspace and the public result disagree
Check whether the edited zone is authoritative, whether the exact root/www/subdomain was changed, whether a proxy state alters the visible endpoint, and whether a prior TTL can still exist in recursive caches. Do not add a second conflicting lookup MX value to force validation.
Mistakes to avoid for this repair
Do not copy tenant-specific or region-specific values from another account, delete working email records during a website repair, change nameservers as a shortcut, or alter SSL/proxy modes without evidence from the origin. Google Workspace not receiving email should change only the settings required by this diagnosis.
Technical references
These primary standards and provider documents are used to verify the behavior described on this page. Provider dashboards can change, so use the current official value for tenant-specific DNS records rather than copying an example from another account.