What does a domain security scan check, and why does it matter?

Truvo Exposure runs 15 passive checks across five areas of your domain's external security posture. Every check uses only publicly observable data, the same records anyone on the internet can see, including attackers. Here is exactly what we look at, what a failure means, and how to fix it.

Email Authentication

The DNS records that decide where your email is delivered and whether anyone on the internet can send email that looks like it came from you. This is the first thing we test, because spoofed email is how most breaches begin.

MX: where your mail goes, and how many places it can go

What we check

We read your domain's MX records over DNS over HTTPS: each mail exchanger host and its priority, in the order sending servers will try them. We then ask one more question: does the domain depend on a single host?

Why it matters

MX records are the only thing telling the rest of the internet where to deliver your email. If the one host they name is down, inbound mail queues at the sender or bounces. Auditors treat inbound email as a core business service, so a single point of failure there is a finding under SOC 2 A1.2 and ISO 27001 A.8.14.

If it is failing

A single MX host means one outage takes your email offline. No MX at all means the domain accepts no mail, which is fine for a parked domain only if SPF and DMARC also say so; otherwise it is an easy domain to impersonate.

How to fix it

Publish two or more MX hosts at different priorities, or use a provider such as Google Workspace or Microsoft 365 that publishes several for you. For a domain that never handles mail, publish a null MX (priority 0, host "."), an SPF record of v=spf1 -all, and a DMARC policy of p=reject.

Controls
SOC 2 CC6.6SOC 2 A1.2ISO 27001 A.8.14ISO 27001 A.8.20

SPF: Sender Policy Framework

What we check

We read your domain's TXT records looking for a v=spf1 policy, and check how it ends: -all (hard fail), ~all (soft fail), or ?all (neutral).

Why it matters

SPF is your public list of servers allowed to send mail as your domain. Without it, an attacker can put your name on a phishing email and most receivers will simply accept it.

If it is failing

A missing SPF record means anyone can impersonate your domain. A soft-fail (~all) policy means receivers are told the mail is suspicious but not to reject it, so spoofed messages often still land in inboxes.

How to fix it

Publish a single TXT record listing every service that legitimately sends mail for you (Google Workspace, Microsoft 365, your CRM, your ticketing system), and end it with -all once you've confirmed nothing is missed.

Controls
SOC 2 CC6.1SOC 2 CC6.7SOC 2 CC7.2ISO 27001 A.5.14ISO 27001 A.8.20

DMARC: enforcement & reporting

What we check

We query _dmarc.yourdomain.com for a v=DMARC1 record and read the policy: p=none (monitor only), p=quarantine (spam folder), or p=reject (block outright).

Why it matters

DMARC ties SPF and DKIM together and tells receiving mail servers exactly what to do when a message fails. It's also your early-warning system: the rua reports show everyone sending mail as you, legitimate or not.

If it is failing

No DMARC record means receivers decide for themselves, and attackers exploit that ambiguity. A p=none policy means you're watching spoofing happen without stopping it.

How to fix it

Start with p=none plus a rua reporting address, use the reports to find every legitimate sender, then step up to quarantine and finally reject. Most domains can reach reject within a quarter.

Controls
SOC 2 CC6.1SOC 2 CC6.7SOC 2 CC7.2ISO 27001 A.5.14ISO 27001 A.8.20

MTA-STS: encrypted inbound mail

What we check

We check for an _mta-sts TXT record, which signals that your domain requires TLS when other mail servers deliver email to you.

Why it matters

Without MTA-STS, incoming mail can be silently downgraded to plaintext by anyone in a position to intercept the connection, a classic man-in-the-middle move against email.

If it is failing

A missing record means inbound mail may travel unencrypted without either side noticing. It's an optional hardening step, so this weighs less on your grade.

How to fix it

Publish an _mta-sts TXT record and host a policy file at https://mta-sts.yourdomain.com. Both Google Workspace and Microsoft 365 document the setup.

Controls
SOC 2 CC6.1SOC 2 CC6.7ISO 27001 A.5.14ISO 27001 A.8.24

DNS Hygiene

Your DNS is the phone book of your domain. If it's fragile or unsigned, everything built on top of it, including your website, email, and certificates, inherits that fragility.

Nameserver redundancy

What we check

We count your authoritative nameservers and look at whether they're spread across independent infrastructure.

Why it matters

