An MX lookup that names your mail provider
The first step in any email deliverability check is the MX record — the DNS entry that tells the world which servers accept mail for a domain. This MX lookup lists every record in priority order and, where the hostnames give it away, names the provider behind them: Google Workspace, Microsoft 365, Zoho, Proton, Amazon SES, and many more. If a domain has no MX records at all, it can't receive email, and you'll see that immediately.
An SPF checker that counts your DNS lookups
SPF tells receiving servers which hosts may send mail for your domain, and the single most common way it silently breaks is the ten-lookup limit: SPF permits at most ten DNS-querying mechanisms, and every include: you add — plus the includes nested inside those — counts toward it. Go over, and SPF fails with a permanent error that many receivers treat as no SPF at all. This SPF checker resolves your include: chains recursively and shows you the real lookup count, so you can catch a record that's quietly over the limit. It also flags the two other unambiguous faults: more than one SPF record on the domain, and a missing all mechanism.
DKIM lookup — honest about selectors
DKIM is where most tools mislead you. A DKIM key lives at selector._domainkey.yourdomain, and the selector is an arbitrary label chosen by your mail provider — it cannot be listed or discovered through DNS. So we do two things: we automatically probe a large list of common selectors (Google's google, Microsoft's selector1/selector2, and many others), and we let you type in your exact selector for a definitive check. Crucially, if we don't find one, we never claim "DKIM is missing" — because a domain can use DKIM under a custom selector we simply can't see. That honesty is the difference between a useful DKIM lookup and a misleading one.
DMARC policy, reported plainly
DMARC ties SPF and DKIM together and tells receivers what to do when a message fails: monitor (p=none), quarantine, or reject. We report the policy exactly as published, with a neutral note on what it means — because p=none isn't a failure, it's the normal starting point while you monitor reports before tightening enforcement. We don't shout "high risk" at a valid configuration; we show you the policy and let you decide whether it matches your intent.