To diagnose an email delivery problem in 60 seconds, put the recipient's domain into Zro7 MX Lookup. Zro7 returns the MX records (mail servers, in priority order), highlights the provider (Google Workspace, Microsoft 365, Fastmail, self-hosted), and pulls SPF, DKIM, and DMARC TXT records so you can see whether your sending domain is set up to be accepted at all.
What MX records tell you
- Which server accepts mail —
10 aspmx.l.google.commeans Google Workspace,0 example-com.mail.protection.outlook.commeans Microsoft 365. - Priority order — lower is preferred. Multiple MX at different priorities is a normal failover pattern.
- Missing MX — no MX at all means the domain does not accept mail. Some senders will fall back to the A record; most modern MTAs won't.
The three failure modes MX lookup catches
1. No MX record
If the lookup returns no MX, mail bounces with 550 no mail server. Fix: publish an MX record pointing at your mail provider.
2. MX points at the wrong provider
You migrated to Google Workspace but MX still points at the old cPanel host. Mail goes to the old inbox, no bounce. Fix: update MX to the new provider's values, delete the old ones.
3. MX is fine, but SPF / DMARC rejects the sender
MX accepts the connection, then the recipient's DMARC policy rejects because your sending IP isn't in your SPF include. Zro7 surfaces the TXT records so you can see v=spf1 ..., _dmarc.example.com policy (p=none | quarantine | reject), and DKIM selector presence.
Why browser-side matters
Cloud MX checkers (MXToolbox, DNSChecker) log every query and often show ads based on the domain you searched. Zro7 queries Cloudflare's DoH directly with no server-side logging on our end.
Steps
- Open MX Lookup.
- Enter the domain. MX + SPF + DMARC render together.
- Cross-check with DNS Lookup → All records for anything else.
Zro7