What is an ESP / MX lookup?
Every domain that accepts email publishes one or more MX (Mail Exchanger) records in DNS. These records point at the hostnames of the mail servers responsible for receiving messages, with a numeric preference that decides resolution order. The hostname patterns are usually distinctive — Google Workspace publishes `aspmx.l.google.com`, Microsoft 365 publishes `*.mail.protection.outlook.com`, Zoho publishes `mx.zoho.com`, and so on.
An ESP checker queries those MX records, sorts them by preference, and matches the hostnames against a database of known providers. The protocol is governed by **RFC 5321** (the modern SMTP specification) and **RFC 7505** (which defines the 'Null MX' for domains that never receive mail).
Why check the ESP / MX records?
1Tailor outreach by mailbox provider
Gmail, Microsoft, and on-prem filters score content differently — knowing the destination informs subject lines and HTML choices
2Confirm migration cutovers
After moving from one provider to another, verify MX records point at the new platform before deprovisioning the old one
3Detect mis-routed mail
A typo or stale MX entry silently sends mail to the wrong provider — the checker exposes it instantly
4Audit vendor portfolios
When acquiring or auditing a company, see at a glance which email platform each domain runs on
How ESP detection works — step by step
You enter a domain. The checker queries its MX records over DNS.
Each MX record is parsed into a preference number and a hostname.
Records are sorted by preference — lowest number is tried first by sending servers.
The hostnames are matched against patterns for known providers (Google, Microsoft, Zoho, Proofpoint, Mimecast, and dozens more).
The detected provider is reported, with the full preference-ordered MX list shown so you can audit the routing yourself.
MX record syntax
example.com. 3600 IN MX 1 aspmx.l.google.com.
example.com. 3600 IN MX 5 alt1.aspmx.l.google.com.
example.com. 3600 IN MX 5 alt2.aspmx.l.google.com.Field breakdown
preference— lower wins, mail tries that host firsthost— receiving mail server hostnameTTL— cache lifetime in secondsIN— Internet record classMX— record typeCommon ESP / MX failures and fixes
No MX records published
Without MX records the domain cannot receive mail — publish the records your provider supplied
Wrong provider's MX still live
After migration the old provider's MX is still answering — remove stale records to stop mail loops
Same preference for every record
Either intentional (round-robin) or accidental — verify the provider's documentation
MX points to a CNAME
RFC 2181 forbids MX records pointing at a CNAME — point MX records directly at a hostname with an A/AAAA record
자주 묻는 질문(FAQ)
An ESP (Email Service Provider) checker inspects the MX records on a domain and fingerprints them against a database of known providers like Google Workspace, Microsoft 365, Zoho, Proofpoint, and Mimecast. The MX hostnames usually reveal the provider unambiguously, even when the domain itself is custom.
Knowing the receiving ESP helps you tailor outreach — Gmail and Outlook score content differently — and it helps you debug delivery problems by checking the provider's published deliverability rules. For your own domain, it confirms you are not pointing MX records at a deprecated platform after a migration.
MX preference (sometimes called priority) is a number that tells sending servers which MX host to try first. Lower numbers are tried first, with the rest acting as fallbacks if the primary is unreachable. The checker sorts the records by preference so the resolution order is obvious.
Mail providers publish multiple MX records for redundancy. If the primary host is down, sending servers retry the next one in preference order. Google Workspace and Microsoft 365 typically publish 4–5 MX entries on different infrastructure to guarantee mail acceptance even during regional outages.
Yes. A domain with no MX record cannot receive email. RFC 5321 says sending servers should fall back to the A/AAAA record, but most production senders treat the absence of MX as a hard bounce. If your ESP checker returns no MX records on a domain you expect to receive mail, publish the correct MX entries immediately.
It works on any domain that publishes MX records. Parked or unused domains often expose your registrar's default MX or a 'no MX' configuration, both of which the checker will flag clearly. This makes it useful for auditing entire domain portfolios.