How to check the public security of a domain

What public security posture means

Public security posture is the security footprint observable from outside the organization, with no credentials and no internal access. It is what an attacker sees when choosing a target: whether email records allow spoofing, whether HTTP headers protect the user in the browser, whether forgotten subdomains still point to external services, whether leaked credentials show up in public pastes, what third-party providers sit behind your domain, and whether any of them suffered a recent breach.

It matters for three practical reasons. First, weak public posture is the typical entry point for the majority of incidents that make the news, according to trend reports published by ENISA and other industry sources. Second, it is the only thing a customer or auditor can check without signing an NDA, which means it defines the first technical impression of your organization. Third, it is the easiest area to fix: most findings are configuration changes, not multi-month projects.

The good news is that all of this surface can be measured passively, in seconds, without touching your internal systems.

Email: SPF, DKIM, DMARC and MTA-STS

Email is where most incidents start, and almost all the important controls are public DNS records. If they are wrong, anyone can verify it and abuse it.

SPF — Sender Policy Framework

A DNS TXT record declaring which servers are authorized to send mail on behalf of your domain. If it is missing or malformed, receivers cannot tell your legitimate mail from spoofed mail. If it is too permissive (for example, authorizes large network ranges that no longer send mail), an attacker finds a comfortable vector.

How to detect a failure. The record does not exist, exceeds the 10 DNS lookup limit from the RFC, includes `+all` (universal authorization), or authorizes networks that no longer send your mail.

DKIM — DomainKeys Identified Mail

Cryptographic signature on outbound mail, with the public key published in DNS. It lets the receiver verify the message has not been altered and comes from the domain it claims to come from. DKIM is what gives real weight to DMARC.

How to detect a failure. No DKIM selector published, key shorter than 1024 bits (obsolete cryptography), or the email provider signs mail but the DNS record is missing — so the signature cannot be verified.

DMARC — Domain-based Message Authentication, Reporting and Conformance

The record that ties SPF and DKIM together and tells the receiver what to do when either fails: nothing (`p=none`, monitoring mode), quarantine (`p=quarantine`), or reject (`p=reject`). Without an active DMARC policy, SPF and DKIM do not protect against phishing that impersonates your brand.

How to detect a failure. No DMARC record, permanently stuck at `p=none` (never moving to quarantine or reject), or no `rua` address to receive aggregate reports — meaning you have no visibility into impersonation attempts.

MTA-STS — SMTP MTA Strict Transport Security

A published policy that forces servers sending mail to your domain to use TLS and verify the certificate. Without MTA-STS, an attacker on the path can downgrade the connection to plaintext and intercept mail.

How to detect a failure. No `_mta-sts` TXT record, no HTTP policy published, or policy in `none` mode. A quick control to implement and rare in small domains, which makes it a real operational differentiator.

Quick check: the "Email security" block in Hard2bit Scanner validates all four records on your domain and shows the specific failures with explanatory text, not just OK/KO. Free to start.

DNS: DNSSEC, sensitive records and Certificate Transparency

DNS is the nervous system of public posture. If it is well governed, everything else holds up. If it is broken, nothing else matters.

DNSSEC

Cryptographic signature on DNS responses that prevents an attacker on the resolution path from redirecting traffic to a fake server. Few domains enable it, but its absence is a strong point in any external audit report.

Overall DNS health

Authoritative server redundancy, consistency across providers, no misconfigured wildcards, no sensitive records unnecessarily exposed (`_admin`, `_dev`, `_staging`, `_internal`) that reveal internal structure. Each one is a clue for an attacker.

Certificate Transparency (CT)

Public logs where every TLS certificate issued for any domain is recorded. Anyone can query which certificates have been issued for your brand — including those issued by mistake or by an attacker who has compromised your DNS. Not monitoring CT is a common blind spot.

How to detect a failure. The team is not alerted when a new certificate is issued for the domain, or subdomains show up in CT logs that are no longer in use but still point to live external services. Those are takeover candidates.

Quick check: the "DNS health" and "Certificate Transparency" blocks in the scanner show which subdomains appear in CT logs, classified by pattern (dev/staging/admin) — those are the ones to review first.

Web: HTTP headers, cookies and mixed content

When a user opens your site, the browser receives a response from the server with a set of headers that regulate what the page can do and what it cannot. If they are missing or wrong, the site still works, but the user is exposed to perfectly preventable risks.

HTTP headers that matter

• Strict-Transport-Security (HSTS): forces the browser to use HTTPS always, even if the user types `http://`. Without HSTS, an attacker on the network can intercept the first connection.
• Content-Security-Policy (CSP): declares which origins of scripts, images and styles the page may load. Without CSP, an injection flaw easily turns into session theft.
• X-Frame-Options or `frame-ancestors`: prevents your site from being loaded in an iframe of another domain. Without it, your site can be hijacked visually (clickjacking).
• X-Content-Type-Options: nosniff: stops the browser from interpreting files as a different type than declared, a common technique in some attacks.
• Referrer-Policy: controls what origin information leaks when navigating to other sites.
• Permissions-Policy: limits which browser APIs the page may use (camera, microphone, geolocation).

Cookie configuration

The `Secure`, `HttpOnly` and `SameSite` attributes prevent session cookies from leaking through insecure channels or being used in forced requests from other domains. A cookie without these attributes on an authenticated session is a real risk.

Mixed content

Pages served over HTTPS that load resources over HTTP. Modern browsers block critical mixed content, but warnings and mixed images remain a signal of careless maintenance and, in some cases, of user information leakage.

TLS / SSL: encryption, certificates and secure protocols

The TLS certificate is the first thing a browser or client validates when connecting to you. Three fronts matter.

