██████  ███    ██ ███████
       ██   ██ ████   ██ ██
       ██   ██ ██ ██  ██ ███████
       ██   ██ ██  ██ ██      ██
       ██████  ██   ████ ███████

██████  ███████  ██████  ██████  ███    ██
██   ██ ██      ██      ██    ██ ████   ██
██████  █████   ██      ██    ██ ██ ██  ██
██   ██ ██      ██      ██    ██ ██  ██ ██
██   ██ ███████  ██████  ██████  ██   ████

Domain Security Audit

A domain security audit examines your domain's DNS configuration, email authentication records (SPF, DKIM, DMARC), transport security (DANE/TLSA certificate pinning, MTA-STS, TLS-RPT), encryption settings (DNSSEC), certificate controls (CAA), and email security management providers. It examines your domain's observable DNS controls for email spoofing, DNS hijacking, man-in-the-middle attacks, and brand impersonation — and whether configuration detected signals consistent with active management or is left unmonitored. DNS Tool performs all these checks in a single scan and delivers a security posture assessment based on controls observed.

No. DNS Tool is not a PCI DSS Approved Scanning Vendor (ASV) and our reports are not PCI compliance attestations. PCI DSS requires vulnerability scans performed by vendors formally certified by the PCI Security Standards Council. Certified ASVs include Qualys, Tenable, and Trustwave, among others.

What we do: We perform OSINT-based DNS security analysis — examining your domain's email authentication (SPF, DKIM, DMARC), transport security (DANE, MTA-STS), and public exposure posture using only publicly available data. This is complementary to PCI scanning, not a substitute for it.

If you need PCI compliance: Engage a certified ASV from the PCI SSC ASV listing. Use DNS Tool alongside your ASV to ensure your domain's DNS and email security posture is properly configured — something ASV scans typically do not cover in depth.

Enter your domain name above and click Analyze. DNS Tool checks your SPF record (which servers can send email as you), DMARC policy (what happens to unauthorized emails), and DKIM keys (cryptographic email signatures). If any of these are missing or misconfigured, the report will flag it and explain the risk in plain language. A DMARC policy of p=reject instructs receiving servers to reject unauthorized messages (RFC 7489, Section 6.3).

SPF (Sender Policy Framework) lists which mail servers are authorized to send email for your domain. DKIM (DomainKeys Identified Mail) adds a cryptographic signature to emails designed to detect tampering. DMARC (Domain-based Message Authentication) tells receiving mail servers what to do when SPF or DKIM checks fail — it can monitor, quarantine, or reject suspicious emails. Together, these three protocols form the foundation of email authentication and spoofing prevention.

DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS responses, designed to detect tampering in transit. Without DNSSEC, attackers could redirect your domain's traffic to malicious servers through DNS hijacking or cache poisoning. DNS Tool validates the full DNSSEC chain of trust and checks the AD (Authenticated Data) flag across multiple resolvers. Many enterprise organizations use alternative security measures like enterprise-grade DNS providers with built-in DDoS protection when DNSSEC is not deployed.

No account is required to run any analysis. Paste a domain, click Analyze, and get your intelligence report immediately. Optional Google sign-in unlocks personal features like scan history, watchlists, and domain dossiers. We don’t collect tracking cookies and marketing messages are opt-in only. Every analysis queries DNS records in real-time from multiple resolvers (Cloudflare, Google, Quad9, OpenDNS, DNS4EU) to provide the most current data available to public resolvers. Built by IT Help San Diego Inc.—a San Diego-based IT consultancy providing remote DNS configuration and troubleshooting, email deliverability consulting, and network security for organizations worldwide. Our team offers on-demand support without retainers or contracts.

DNS Tool provides a comprehensive DNS security intelligence report that goes beyond record retrieval. The report analyzes multi-resolver consensus verification across Cloudflare, Google, Quad9, OpenDNS, and DNS4EU; email authentication scoring; DKIM key strength analysis; DANE/TLSA certificate pinning analysis for authenticated mail transport; DMARCbis readiness checks for evolving DMARC standard changes; enterprise DNS provider detection; email security management provider identification (DMARC monitoring, SPF flattening, TLS-RPT reporting); SMTP transport encryption checks; BIMI brand verification; CAA analysis with MPIC context; and a CVSS-aligned risk level (Critical / High / Medium / Low / Informational) with per-section remediation designed for both technical and executive audiences. Compare analyses over time, export results as JSON, and discover subdomains via Certificate Transparency logs. Every query fetches fresh data — we never show cached results.

Absolutely. DNS records are public information, so analyzing any domain is perfectly legitimate. This is commonly used for vendor security assessments, supply chain risk evaluation, due diligence before partnerships, and competitive analysis. The security posture report gives you a quick view of how seriously an organization takes their email and DNS security.

