Your Domain Is Public. But Do You Know What It Reveals? A Practical Security Assessment Guide

Imagine this.

You manage a small business website. The homepage loads correctly, HTTPS works, and customers can contact your team without any problems. Everything looks fine.

Then you discover an old subdomain that nobody on your current team remembers. Its DNS records still exist. A certificate was issued for it months ago. Your inventory doesn't mention it.

Is it a vulnerability?

Not necessarily. But it raises a question worth answering: Do you know what your domain exposes publicly, and can you explain why each finding matters?

That is the starting point for an external attack surface assessment. It is not about finding the largest number of assets or treating every observation as a critical security issue. It is about collecting evidence, validating what you find, and deciding what deserves attention.

In this guide, we'll walk through a practical workflow that website owners, developers, and security learners can use on domains they own or are explicitly authorized to assess.

First, understand what you're assessing

An external attack surface includes the internet-facing domains, subdomains, addresses, services, and related infrastructure that may affect an organization's security.

Consider a fictional company called Northstar Retail. Its public footprint might include:

• northstar.example — the main website
• shop.northstar.example — an online store
• api.northstar.example — an application API
• DNS records that identify addresses, mail services, and other infrastructure
• TLS certificates and HTTP response headers that reveal configuration details

These names are illustrative; .example is reserved for documentation.

The important point is that the homepage is only one piece of the picture.

If you're new to the subject, start with What Is an External Attack Surface?. For a broader introduction to the relationship between domains, DNS, subdomains, and addresses, read Domains, Subdomains, DNS, and IP Addresses Explained.

Step 1: Find out where your domain resolves

A domain name is easier for people to remember than an IP address. DNS helps clients discover the information they need to reach the intended destination.

For a domain you're authorized to assess, inspect its IPv4 and IPv6 records:

dig example.com A +short
dig example.com AAAA +short

Replace example.com with your own domain.

An A record identifies IPv4 addresses; an AAAA record identifies IPv6 addresses. If multiple addresses are returned, compare them with your known hosting, CDN, and infrastructure configuration.

Ask yourself:

• Do the returned addresses match the infrastructure I expect?
• Are any results unfamiliar or no longer documented internally?
• Could the result be affected by a CDN, load balancer, or DNS provider?
• When was this information last checked?

Do not jump straight from “I don't recognize this address” to “I've found a vulnerability.” First establish whether it belongs to your organization, a trusted provider, or an expected service.

DNS results can change, and different resolvers may return different answers. A lookup is evidence from a particular point in time, not a guarantee of a complete asset inventory.

For a deeper explanation of name resolution, follow the DNS Fundamentals and Name Resolution guide.

Step 2: Read the DNS records, not just the IP address

DNS records reveal different aspects of how a domain is configured.

You can query some of the common record types using dig:

dig example.com MX +short
dig example.com NS +short
dig example.com TXT +short
dig example.com CAA +short

For additional reference, Cloudflare maintains a practical DNS record type guide.

Here's the question to ask: Does this configuration make sense for the service that is supposed to use it?

A mail record may be expected. A CNAME to a third-party platform may be intentional. A missing record may be entirely normal. The security review begins when you compare observed configuration with the expected configuration.

If you need help understanding record values, continue with DNS Records Explained. If you're troubleshooting changes that don't appear consistently, see DNS Caching, TTL, and Propagation.

Step 3: Discover subdomains that your inventory may have missed

Subdomains can outlive the projects that created them. A testing environment may be retired, a team may change, or an old application may be replaced without every record being reviewed.

Certificate Transparency (CT) logs provide one source of publicly observable certificate information. Because certificates can include names associated with a domain, CT records can help identify subdomains that deserve an inventory review.

Google explains the purpose of this system in its Certificate Transparency overview.

Discovery, however, is not the same as confirmation.

A name in a certificate record does not prove that the host is currently online, belongs to the same team, or has a security weakness. Some records may be old, and some services may be managed by third parties.

For every discovered name:

1. Compare it with your known asset inventory.
2. Identify its owner and business purpose.
3. Confirm whether it is still required.
4. Use only authorized methods for any further testing.
5. Record the decision and remove or remediate assets through the appropriate owner.

CyberSurfaceMap's subdomain intelligence scanner uses passive Certificate Transparency discovery with a fallback provider. It does not actively resolve, connect to, or port-scan the subdomains it discovers.

For a more detailed workflow, read Subdomain Enumeration for Defensive Asset Discovery.

Step 4: Look at the website's HTTP and HTTPS responses

The browser sees more than the rendered webpage. HTTP responses also contain status codes, redirect information, content types, and headers.

For a website you control, you can inspect its root response using:

curl -sSI https://example.com/

Review the status code and response headers. Check whether redirects lead to the expected destination and whether the website consistently uses HTTPS.

Some response headers communicate security-related instructions to browsers. Examples include:

