// free tool

DNS Security Checker

Check SPF, DMARC, DNSSEC, CAA and MX records for the gaps that let attackers spoof your domain.

Enter any domain. We look up its SPF, DMARC, DKIM, MX, CAA, DNSSEC and nameserver records — nothing is modified and no email is sent.

What this DNS security checker looks for

Enter a domain and this tool runs a set of read-only DNS lookups against it — the same kind of queries any mail server or resolver makes millions of times a day — and checks the results against what a well-configured domain should have. The main draw is email authentication: SPF, DMARC and DKIM are the three records that together decide whether someone can convincingly send email claiming to be from your domain. The rest — CAA, DNSSEC, nameserver count and wildcard records — round out the picture of how the domain itself is configured.

SPF (Sender Policy Framework)

SPF is a TXT record at your domain's apex listing which mail servers are allowed to send email claiming to be from you. Without one, receiving servers have no way to tell your real mail from a forgery, and many will accept the forgery anyway. We check for a missing record, more than one record (which is a permanent error under RFC 7208 and breaks SPF entirely, regardless of what either record says), and the qualifier on the final all mechanism: -all tells receivers to reject unlisted senders, ~all asks them to flag but not block, ?all asks for no enforcement at all, and +all explicitly authorises every server on the internet to send as you — a startlingly common misconfiguration. We also flag records needing more than 10 DNS lookups to evaluate, because SPF silently stops working past that limit with no visible symptom.

v=spf1 include:_spf.google.com -all

DMARC

DMARC sits on top of SPF and DKIM. It is a TXT record at _dmarc.yourdomain.com that tells receiving servers what to do when a message fails authentication, and where to send reports about it. The policy tag, p=, has three values: none means monitor only and take no action — a message that fails still lands in the inbox exactly as if DMARC did not exist — quarantine routes failures to spam, and reject blocks them outright. Most domains should land on p=none first, watch the reports for a few weeks to make sure legitimate mail is not misclassified, then move to quarantine and finally reject. We also flag a missing rua= reporting address, since without it you never see the reports at all.

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com

DKIM

DKIM adds a cryptographic signature to outgoing mail, so a receiving server can verify the message was not altered after it was sent and genuinely came from a server holding your private key. DKIM records live at selector._domainkey.yourdomain.com, where the selector is an arbitrary name your mail provider chooses — Google, for instance, defaults to google. There is no DNS record that lists a domain's selectors, so this tool probes a handful of names mail providers commonly use. Finding nothing at those names is a real limitation of outside-in scanning, not proof DKIM is unset — the report says so explicitly.

MX records

MX records name the servers that actually receive mail for a domain. A domain with none does not receive email at all, which is a perfectly normal setup for, say, a marketing site that only sends transactional mail from a subdomain. It does not make SPF and DMARC optional, though — if anything it makes them more important, because an attacker can still spoof the domain in mail routed through somewhere else entirely, and there is no legitimate traffic for a receiving server to compare it against.

CAA, DNSSEC, nameservers and wildcards

A CAA record restricts which certificate authorities are allowed to issue TLS certificates for your domain; without one, any publicly trusted CA can. DNSSEC lets resolvers cryptographically verify that a DNS response has not been tampered with, by publishing a DS record in the parent zone — genuinely useful, but adoption is still low enough across the web that we treat a missing DS record as low severity rather than a hard failure. Fewer than two nameservers means a single outage can take the entire domain offline. And a wildcard A record answering for any undefined subdomain is worth knowing about because it can quietly mask a dangling DNS record that would otherwise show up as an obvious takeover risk.

How the grade is calculated

Every check starts the report at 100 and deducts based on severity — a missing SPF or DMARC record costs far more than a missing CAA record. Scores of 90 and above earn an A, 75 a B, 55 a C, 35 a D, and anything below that an F. Read the individual findings rather than the grade alone: one missing DMARC record matters more for most domains than several low-severity gaps combined.

Frequently asked questions

What is email spoofing, and how do SPF and DMARC stop it?

Email spoofing is putting someone else’s domain in the From: address of a message you send, so it looks like it came from them. SPF lists which servers are allowed to send mail for a domain, and DMARC tells receiving servers what to do when a message fails that check — without both configured, nothing stops the forgery.

My domain does not send any email. Do I still need SPF and DMARC?

Yes, arguably more so. If a domain has no mail flow at all, the correct SPF record is "v=spf1 -all" — explicitly nobody is authorised to send as you. Without it, an attacker can still spoof your domain in phishing sent through unrelated servers, and there is no legitimate traffic to distinguish it from.

Why can this tool not just tell me my DKIM selector?

DKIM selectors are chosen by whoever configured your mail provider and are not published anywhere discoverable from outside — there is no DNS record that lists them. This checker probes a handful of names mail providers commonly use, and is upfront that a miss there is inconclusive, not proof DKIM is absent.

Is DNSSEC actually worth setting up?

It closes a real gap — DNS responses can otherwise be forged in transit — but adoption across the web is still low, and it adds operational complexity if your registrar and DNS provider do not handle it smoothly. Treat a missing DS record as a nice-to-have, not an emergency, unless your registrar makes it a one-click toggle.

Does checking my DNS records send any email or change anything?

No. Every check in this tool is a read-only DNS lookup — the same kind of query your own browser or mail server makes constantly. Nothing is sent, submitted, or modified, and no email passes through this tool at any point.

Can I check a domain I do not own?

Yes. DNS records are public by design — anyone can look them up with standard tools, and this checker does nothing your own terminal could not do with dig or nslookup. Only act on the recommendations for domains you are actually responsible for.

Is this DNS security checker free?

Yes, completely free with no sign-up. Enter a domain and get the full report immediately.

// one check is not a security programme

This checks one thing. Averto checks everything.

A dns security checker tells you about a single slice of your attack surface. Averto scans your websites, web apps, code, dependencies, containers, configuration and secrets in one place, then explains every finding in plain English.