DANE (DNS-based Authentication of Named Entities) pins TLS certificates to DNS via TLSA records, providing controls against man-in-the-middle attacks and rogue CAs when DNSSEC is deployed — over 4 million domains publish TLSA records globally (per stats.dnssec-tools.org), including Microsoft Exchange Online. BIMI (Brand Indicators for Message Identification) enables brand logo display next to emails in supporting inboxes, providing a visual signal consistent with authenticated sending. MTA-STS (Mail Transfer Agent Strict Transport Security) instructs sending servers to require encrypted email delivery, providing controls against downgrade attacks. TLS-RPT (TLS Reporting) sends delivery failure reports when encrypted email connections fail, giving you visibility into transport security issues. CAA (Certificate Authority Authorization) specifies which certificate authorities are permitted to issue certificates for your domain. CAs now verify CAA from multiple geographic locations via MPIC (Multi-Perspective Issuance Corroboration, mandatory since September 2025 per CA/B Forum Ballot SC-067). DNS Tool analyzes your CAA records and provides context on MPIC implications. These are advanced security controls that complement SPF, DKIM, and DMARC. DNS Tool checks all of them in a single scan.

This is one of the most common misconceptions in email security. SPF -all (hard fail) sounds stronger, but RFC 7489 warns that it can cause receiving servers to reject messages before DKIM is checked and before DMARC can evaluate the result. A message that would pass DMARC via DKIM alignment gets rejected prematurely. Google and most major providers recommend ~all (soft fail) for active sending domains, with DMARC p=reject as the enforcement layer. The combination of ~all + DMARC reject is the strongest compatible security stance — every authentication method is fully evaluated before a disposition decision is made.

Federal .gov context: CISA BOD 18-01 (2017) requires valid SPF records and DMARC p=reject for federal civilian agencies. The directive doesn't explicitly specify -all vs ~all, but federal agencies widely adopted -all as a defense-in-depth practice. In 2017, most federal domains had no DMARC at all, so -all was a pragmatic safety net — you couldn't rely on DMARC being there to catch what SPF missed. Now that DMARC p=reject is in place across federal domains, the -all is somewhat redundant and creates the RFC 7489 premature-rejection risk, but federal infrastructure is controlled enough that the risk is lower. The directive hasn't been updated to reflect the broader industry consensus around ~all + DMARC reject. Microsoft also historically defaults to -all.

This is a simple way to remember that DMARC p=none is only a monitoring policy — it instructs receiving servers to deliver everything, even messages that fail authentication, and just send reports. It does not instruct receivers to block spoofed emails. Similarly, p=quarantine instructs receivers to treat suspicious messages as spam, where recipients might still open them. DMARC p=reject instructs receiving servers to refuse messages that fail authentication (RFC 7489, Section 6.3) — they should never reach the inbox or spam folder. The recommended modern configuration is SPF ~all (soft fail) combined with DMARC p=reject and verified DKIM signing. This configuration ensures every authentication method is fully evaluated before a disposition decision is made.

This is one of the most widespread misconceptions in email security, and it's easy to see why it took hold. The Netherlands adopted DANE early and aggressively — SIDN (the .nl registry) promoted it, and the Dutch government mandated it. That high visibility created the false impression DANE was only a Dutch phenomenon. Making things worse, DANE for web browsers genuinely did fail — browsers never adopted it because Let's Encrypt solved HTTPS certificate distribution differently. People conflated "DANE for websites is dead" with "DANE is dead," missing that DANE for email (SMTP) was thriving separately the entire time.

What actually happened: DANE for SMTP (RFC 7672) quietly grew into a global standard. Over 4 million domains now publish TLSA records (stats.dnssec-tools.org tracks daily). Adoption extends well beyond the Netherlands: Sweden (.se), Norway (.no), Czech Republic (.cz), and EU public agencies all have significant DANE deployment.

The turning point: Microsoft Exchange Online announced General Availability of inbound SMTP DANE with DNSSEC in October 2024 — available to all Exchange Online tenants at no extra cost. Outbound DANE has been live since March 2022. By Q4 2025, Microsoft plans to make outbound SMTP DANE mandatory per-tenant. The IETF itself uses DANE on mail.ietf.org. This isn't a niche experiment — it's the world's largest email platform betting on it.

Why DANE is underrepresented in DNS audits: DANE requires DNSSEC (RFC 7672 §1.3), and DNSSEC adoption was historically slow. Because DANE verification is complex and adoption was initially concentrated in a few regions, it was often omitted from DNS security assessments. This created a self-reinforcing blind spot: if DANE isn't checked, it isn't seen, and its growing adoption goes unrecognized. DNS Tool surfaces DANE as a first-class protocol.

