DNS Record Lookup + SPF / DMARC / DKIM Checker

A domain's DNS is the source of truth for where its website points and how its email is authenticated. This tool resolves the core records - A and AAAA (addresses), MX (mail servers), NS (nameservers), CNAME, SOA, CAA, and every TXT record - and then goes further than a plain lookup by parsing the three records that stop email spoofing: SPF, DMARC, and DKIM.

Misconfigured email authentication is the quiet reason legitimate mail lands in spam and the reason attackers can forge your domain. Each check here returns a clear pass, warning, or fail with the exact fix, so you are not left staring at a raw TXT string wondering whether it is correct.

An SPF record lists which servers may send mail for your domain. The catch most people miss is in RFC 7208: SPF is allowed a maximum of 10 DNS lookups during evaluation. Every include:, a, mx, ptr, and exists mechanism costs one lookup, and include: records nest - so a single include:_spf.google.com can pull in several more.

Go over 10 and receivers return a permerror: SPF is treated as broken and your mail can fail authentication even though the record "looks fine." This tool recursively resolves your includes and counts the real total, warns as you approach the limit, and flags the dangerous +all (which lets anyone send as you) and a missing all mechanism.

DMARC ties SPF and DKIM together and tells receivers what to do with mail that fails both. Its policy tag p= has three values. p=none is monitor-only: it collects reports but still delivers failing mail, so it provides visibility, not protection. p=quarantine sends failing mail to spam. p=reject blocks it outright and is the strongest setting.

A domain sitting on p=none for months is a common finding - it feels safe but stops nothing. The checker reports your policy, whether pct= is throttling enforcement below 100%, and whether an rua= reporting address is set so you can actually see who is sending as you before you tighten the policy.

DKIM signs each message with a private key; the matching public key is published in DNS at <selector>._domainkey.<domain>. The selector is chosen by your mail provider, so there is no single place to look - Google Workspace uses google, Microsoft 365 uses selector1 and selector2, Mailchimp uses k1, and so on.

This tool probes about 20 of the most common selectors in parallel and also takes a selector you supply. If you know yours, find it in any email you sent: open the raw headers and read DKIM-Signature: ... s=<selector>. An empty p= in a DKIM record means the key has been revoked, which the tool flags.

Beyond the big three, three newer records improve security and inbox presence. MTA-STS forces senders to use TLS when delivering to you, closing a downgrade-attack gap that opportunistic TLS leaves open. TLS-RPT asks other servers to report when TLS delivery to you fails, so you find problems before users do. BIMI displays your verified logo next to authenticated mail in supporting inboxes.

These are optional, so the tool marks them as enabled or not set rather than pass or fail. One honest limit: the full MTA-STS policy file is served over HTTPS at mta-sts.<domain>/.well-known/mta-sts.txt, which a browser cannot fetch cross-origin - so the tool confirms the DNS record exists but does not read the policy body.

On your own machine, dig example.com ANY and dig _dmarc.example.com TXT return the same raw records. The tool shows those dig equivalents with copy buttons. What it adds is the parsing and judgement: counting SPF lookups, grading the DMARC policy, resolving MX hosts, and probing DKIM selectors you would otherwise have to guess one by one.

Because browsers cannot make raw DNS queries, the lookups run over DNS-over-HTTPS to Cloudflare (with Google as a fallback). Only the domain name you type is sent to that public resolver - never to a CtrlOps server, and no email content is ever involved. You can confirm this in your browser's network tab.