About DNS Radar
Public DNS measurement without a black box
DNS Radar turns public DNS, email and registration data into a readable audit report. The records and measurements remain visible beside each result, so you can verify what the conclusion is based on. No account is required, and DNS Radar does not build a database of scan reports.
Why DNS Radar exists
DNS Radar was built and is maintained by Joris de Vaan. It grew out of a practical problem: many checkers show only a green or red light, while the underlying records are what you need to understand and safely fix a fault. DNS Radar therefore combines the technical measurement, the assessment and the relevant explanation in one report.
What is checked
The full domain scan checks A, AAAA, NS, SOA, MX and TXT records, email authentication through SPF, DKIM, DMARC and BIMI, DNSSEC and CAA, and secure mail transport through MTA-STS, TLS-RPT and DANE/TLSA. Separate tools cover DNS propagation, reverse DNS, RDAP registration data and mail headers. Only public data and information you enter yourself are used; DNS Radar does not sign in to your provider or perform an active vulnerability scan.
Where the measurement runs
DNS queries are sent directly from your browser to public resolvers whenever possible. If a browser, firewall or ad blocker prevents that, a limited backup route through the DNS Radar Cloudflare Worker may be used. Pasted mail headers are parsed locally; only extracted From and Return-Path domains receive a bounded mail-routing check. A blacklist check sends the selected IP address only when you request it.
How a verdict is produced
The status, audit index and confidence level are calculated by deterministic code. Each check compares the measured data with protocol rules and explicit assessment boundaries; explanatory wording or any automatically generated advice does not decide the verdict. The report distinguishes failures, improvement advice, informational results and checks that could not be measured reliably.
Standards and maintenance
The checks follow the relevant RFCs and other primary technical sources wherever possible. The guides link to those sources and explain where a standard leaves room for interpretation or provider behaviour differs. Tests protect known edge cases and regressions, but protocols and implementations change, so the measurement rules and explanations are maintained continuously.
What the audit index means
The audit index summarises only fully completed counting checks on a scale from 0 to 100. Failures in important controls such as SPF, DKIM, DMARC and DNSSEC carry more weight than missing optional settings. Unmeasured and partly measured checks count neither positively nor negatively and lower confidence in completeness. Without a complete score basis, no index is calculated. Use the index to prioritise work and compare measurements, not as a certificate or proof that a domain is secure.
A snapshot, not a guarantee
DNS can differ by resolver, location and time. Recent changes may still be cached, some answers are deliberately distributed geographically, and DKIM can only be checked for selectors that are known or can be discovered. A clean report therefore cannot guarantee that every email will be delivered, a website will always remain reachable or no security issue exists outside the measured areas.
How to use the report
Fix concrete failures first, review the advice in the context of your own mail and hosting environment, and scan again after DNS changes have propagated. Always verify record values with your own provider before publishing them: DNS Radar can identify a problem, but it does not automatically know every sender, certificate authority, DKIM selector or policy choice used by your organisation. When the context is uncertain, a manual review by someone with access to the environment is still required.
Minimising data
DNS Radar uses no accounts and does not store submitted domains or scan reports in its own database. Some functions do send a domain name, IP address or technical request away from your device, and Cloudflare processes connection and security data for the website and Worker. The privacy statement describes which data each function processes, which external services are involved and what limited operational logging takes place.