Try it yourself — analyze these domains to see DANE in action: ietf.org (the IETF's own infrastructure), nlnetlabs.nl (creators of the Unbound DNS resolver), freebsd.org (the FreeBSD project). DANE works alongside MTA-STS — best practice is to deploy both: DANE provides cryptographic strength via DNSSEC, while MTA-STS provides broader compatibility for receivers that don't validate DNSSEC.

The RFCs themselves establish a clear hierarchy. DANE is the primary standard; MTA-STS is the alternative for domains that cannot deploy DNSSEC.

DNSSEC + DANE (RFC 7672) is the strongest mechanism. DANE publishes TLS certificate information in DNSSEC-signed TLSA records, creating a cryptographic chain of trust from the DNS root to the mail server certificate. This removes reliance on certificate authorities — no trust-on-first-use weakness, no vulnerability to CA compromise. The requirement: your domain must be signed with DNSSEC.

MTA-STS (RFC 8461) was created for domains where “deploying DNSSEC is undesirable or impractical” (§2). It publishes a TLS policy via HTTPS using the existing CA trust model. Simpler to deploy but inherits CA limitations and is vulnerable on first use (§10). RFC 8461 mandates: senders “MUST NOT allow MTA-STS validation to override a failing DANE validation” — DANE always takes precedence.

Why both coexist: DANE is backward-compatible by design. RFC 7672 §1.3 specifies that sending servers simply skip the DANE check if the receiving domain isn't DNSSEC-signed. This means enabling DANE never breaks anything — it only adds protection for senders that validate it. MTA-STS works independently alongside DANE without conflict.

Where the camps stand today:

• Microsoft is the strongest DANE advocate. Exchange Online enforces inbound DANE with DNSSEC (GA October 2024), and plans to make outbound DANE mandatory per-tenant. Microsoft also supports MTA-STS, but DANE is their strategic direction.
• Proton Mail & Fastmail fully support DANE with DNSSEC on their mail infrastructure, providing cryptographic transport controls for their users.
• Google validates DANE outbound (Gmail checks TLSA records when sending to DANE-enabled domains). However, google.com is not DNSSEC-signed, and Google Workspace customers cannot deploy DANE — Google's shared multi-tenant MX infrastructure (aspmx.l.google.com) does not publish TLSA records and does not allow customers to do so. Google relies on MTA-STS for inbound transport security.
• Apple uses MTA-STS for iCloud Mail. apple.com is not DNSSEC-signed and has no DANE/TLSA records.
• Government agencies (Netherlands, Germany, Czech Republic, Nordic countries) tend to mandate DANE+DNSSEC, often by policy. The IETF itself uses DANE on mail.ietf.org.

The key question: Microsoft's enforcement momentum is the most significant development. When the world's largest email platform not only supports but enforces DANE, it creates pressure on sending domains to enable DNSSEC so their DANE records are actually validated. If Microsoft makes outbound DANE mandatory — meaning Exchange Online requires DANE for delivery to domains that publish TLSA records — it could tip the balance toward universal DNSSEC+DANE adoption.

Best practice: Deploy both for defense in depth. DANE provides the strongest cryptographic controls via DNSSEC, while MTA-STS provides coverage for senders that don't validate DNSSEC. The German BSI TR-03108 standard mandates both DANE and MTA-STS together with TLS-RPT. The protocols are complementary: DANE for cryptographic strength, MTA-STS for breadth of coverage.

See it in practice: Analyze ietf.org to see DANE + DNSSEC delivering the strongest transport security, then compare with google.com which uses MTA-STS — the best available option given Google's infrastructure cannot support DNSSEC/DANE.

OSINT (Open Source Intelligence) is the collection and analysis of information from publicly available sources. Intelligence agencies, law enforcement, and security researchers have used OSINT methodology for decades — it is the foundation of modern threat intelligence.

DNS Tool is an OSINT platform. Every data source we query is publicly available: DNS records (via standard resolvers), certificate transparency logs, RDAP registrar data, and publicly accessible web resources. We do not bypass authentication, probe closed ports, or exploit vulnerabilities. We observe what is already visible to anyone with a browser or a dig command — and we organize those observations into actionable intelligence.

This is the same methodology used by Shodan, Mozilla Observatory, Censys, and VirusTotal. The difference is our focus: we specialize in DNS security posture and email authentication, producing intelligence products modeled on the formats used by national intelligence agencies.

We query only publicly available data that anyone can access using standard tools:

• DNS records — the same records returned by dig or nslookup (A, MX, TXT, CNAME, TLSA, DNSKEY, etc.)
• Certificate transparency logs — public logs maintained by CAs, queried via crt.sh
• RDAP registrar data — the public successor to WHOIS, served by IANA-accredited registries
• Publicly accessible web resources — MTA-STS policy files, security.txt, robots.txt, and (if opted in) well-known misconfiguration paths that any browser can visit

We do not access anything behind authentication, scan closed ports, or perform any action that requires special authorization. Every query we make is reproducible using the verification commands in each report.

No. Penetration testing involves active exploitation attempts against systems with the owner’s permission. Testers try to bypass security controls, escalate privileges, and map real-world attack paths.

DNS Tool performs passive OSINT observation: we read public DNS records, check publicly accessible URLs, and analyze the data. No vulnerabilities are exploited, and we don’t interact with any system that requires authorization.

Think of it this way: a penetration tester tries to break into your house. We observe whether your front door is locked — from the sidewalk.