• Content-Security-Policy (CSP): restricts the sources from which a page may load resources and can help reduce the impact of certain injection attacks.
• Strict-Transport-Security (HSTS): tells browsers to use HTTPS for future connections to the host.
• X-Content-Type-Options: can prevent browsers from MIME-sniffing certain responses.

MDN's HTTP response header reference explains these and other headers. OWASP's HTTP security header testing guidance provides additional context for reviewing configuration.

A missing header is not automatically proof of an exploitable vulnerability. Its relevance depends on the application, the threat, and the surrounding configuration.

Also remember what this command actually checks: one response from the root endpoint. It does not inspect every page, API, authenticated area, or application behavior.

Step 5: Review TLS and certificate information

HTTPS depends on Transport Layer Security (TLS) to protect connections between clients and servers.

For an endpoint you own, the following command can display information about the certificate presented during the TLS connection:

openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

Review the certificate's subject, issuer, and validity dates. Then consider whether the certificate covers the intended hostname and whether the service's TLS configuration meets your requirements.

For a fuller perspective on secure TLS configuration, read the OWASP Transport Layer Security Cheat Sheet.

Certificate metadata alone does not establish that the entire deployment is secure. A deeper assessment may need to examine protocol support, certificate-chain validation, and additional configuration details.

CyberSurfaceMap collects TLS and certificate metadata alongside HTTP and HTTPS response information. The documented scanner uses lightweight requests to the root endpoint; it is not a full website crawl.

Step 6: Check what your DNS records say about email security

Email-related DNS records can provide useful evidence about a domain's published authentication configuration.

For example, SPF records are commonly published in TXT records:

dig example.com TXT +short

DMARC records are typically queried at _dmarc:

dig _dmarc.example.com TXT +short

Look for SPF values beginning with v=spf1 and DMARC values beginning with v=DMARC1.

These records help describe how a domain publishes email authentication policies, but the presence of a record does not prove that every email is authentic or that the entire email system is configured correctly. DKIM checks can also require knowing the relevant selector.

A compromised, legitimate mailbox can still be used to send fraudulent messages. That is why technical evidence must be considered alongside the context of the request and, where appropriate, independent verification.

CyberSurfaceMap extracts SPF information and queries DMARC records as part of its DNS intelligence workflow. For a more complete explanation, see SPF, DKIM, and DMARC Explained.

For suspicious messages, these additional guides are useful:

• How to Read Email Headers
• How to Detect Email Spoofing Before You Pay

Step 7: Turn observations into decisions

You've now gathered several types of evidence. The next challenge is deciding what deserves attention first.

Imagine your review identifies three observations:

• An unfamiliar subdomain appears in publicly observable certificate records.
• Your domain publishes an email policy record that you don't fully understand.
• Your website returns a security header that differs from your preferred configuration.

Treat these as investigation items—not three confirmed vulnerabilities.

For each item, record:

Evidence: What exactly was observed, and when?

Context: Is the asset or configuration expected? Who owns it?

Impact: What could happen if the issue is genuinely relevant?

Confidence: Has the observation been verified, or is further evidence needed?

Action: Should you remediate a configuration, confirm ownership, or perform an authorized follow-up check?

Risk assessment helps organize this work, but it should not replace judgment. A public DNS record may be entirely appropriate, while a seemingly minor configuration issue may matter considerably in a particular application.

CyberSurfaceMap normalizes scanner output into structured findings and evaluates them to produce a risk score, level, and contributing factors. The score is an aid for organizing investigation; it is not a guarantee that every possible weakness has been identified.

You can read the CyberSurfaceMap security assessment methodology for details about the supported checks, how findings are handled, and the limitations of the assessment.

A repeatable 20-minute starting checklist

For an authorized domain, start with these steps:

• Confirm that the domain and any assets being reviewed are in scope.
• Compare A and AAAA records with your expected infrastructure.
• Review relevant DNS records and identify unexplained configurations.
• Check passive sources for candidate subdomains.
• Inspect the root HTTP/HTTPS response and redirect behavior.
• Review available TLS certificate information.
• Check SPF and DMARC records where email authentication is relevant.
• Document findings, confidence, ownership, and next actions.
• Verify important findings before treating them as vulnerabilities.

Twenty minutes is a starting estimate, not a guarantee. Large or complex environments require more time and a more comprehensive inventory.

If you'd prefer to bring several of these public signals into one workflow, explore CyberSurfaceMap. It is designed to collect domain, DNS, passive subdomain, HTTP/HTTPS, TLS, and security-header intelligence and organize the resulting findings for review.

Final thoughts

A useful domain security assessment is not the one that produces the longest report. It is the one that helps you understand what is visible, distinguish facts from assumptions, identify which observations matter, and determine what to do next.

Start with assets you are authorized to review. Collect evidence carefully. Verify the important findings. Keep the inventory current.

The objective is not to prove that a domain is perfectly secure. It is to reduce uncertainty and make better-informed defensive decisions.