MX Record Lookup

What it does

MX Record Lookup retrieves the mail exchanger records for a domain — the hostnames responsible for receiving email — and follows them to their A/AAAA addresses and reverse DNS. Alongside the MX results it pulls the SPF and DMARC TXT records so you can read the domain's complete inbound and outbound email posture in one view. For deeper drill-downs, pair this tool with DNS Lookup for full record audits and Reverse DNS to verify FCrDNS on the mail hosts.

When to use it

• Confirming an MX migration to Google Workspace, Microsoft 365, or another provider has cut over correctly and the old hosts are no longer referenced.
• Diagnosing why mail to a domain is bouncing — a missing or unreachable MX, or no SPF, causes silent rejection at many providers.
• Auditing a customer's domain to see whether DMARC is published in monitor (p=none), quarantine, or reject mode.
• Reviewing the priority order of multiple MX hosts to confirm the primary and backup are configured the way you expect.
• Verifying SPF doesn't exceed the 10-DNS-lookup limit, which silently breaks SPF evaluation for many senders.
• Cross-checking the sending IP against an IP Blacklist Check when delivery is failing — reputation, not config, is often the culprit.

How to read the results

MX records are sorted by priority — the lowest number is tried first, and equal priorities are load-balanced. Every MX hostname must resolve to an A or AAAA record (use DNS Lookup to verify); an MX pointing to a CNAME is a configuration error per RFC 5321. SPF (a TXT record beginning v=spf1) lists the IPs and providers authorized to send for the domain and ends in -all (hard fail), ~all (soft fail), or ?all (neutral). DMARC (TXT at _dmarc.domain) sets a policy of none, quarantine, or reject. To check the registrar and ownership of a domain alongside its mail config, see WHOIS Lookup.

Common mistakes

• Publishing two v=spf1 TXT records, which invalidates the entire SPF policy — there must be exactly one.
• Pointing an MX record at a CNAME instead of a hostname with an A/AAAA record, breaking RFC compliance and causing failures with strict mail servers.
• Setting DMARC straight to p=reject without a monitoring period, which can blackhole legitimate mail from forgotten senders.
• Including too many include: mechanisms in SPF and exceeding the 10-DNS-lookup limit, after which receivers treat the policy as PermError.
• Forgetting that mailbox providers also enforce FCrDNS — if your sending IP's reverse DNS doesn't match the HELO, big mailboxes (Gmail, Yahoo) will throttle or reject. Verify with Reverse DNS.

# curl — JSON response (default)
curl https://internettimes.com:80/api/v1/mx-lookup/example.com \
  -H "Authorization: Bearer YOUR_API_KEY"

# Markdown response — ingest-friendly for agents
curl "https://internettimes.com:80/api/v1/mx-lookup/example.com?format=md" \
  -H "Authorization: Bearer YOUR_API_KEY"