The certificate

Valid, issued by a trusted CA, with the correct domain name (including wildcards if applicable), and a sufficient key size. Unexpected certificate expiry is still one of the most common causes of production incidents.

Protocols and cipher suites

TLS 1.2 minimum, TLS 1.3 ideally, and disabling SSLv2/SSLv3, TLS 1.0 and TLS 1.1 — all with documented public vulnerabilities. Modern cipher suites, no RC4, no 3DES, no MD5-based algorithms.

Advanced configuration

OCSP stapling for fast revocation, Perfect Forward Secrecy so that a future key compromise does not decrypt past traffic, and certificates with SCT (Signed Certificate Timestamps) for Certificate Transparency integration.

External exposure: subdomains, ports and cloud storage

This is where the findings that worry leadership the most appear, and they are the easiest to exploit.

Forgotten subdomains (shadow IT)

Every subdomain that ever existed leaves a trail in CT logs and DNS feeds. If they point to abandoned external services (a Heroku you no longer use, a GitHub Pages from an old campaign, an S3 bucket from two years ago), an attacker can claim it as their own and serve content from your brand. That is what is called subdomain takeover, and it appears consistently as a critical finding in bug bounty programs.

Exposed ports

Admin panels reachable from the Internet, databases with no firewall, exposed management services. The operational rule is: if it does not need to be on the Internet, it should not be on the Internet.

Exposed cloud storage

S3 buckets, Azure Blob containers, Google Cloud Storage spaces accidentally set to public. They typically contain backups, database exports, internal documents. A misconfiguration here is one of the fastest breaches you can produce.

Quick check: the "Subdomain takeover risk", "Exposed ports" and "Exposed cloud storage" blocks in the scanner detect these three classes of findings without touching your systems. They are Premium checks, available in the Starter plan (€19/month) and above.

Leaks in pastes, repositories and AI datasets

An important share of exposure no longer lives on your domain but outside of it: in sites where code and text get published, and where someone inside your organization may have shared something by mistake.

Public pastes and repositories

Pastebin, GitHub, public GitLab, technical forums. Automated searches for your domain, your emails, your internal names or your API keys in these sites surface leaks the security team may not have detected.

AI datasets and open archives

Common Crawl, public training datasets, archive.org. Your public content may be included in datasets that feed generative models, and that has two implications: commercial (control over how LLMs cite you) and security (information leaked publicly that now forms part of a dataset).

Information exposed by mistake

Accessible `.env` files, exposed `.git`, PDF documents with internal metadata (author, file path, software), backups with predictable extensions. Each one is a key that may not look important until someone uses it.

Supply chain and NIS2: third-party risk

The EU NIS2 directive makes organizations accountable for the risk of their technology supply chain. That means if a vendor of yours (CRM, marketing, analytics, CDN, payments) suffers a breach, you must have detected it, evaluated the impact on your organization, and left documented evidence of the response.

What it actually covers

The control is not just "knowing who your vendors are". It is knowing which vendors have access to your data or serve content from your domain, what public breaches they have had and when, what potential impact they may have had on your organization, and what response measures you took.

How it gets detected automatically

Hard2bit Scanner cross-references third-party providers detected on your domain (via HTTP headers, loaded scripts, DNS records) against a database of documented public breaches. If your email-marketing provider suffered a breach 14 months ago, it shows up in the report — and that is exactly what a NIS2 auditor will want to see managed.

Quick check: the "Vendor breach exposure" block in the scanner is one of the few commercial automated controls in the Spanish market that provides NIS2-aligned supply-chain traceability.

AI era: bots, llms.txt and Agent Readiness

Between 2025 and 2026 a new layer appeared in public domain posture: how AI agents see you. People no longer just search your brand on Google; they ask ChatGPT, Claude, Perplexity or Gemini, and those assistants read your site very differently from how a user does.

Selective AI bot blocking

If you want to prevent your content from feeding generative models without consent, you can block GPTBot (OpenAI), ClaudeBot (Anthropic), Google-Extended (Google) and other AI scrapers in `robots.txt`, in HTTP headers and in `meta` tags. If you do not, anything you publish is eligible to end up as training data.

llms.txt and the instruction file for LLMs

Emerging standard (not yet official but widely adopted by technical sites) that publishes an `llms.txt` file at the domain root describing which sections of the site are useful for a model, in which format, and under what conditions. It is to AI agents what `sitemap.xml` is to search engines.

Content-Signal, ai.txt and scraping policies

Signaling of content type (informational, commercial, transactional), explicit policies on usage by generative models (training yes, commercial inference no, citation with attribution yes), and structured markup designed so an agent can interpret entities, products, FAQs and pricing. All are emerging; whoever adopts them early will have an advantage in how they appear in generative answers.

Quick check: Hard2bit Scanner is one of the few commercial scanners that evaluates up to 11 emerging AI Agent Readiness standards (4 basic in the Starter plan, 11 total in Pro). It is territory most competitors do not yet cover.

What to do if your domain fails any of these checks

As a rule of thumb, findings fall into two buckets.

Configuration findings (the majority)

Missing or malformed SPF/DKIM/DMARC, missing HTTP headers, cookies without attributes, certificates close to expiry, AI bots not blocked. 70-80% of typical findings are this type. They are fixed with a DNS or web server config change, in hours or a few days, and do not require a specialist team.

Structural findings (the important ones)

Active subdomain takeover, unmanaged vendor breaches, exposed cloud storage with sensitive data, integration with a vendor that had a public breach last year and whose impact was never evaluated. These may need incident response, pentesting for validation or a deeper audit project. The difference between these two buckets is what separates "I fix it on Friday" from "I need to talk to someone serious".