MX Lookup
DNS lookups send the domain (or DKIM/DMARC host name) to this site's DNS API. Format checks for headers run locally in your browser.
How to use
- Enter a domain (example.com) or an email — the domain part is extracted automatically.
- Click Look up MX (or press Enter). Records are fetched only when you run the lookup, not while typing.
- Review the priority table and copy JSON for tickets or runbooks. Use Sample for a demo domain if needed.
FAQ
What is an MX record?
MX (Mail Exchanger) records tell sending mail servers which hostnames receive email for a domain, ordered by priority (lower number = preferred).
Why does lookup not start automatically?
Lookups run on button click to reduce accidental API use and respect rate limits while you edit the domain.
What if there is no MX but an A record exists?
Some legacy setups rely on an A record at the apex as an implicit mail host. The tool reports that as a fallback; most modern domains publish explicit MX records.
Is data sent to a server?
Yes. The domain name is sent to this site's DNS API to resolve public MX and A records.
How is this different from Email Validator?
Email Validator checks address syntax and optional MX for emails. MX Lookup is dedicated to mail exchanger DNS only.
Introduction
MX lookup answers a simple deliverability question: which servers are allowed to receive mail for this domain? After a DNS migration, ESP change, or “mail not arriving” ticket, verifying MX records is often faster than guessing from a registrar screenshot.
This tool queries public DNS when you click Look up MX — not on every keystroke — so you control when lookups run.
What is an MX record lookup?
Mail systems use MX (Mail Exchanger) DNS records to find inbound hosts. Each record has:
- Priority — lower values are tried first (e.g.
10before20). - Exchange — hostname of the mail server (e.g.
aspmx.l.google.com).
Sending servers perform DNS lookups, sort by priority, and connect to the targets. If no MX exists, some paths fall back to an A record at the apex (uncommon today but still reported here).
Key Features
- Domain or email input with automatic domain extraction.
- Button-triggered MX + A lookup (no auto-query while typing).
- Sortable-style table: priority and mail exchanger hostname.
- Clear status when MX is missing but A exists, or when neither is found.
- JSON export with copy for documentation and support threads.
- Sample button for quick demos without pre-filled input on load.
Common Use Cases
- Confirming Google Workspace, Microsoft 365, or SendGrid MX after DNS changes.
- Comparing primary vs backup MX priorities before a cutover.
- Support debugging: “does this domain accept mail at all?”
- Exporting JSON into incident notes alongside SPF Checker and DMARC Checker results.
Best Practices
- Wait for DNS propagation (minutes to 48 hours) before declaring a failed migration.
- Lower priority number = preferred host; document both primary and backup MX in runbooks.
- MX proves routing, not that a specific address exists — pair with Email Validator for address syntax.
- For sender authentication policy, check SPF and DMARC separately — MX alone does not validate SPF/DKIM.