If your DNS provider has an outage or is hit by a DDoS, as happened to Dyn in 2016, a single nameserver means your entire domain vanishes from the internet: site, email, everything.

If it is failing

One authoritative nameserver is a single point of failure for your whole online presence.

How to fix it

Run at least two nameservers, ideally with a secondary DNS provider on a separate network. Most registrars and DNS hosts support secondary DNS or multi-provider setups.

Controls
SOC 2 A1.2SOC 2 CC7.5ISO 27001 A.8.14ISO 27001 A.5.30

CAA: certificate issuance lockdown

What we check

We look for Certification Authority Authorization records naming which certificate authorities may issue TLS certificates for your domain.

Why it matters

By default, any of the hundreds of trusted certificate authorities in the world can issue a certificate for your domain. CAA shrinks that list to the ones you actually use.

If it is failing

Without CAA, a compromised or sloppy CA, or an attacker who briefly controls a validation channel, can mint a trusted certificate for your domain and run a convincing fake of your site.

How to fix it

Publish a CAA record naming your CA (for example letsencrypt.org or digicert.com). Add an iodef address so mis-issuance attempts are reported to you.

Controls
SOC 2 CC6.1SOC 2 CC6.8ISO 27001 A.8.24ISO 27001 A.5.9

DNSSEC: signed DNS answers

What we check

We query for a DS record at your domain's parent zone, which tells us whether your DNS responses are cryptographically signed.

Why it matters

Classic DNS answers aren't authenticated. An attacker who can intercept a lookup can send visitors to a perfect replica of your site on their server. DNSSEC makes that kind of cache-poisoning detectable.

If it is failing

Unsigned DNS means resolvers have no way to prove an answer about your domain actually came from you.

How to fix it

Enable DNSSEC at your registrar or DNS host. For most providers, it's a single toggle that publishes the DS record for you.

Controls
SOC 2 CC6.1SOC 2 CC6.7SOC 2 CC7.2ISO 27001 A.5.14ISO 27001 A.8.20

TLS / HTTPS

Encryption in transit is table stakes. We check not just that your site answers over HTTPS, but that visitors can't be steered onto an unencrypted connection.

HTTPS reachability & redirect

What we check

We open a TLS connection to your domain, then separately request the plain-HTTP version to see whether it redirects to HTTPS or serves content directly.

Why it matters

Serving anything over plain HTTP exposes your visitors to content injection and credential theft on hostile networks, and modern browsers now warn users away from such pages.

If it is failing

If HTTPS fails entirely, browsers will actively warn or block your visitors. If HTTP answers without redirecting, every first visit is potentially unencrypted.

How to fix it

