TR

MX lookup with SPF and DMARC check

See which mail servers accept email for a domain and whether its SPF and DMARC records are present and well formed.

wikipedia.orggithub.comcloudflare.commozilla.orgbbc.co.uk

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. The findings look for the mistakes that break it in practice: more than one SPF record, which makes evaluation fail outright; mechanisms that require more than ten DNS lookups once includes are followed; the deprecated ptr mechanism; and an ending of +all, which authorises the entire internet.

A policy ending in ~all asks receivers to treat other sources with suspicion, and -all asks them to reject. Either is reasonable when combined with DMARC. A record with ?all or no all mechanism provides almost no protection.

DMARC: policy and reporting

DMARC ties SPF and DKIM to the address people actually see in the From header. A message passes when SPF or DKIM passes and the authenticated domain aligns with the From domain. The record states what receivers should do with failures, none, quarantine or reject, and where to send aggregate reports.

p=none is the right starting point because it lets you collect reports without affecting delivery. It is not a destination. A domain that stays on p=none indefinitely has visibility but no protection against spoofing. The tool shows the policy, the subdomain policy if set, the pct value and the report addresses.

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.

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.