What DNS reveals — and what only a real email shows
Every tool on this page reads public DNS records and nothing else. That is the same view a receiving mail server has before your message even reaches it — but it is only half the check.
DNS tells you: whether an SPF, DMARC, MTA-STS or TLSA record exists and is syntactically valid, how many of the ten permitted DNS lookups an SPF record consumes, which mail servers are responsible for the domain, which certificate they present on STARTTLS and whether their IP addresses appear on blacklists.
DNS does not tell you which IP you actually send from. An SPF record can be syntactically flawless and still fail to cover the very machine that sends your invoices — that only surfaces once a real message is examined. Equally invisible: the DKIM selector, which exists only inside the signature of an actual message, whether that signature verifies cryptographically, whether SPF and DKIM align with the visible sender domain, and which TLS version the message really travelled over.
For that part there is the full analysis: send an email to
hello@analyzemy.email and get the report within seconds.
Which tool for which symptom
- Your mail lands in the spam folder. Start with the
SPF check and the
DMARC check. If DMARC is missing entirely, or the policy
sits at
p=none, the receiver has no instruction for what to do with forged messages from your domain — and grades you more harshly when in doubt. - The receiver rejects with
554 5.7.1 … blocked using zen.spamhaus.org. That is a blacklist entry for the sending IP: blacklist check, then the page on 554 5.7.1. SPF permerroror "too many DNS lookups". The record exceeds the limit of ten recursive lookups and is therefore not evaluated at all — the outcome is not "fail" but "invalid". The SPF check lists every lookup individually; the matching error page explains how to shorten it.- Messages arrive late or not at all. MX check — it shows priorities, IP addresses, reverse DNS and whether the servers can be reached over STARTTLS at all.
- You want to know whether transport is encrypted. Also the MX check: negotiated TLS version, certificate with issuer and expiry, hostname match and DANE/TLSA.
- You want to create a record or rebuild an existing one. That is what the SPF generator and the DMARC generator are for. Both load an existing record into the form, and both run the finished draft through the same audit as the checking tools — for SPF including a recursive count of its DNS lookups, before the record ever reaches DNS.
What you can enter
Each tool expects a domain but also accepts whatever you happen to have at hand: a full URL
such as https://example.com/contact, an email address such as
info@example.com, a hostname with a port, or an internationalised name such as
müller.de, which is converted to Punycode internally. The domain name is
extracted from it.
No sign-up, no cost. Twenty queries per five minutes are allowed per IP address, shared across all six tools — so the blacklist and DNS operators being queried do not carry the load.
When a check is worth running
Every result is a snapshot. It is worth looking after any DNS change, after switching providers, after connecting a newsletter or ticketing system — and before a larger send begins. Blacklist entries appear and disappear continuously; a clean result from last week says nothing about today.
Check, understand, fix
The tools tell you what DNS says. What each individual check means is explained under checks. How to create a record correctly is covered by the guides. And if your mail server returned a specific message, you will find it verbatim under error messages.