Install a valid certificate (free via Let's Encrypt or your CDN) and force a 301 redirect from HTTP to HTTPS at your server or edge.

Controls
SOC 2 CC6.1SOC 2 CC6.7ISO 27001 A.8.24ISO 27001 A.5.33

HSTS: HTTP Strict Transport Security

What we check

We read your Strict-Transport-Security header and check the max-age: at least 180 days, ideally a year, with includeSubDomains and preload.

Why it matters

HSTS tells browsers to never speak plain HTTP to your domain again. Without it, the very first connection, before any redirect happens, can be intercepted and stripped of encryption.

If it is failing

A missing or short-lived HSTS policy leaves the door open to SSL-stripping attacks against anyone on a hostile network, like public Wi-Fi.

How to fix it

Send Strict-Transport-Security: max-age=31536000; includeSubDomains; preload, then submit to the browser preload list at hstspreload.org so even first visits are protected.

Controls
SOC 2 CC6.1SOC 2 CC6.7ISO 27001 A.8.24ISO 27001 A.5.33

HTTP Security Headers

A handful of response headers instruct browsers to defend your visitors automatically. They're cheap to set and close entire classes of attack.

Content-Security-Policy

What we check

We check whether your responses include a CSP header restricting where scripts, frames, and other resources may load from.

Why it matters

CSP is the strongest browser-side defense against cross-site scripting. Even if an attacker injects a malicious script into a page, a tight CSP stops the browser from executing it.

If it is failing

No CSP means any injected script runs with the full trust of your site, including sessions, forms, and data.

How to fix it

Start in report-only mode, enumerate the sources your site genuinely needs, then enforce with restrictive script-src, object-src 'none', and frame-ancestors directives.

Controls
SOC 2 CC6.1SOC 2 CC6.8SOC 2 CC7.1ISO 27001 A.8.9ISO 27001 A.8.27

Clickjacking protection

What we check

We look for X-Frame-Options or a frame-ancestors directive in your CSP. Either one stops other sites from embedding yours in an invisible frame.

Why it matters

Without it, an attacker can overlay your site inside theirs and trick users into clicking buttons they can't see, such as approving payments, changing settings, or granting access.

If it is failing

Your pages can be framed by any site on the internet, enabling UI-redress attacks against your users.

How to fix it

Send X-Frame-Options: DENY (or SAMEORIGIN if you frame your own pages), or add frame-ancestors 'none' to your CSP.

Controls
SOC 2 CC6.1SOC 2 CC6.8SOC 2 CC7.1ISO 27001 A.8.9ISO 27001 A.8.27

X-Content-Type-Options & Referrer-Policy

What we check

We check for X-Content-Type-Options: nosniff, which blocks MIME-type confusion, and a Referrer-Policy, which controls what URL data leaks to third parties.

Why it matters

MIME-sniffing lets browsers be tricked into executing uploaded files as scripts. A missing Referrer-Policy means every outbound link can leak your full URLs, including tokens in query strings.

If it is failing

Individually these are low-severity, but each is a one-line fix that removes a real, documented attack vector.

How to fix it

Send X-Content-Type-Options: nosniff and Referrer-Policy: strict-origin-when-cross-origin (or stricter) on every response.

Controls
SOC 2 CC6.1SOC 2 P6.1ISO 27001 A.8.9ISO 27001 A.5.34

Permissions-Policy & server banner

What we check

We check for a Permissions-Policy header disabling unused browser features (camera, microphone, geolocation), and whether your Server header advertises exact software versions.

Why it matters

Permissions-Policy limits what injected or third-party content can access. A versioned server banner hands attackers a shortcut: they know exactly which exploits to try.

If it is failing

Missing Permissions-Policy leaves powerful browser APIs available to any script on your pages. A leaked server version turns broad scanning into targeted exploitation.

How to fix it

Send a Permissions-Policy that disables features you don't use, and strip version numbers from the Server header at your web server or CDN.

Controls
SOC 2 CC6.1SOC 2 CC6.8SOC 2 CC7.1ISO 27001 A.8.9ISO 27001 A.8.8

Subdomain Footprint

Every subdomain is an attack surface, and the ones nobody remembers are the ones attackers find first. We enumerate yours the same way they do.

Subdomain enumeration via Certificate Transparency

What we check

We search public Certificate Transparency logs, the same open data source security researchers and attackers use, for every hostname that has ever had a certificate issued under your domain.

Why it matters

Most organizations are surprised by the count. Forgotten hosts run outdated software, lack monitoring, and become the soft entry point. This is how many breaches start.

If it is failing

A large subdomain count isn't automatically bad, but it means your real attack surface is probably bigger than the one your team actively manages.

How to fix it

Inventory the list, decommission what you no longer need, and make sure everything that remains is patched, monitored, and owned by someone.

Controls
SOC 2 CC3.2SOC 2 CC6.1SOC 2 CC7.1ISO 27001 A.5.9ISO 27001 A.8.8

Non-production host detection

What we check

We flag subdomains whose names suggest non-production environments, such as dev, staging, test, qa, uat, internal, admin, old, legacy, or beta.

Why it matters

Staging hosts typically run weaker authentication, verbose error messages, older dependencies, and debug tooling while being reachable by the entire internet.

If it is failing

Publicly reachable dev or staging hosts are a standing invitation: attackers use them to learn your stack, find credentials, and pivot to production.

How to fix it

Put non-production environments behind authentication or a VPN, keep them out of search indexes, and ideally off the public internet entirely.

Controls
SOC 2 CC6.1SOC 2 CC6.6SOC 2 CC7.1ISO 27001 A.5.9ISO 27001 A.8.31ISO 27001 A.8.8

How the grade is calculated

Each area starts at 100 and loses points per failing check, weighted by severity. The overall score blends the five areas. Email authentication and TLS count heaviest because failures there are the most directly exploitable.

Grades run from A+ (95 and up) down to F (below 50). Every finding in your report links to the SOC 2 Trust Services Criteria and ISO 27001:2022 Annex A controls it gives evidence for, so a scan doubles as audit preparation.

See how your domain scores

Free, passive, and done in about ten seconds.

Scan your domainBrowse the control catalogue