DNS Checker and Email Security Audit
DNS is the address book that turns your domain name into an IP address, but that's no longer all it does. The same records also decide who may send email in your name, which certificate authority may issue certificates for you, and whether your DNS responses can be intercepted and altered. This tool resolves your domain's A, AAAA, MX, NS, TXT, CAA and SOA records, then evaluates your SPF, DMARC and DNSSEC setup not as a simple present/absent check but in terms of how much protection it actually delivers.
Dumping records isn't enough; what they say is what counts
Most DNS lookup tools list your records and stop there. But the mere existence of an SPF record means nothing on its own: if it exceeds the ten-lookup limit, receiving servers treat it as invalid and behave as though it weren't there. In the same way, you can have a DMARC record and still be telling receivers to "do nothing" if your policy is p=none; forged email is delivered regardless. This tool doesn't just list the records, it tells you what level of protection each one actually corresponds to.
SPF and the ten-lookup limit
An SPF record declares which servers are authorised to send email on your behalf. Each include, a, mx, ptr, exists and redirect term inside it triggers an extra DNS lookup at the receiving server, and RFC 7208 caps the total at ten. Exceed it and the result is a "permerror": SPF evaluation fails and your record quietly stops applying. It's a common and hard-to-spot failure at companies that keep adding marketing tools, CRMs and invoicing systems. The mark at the end of the record matters too: -all asks for mail from unlisted servers to be rejected, while ~all asks for it to be marked and let through. ~all is the common recommendation, because it leaves room for DKIM and DMARC evaluation instead of rejecting at the SMTP level. +all makes SPF entirely meaningless.
DMARC: having a record doesn't mean you're protected
SPF and DKIM verify that an email came from an authorised server and wasn't altered in transit. Neither of them, however, requires the "From" address the user sees to match the domain being authenticated. DMARC is the mechanism that establishes that alignment and tells the receiver what to do when authentication fails. The policy has three levels: p=none only monitors and offers no protection at all, p=quarantine sends unauthenticated mail to the spam folder, and p=reject has it refused. The common mistake is setting the record up and leaving it at p=none; reports are collected, but forged email sent in your domain's name still reaches its target. Defining a report address with rua= is critical too: without reports you can't see which legitimate systems send on your behalf, and you can't tighten the policy safely.
DNSSEC and the certificate rule that changes in 2026
DNSSEC signs DNS responses cryptographically, blocking attacks that intercept lookups and return forged addresses. For a long time it was seen as an optional improvement, but its place in the certificate ecosystem has changed: under a rule taking effect in March 2026, certificate authorities are obliged to perform DNSSEC validation during domain validation and CAA lookups. That doesn't make DNSSEC mandatory; but if your zone is signed, the certificate issuance process gains a cryptographic guarantee too. If your registrar supports it, turning DNSSEC on brings a concrete gain on both the resolution and the certificate side.
CAA: you decide who can issue your certificates
A CAA record limits which certificate authority may issue certificates for your domain. With no record, the default is that any authority can. That leaves open the risk of an attacker who can bypass domain validation obtaining a certificate that looks entirely valid in your name. Restricting issuance to the authority you actually use, with a single DNS record, costs close to nothing and has a direct effect.
Why does name server redundancy get measured?
Whether your domain resolves at all depends on its name servers. With only one defined, if that server becomes unreachable your domain stops resolving and visitors can't reach the site, even though the site itself is perfectly healthy. That's why RFC 2182 requires at least two; spreading them across different networks, and ideally different geographies, lowers the risk further. This tool reports how many name servers you have and whether they all sit under the same domain.
Your Questions
Frequently Asked Questions
What's the difference between SPF, DKIM and DMARC?
SPF declares which servers may send on your behalf. DKIM seals the email with a cryptographic signature, proving it wasn't altered in transit. DMARC aligns the results of those two with the sender address the user actually sees, and tells the receiver what to do when authentication fails. All three work together; setting up SPF alone does not protect your domain against spoofing.
I have a DMARC record but forged email still gets through. Why?
Most likely your policy is p=none. That setting asks receiving servers only to send reports and take no other action; unauthenticated email keeps being delivered. Protection begins at p=quarantine and completes at p=reject. Make the transition gradually, reviewing your reports as you go, or you risk blocking your own legitimate mail.
Why should I care how many lookups my SPF record makes?
RFC 7208 caps the number of DNS lookups performed during SPF evaluation at ten. Every include, a, mx, ptr, exists and redirect term adds to that count. Once the limit is passed the result is a "permerror" and SPF is treated as if it were never defined, which is a hard failure to notice because you never see an error message.
Will enabling DNSSEC slow my site down?
No noticeable slowdown is expected in practice. Validation happens on the resolver side and increases response size somewhat. The thing to watch isn't speed but configuration discipline: a botched key rollover can leave the domain unable to resolve at all. If your registrar manages DNSSEC for you, that risk is largely removed.
Does a CAA record renew my certificate automatically?
No. CAA only limits which certificate authority MAY ISSUE certificates; it doesn't perform renewals. With a record in place, an authority not listed must refuse the request. Renewal is the job of your certificate provider or the automation on your server.
I have no MX record. Do I still need SPF and DMARC?
Yes. MX records are about RECEIVING email; SPF and DMARC are about email SENT in your name. A domain that never receives mail can still be used as the sender address in a phishing campaign. For domains that don't send, defining a strict SPF and a p=reject DMARC prevents your domain being abused.
Does this tool measure DNS propagation?
No. This audit evaluates the current state of your records and your security configuration; it doesn't measure how far a change has spread across resolvers around the world. Propagation is a meaningful question right after you've changed a record and the TTL hasn't expired; for auditing a settled configuration, what the records say is what matters.