Your DNS records decide who may send email as your domain and which certificate authorities may issue certificates for it. SecQon reads four of them — SPF, DMARC, CAA and DNSSEC — through a DNS resolver, so this check sends no traffic to your servers at all. It runs on every plan, and it only reports a record as missing when DNS actually answered that it does not exist.
Reports “No SPF record” when your domain does not say which servers may send its email.
Reports an SPF record ending in +all, which authorises any server in the world to send as you (high).
Reports a missing DMARC record, looking up the chain to your registrable domain the way mail receivers do.
Reports a DMARC policy of p=none, which only monitors and lets spoofed mail through.
Reports when no CAA record limits which certificate authorities may issue for your domain.
Reports DNSSEC not enabled, and the broken half-state where keys are published but the delegation from the parent zone is not signed.
Before concluding a record is missing, we prove the resolver can serve that record type. If lookups fail, you get one “DNS lookups could not complete” note and no findings.
The template sweep on Standard and Deep scans includes subdomain-takeover templates that detect DNS records pointing at services you no longer control.
Anyone can send an email that claims to be from your domain. SPF and DMARC are how receiving mail servers tell the real messages from the forged ones — without them, or with DMARC left on p=none, a phishing email “from” your finance team to a customer arrives looking entirely legitimate. That is a direct route to invoice fraud and account takeover, and it damages trust in every genuine email you send.
CAA and DNSSEC protect the plumbing underneath your website. A CAA record limits which certificate authorities may issue certificates for your domain, which narrows the ways someone could obtain one they should not have. DNSSEC lets resolvers check that the answers they receive for your domain were not tampered with in transit. Neither is dramatic, but both appear on security questionnaires and in audits.
Missing DNS records are also easy to get wrong in the other direction. A DNS lookup that times out is not the same as a record that does not exist, and early versions of this check confused the two on our own domains. It now only reports absence from a definite answer, and shows you the exact query and response it saw.
A finding of a type this check really produces. The evidence is illustrative, not taken from a customer's scan.
$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=none; rua=mailto:dmarc@example.com"Read your DMARC aggregate reports (the rua address) and confirm every legitimate sender — your mail provider, CRM, billing system — passes SPF or DKIM. Change the policy to p=quarantine, optionally with pct=25 to start with a share of mail. Once nothing legitimate is being quarantined, move to p=reject. Re-test the finding from your report.
Every report names what its scan did and did not assess. See the full OWASP Top 10 coverage, including the two categories no external scan can assess.
No. The queries go to a DNS resolver, not to your website or mail server. It is completely passive.
No. DKIM keys are published under selector names that cannot be enumerated from outside, so no external scanner can check DKIM reliably. The report lists it as not assessed rather than guessing.
Because p=none asks receivers to report spoofed mail but still deliver it. It is the right place to start, but it does not stop anyone sending as your domain until you move to quarantine or reject.
DMARC, CAA and DNSSEC are looked up the chain to your registrable domain, the same way mail receivers and certificate authorities do. If the parent domain publishes them, the subdomain inherits them and is not reported.
No. We use passive sources such as certificate-transparency logs to suggest names, but we never brute-force DNS, and a suggested subdomain is not scanned until you verify it. Your asset list is only as complete as what you add.
Certificate trust and expiry, and whether your server still accepts TLS 1.0 or 1.1.
Missing or ineffective HSTS, CSP, clickjacking, nosniff and Referrer-Policy headers, plus cookie flags.
36 high-risk TCP ports — databases, container control planes, remote admin — checked with one connect each.
Your API’s own schema, read as an outsider: open operations, GraphQL introspection, CORS and leaked stack traces.
A browser-rendered crawl plus bounded proofs for XSS, SQL injection and SSRF, and an active scanner on the pentest tier.
Last reviewed against our scanning documentation on 24 Sep 2026.
Free for one verified asset, no card needed. Paid plans add the written report, more assets and deeper scans.