MX · SPF · DMARC · DKIM

Email deliverability checker.

Inspect any domain's email authentication. We'll surface the misconfigurations that quietly send legitimate mail to spam — multiple SPF records, p=none DMARC, missing MX, and friends.

What this tool does

This checker reads the public DNS records that decide whether a domain's mail is trusted: the MX records that route incoming mail, the SPF and DMARC policies that authorise and police outgoing mail, and — if you supply a selector — the DKIM key used to sign it. For each one it shows the raw record, parses the meaningful tags, and grades the result so you can tell a working setup from one that quietly leaks legitimate mail into spam folders or leaves the domain open to spoofing.

The four signals every sending domain needs

  • MX — points to the mail server that accepts incoming mail, lowest priority number first. Without it, the domain cannot receive mail at all.
  • SPF — a single TXT record listing which IPs and include mechanisms may send for this domain. It should end with -all (hard fail) or ~all (soft fail) to actually mean something.
  • DMARC — published at _dmarc.<domain>, it tells receivers what to do when authentication fails. p=reject is the strongest policy; p=none is monitor-only and does not actually stop spoofing.
  • DKIM — a cryptographic signature added to each message. The public key lives at <selector>._domainkey.<domain>. Selectors are provider-specific: Google uses google, SendGrid uses s1 and s2, Postmark uses pm.

How the three checks fit together

SPF, DKIM, and DMARC are layers, not alternatives. SPF authorises the envelope sender — the address used during the SMTP exchange, which the recipient never sees — and it breaks the moment a message is forwarded, because the forwarding server's IP is not in the original record. DKIM is more robust: it signs selected headers and the body, so the signature survives forwarding as long as nothing rewrites the signed content. DMARC ties the two to the address a human actually reads, the visible From: domain. It passes only when SPF or DKIM both authenticates and aligns with that From domain. This is why a domain can pass SPF and still fail DMARC, and why DKIM plus alignment is usually the part that decides inbox placement.

The misconfigurations that quietly hurt you

  • Two SPF records — publishing more than one SPF TXT record is a permanent error; many receivers then treat SPF as failing outright. Merge everything into one record.
  • SPF that ends in +all or has no all — this authorises the entire internet to send as you, defeating the point.
  • Too many DNS lookups in SPF — chains of nested include mechanisms can exceed the limit receivers enforce, causing a permerror even though the syntax looks fine.
  • DMARC stuck at p=none — fine as a temporary monitoring stage, but it provides no protection against spoofing on its own. The goal is to gather reports, fix alignment, then move to quarantine and ultimately reject.

Frequently asked questions

Why is my mail going to spam even though SPF passes?

SPF on its own is weak: it authorises only the invisible envelope sender and breaks on forwarding. Inbox placement today leans on DKIM and on a DMARC policy that aligns SPF or DKIM with the visible From: domain. Passing SPF in isolation is not enough.

Can a domain have more than one SPF record?

No. A domain must publish exactly one SPF TXT record. Two or more is a permanent error, and many receivers then treat SPF as failing entirely. To add a sender, extend the single record with another include or ip4/ip6 mechanism.

Why does DKIM need a selector?

The selector names which key to fetch, at <selector>._domainkey.<domain>. It lets a domain run several keys at once — one per sending service, plus old and new keys during rotation. Because each provider picks its own selector, you have to supply the right one here to read the DKIM record.

JSON API

GET /api/email/<domain>?selector=<selector> returns the same data as the form. Example: /api/email/google.com.

Related tools

Use the DNS lookup to inspect the underlying TXT and MX records directly, the email header analyser to see how SPF, DKIM, and DMARC were evaluated on a message you actually received, and the blocklist check to confirm a sending IP is not listed. The hosting lookup helps identify which provider runs a domain's mail.