MX lookup: find a domain's mail servers

See which mail servers accept email for a domain, with the first 5 resolved to their addresses, and whether its SPF and DMARC records are present and well formed.

What the MX lookup checks

The tool reads the MX records of the domain and lists each mail host with its preference value. Where the hostnames match a well-known provider pattern it names the likely provider. It then fetches the SPF policy from the TXT records of the domain and the DMARC policy from _dmarc under the domain, parses both and reports findings.

Everything here is read from public DNS. The tool does not connect to your mail server, send test messages or look inside any mailbox.

Reading MX records

Sending servers try the MX host with the lowest preference number first and move to higher numbers only if that fails. Equal numbers share load. An MX target must be a hostname that resolves to an address; it must not be an IP address and must not be a CNAME. If a domain has no MX record at all, senders fall back to the domain's A or AAAA record, which is rarely what anyone intends.

A domain that should never receive mail can publish a null MX, a single record with preference 0 and a target of a single dot. That tells senders to fail immediately instead of retrying for days.

SPF: who may send for the domain

SPF is a TXT record beginning with v=spf1 that lists the servers allowed to use the domain in the envelope sender address.

SPF checker

DMARC: policy and reporting

DMARC ties SPF and DKIM to the address people actually see in the From header. The tool shows the policy, the subdomain policy if set, the pct value and the report addresses.

DMARC checker

Why DKIM needs a selector

DKIM public keys are published at selector._domainkey.example.com, and the selector is an arbitrary label chosen by the sending system. A domain can have many selectors and DNS offers no way to list them, so no tool can discover a DKIM key from the domain name alone. You can find the selector in the DKIM-Signature header of a message sent from the domain, in the s= tag, and then query that name with a DNS lookup.

What these records cannot prove

Correct MX, SPF, DKIM and DMARC records are necessary for reliable delivery but they do not guarantee that a message lands in the inbox. Mailbox providers also weigh sender reputation, complaint rates, content and recipient engagement, none of which is visible in DNS. Likewise, a clean configuration does not prove that mail is flowing. It shows that the published policy is coherent, which is the part you can fix from the DNS side.

How to use this tool

  1. Enter the domain. Type or paste a domain name such as example.com. A full URL works too: the scheme, path and a leading www are removed.
  2. Look up the mail servers. The tool reads the MX records, resolves each mail host and reads the SPF and DMARC records.
  3. Review priorities and findings. Lower numbers are tried first. Findings explain what is missing or risky in the mail setup.

Command line equivalent

The same check from a terminal. The commands use example.com: replace it with your own name.

  • MX recordsdig example.com MX +short
  • SPF and DMARCdig example.com TXT +short; dig _dmarc.example.com TXT +short
  • Windowsnslookup -type=MX example.com

FAQ

What is an MX record?

An MX record tells other mail servers which hosts accept email for a domain and in which order to try them. Each record has a preference number and a hostname; the lowest number is tried first.

Can I have more than one SPF record?

No. A domain must publish exactly one TXT record starting with v=spf1. Two or more cause a permanent error and SPF fails for every message. Merge all sources into a single record.

What is the SPF 10-lookup limit?

While evaluating SPF, a receiver may perform at most ten DNS lookups caused by include, a, mx, exists, ptr and redirect. Nested includes count. Exceeding the limit produces a permanent error, so long chains of third-party includes need pruning.

Why can't the tool find my DKIM record?

DKIM keys live under a selector name that only the sending system knows. Without the selector there is nothing to query. Look at the s= tag in the DKIM-Signature header of a sent message, then look up selector._domainkey.yourdomain as a TXT record.

Is p=none a valid DMARC policy?

It is valid and useful for monitoring, because receivers send reports while delivery is unaffected. It gives no protection against someone forging your domain. The usual path is none, then quarantine, then reject, moving on once reports show your legitimate mail passes.

Do correct records guarantee my email reaches the inbox?

No. Authentication is a baseline requirement at large mailbox providers, but placement also depends on reputation, content and recipient behaviour. Records that pass remove one common reason for rejection, nothing more.

Which email provider does a domain use?

The MX hostnames usually reveal the inbound provider, because hosted mail services use recognisable names. This shows where mail is received. Outbound mail may go through other services, which tend to show up in the SPF record.