What an external scan can see — and what it can't

What an external scan can — and cannot — tell a carrier

External attack surface checks are useful signals, not substitutes for identity, endpoint, and backup evidence. They answer a narrow question: what does the internet see when it looks at your domains, mail authentication, TLS, and common web headers?

For SMB teams without a dedicated security engineer, an external scan is a fast way to discover obvious misconfigurations before renewal. It is also easy to misread: a clean external score does not mean your submission is complete, and a noisy report does not always mean denial.

Callout: Treat external findings as perimeter hygiene, not proof of MFA enforcement, EDR coverage, or restore testing inside your tenant.

Scope of a typical external scan

Responsible external scanning for insurance readiness stays non-invasive. Common modules include:

• DNS — A/AAAA, MX, NS, TXT volume, CAA presence
• Email authentication — SPF validity, permissive `+all` endings, DMARC record and policy, DKIM selector discovery
• TLS — certificate validity, protocol version, expiry horizon
• HTTPS behavior — redirects from HTTP, HSTS presence and max-age
• Security headers — CSP, X-Content-Type-Options, Referrer-Policy, frame controls
• Lightweight fingerprinting — mail provider hints, CDN headers (not a full asset inventory)

Scans may sample subdomains discovered via certificate transparency with strict time and size budgets. Sampling caps exist so a single domain cannot exhaust worker capacity — partial coverage is a feature, not a failure.

Run a structured check through our external scan flow to see how findings are presented without conflating them with internal control proof.

SPF, DMARC, and DKIM in plain language

SPF publishes which senders may mail on your behalf. Underwriters and fraud teams care because spoofing and BEC drive claims. A valid SPF record that ends in a permissive mechanism suggests incomplete mail governance even if mail “works.”

DMARC tells receivers what to do with messages that fail alignment and where to send aggregate reports. A record with `p=none` is a common starting point but is not equivalent to enforcement. Progression toward quarantine or reject with monitoring is a narrative brokers understand when paired with DNS evidence.

DKIM adds cryptographic signatures on outbound mail. Selectors vary by provider; discovery checks multiple common names. Missing DKIM on a domain that sends invoice or wire instructions is a Missing theme in the crosswalk, not something TLS can compensate for.

These three belong in email authentication rows — separate from firewall rules or endpoint agents.

TLS and HSTS: transport vs identity

TLS protects data in motion between clients and your services. Certificate expiry, weak protocols, and hostname mismatches show up quickly on external scans. They do not prove that admin consoles require MFA or that backups are immutable.

HSTS instructs browsers to prefer HTTPS. Absence of HSTS is not always critical for every SMB, but combined with mixed content or weak redirects it signals perimeter inconsistency worth fixing before underwriters ask follow-up questions.

External TLS success does not verify internal service-to-service encryption or VPN configuration — keep those in separate crosswalk rows.

CSP and headers: defense in depth at the edge

Content Security Policy and related headers reduce certain browser-side attacks. Scanners flag unsafe inline script patterns and missing baseline headers. These are good web hygiene indicators for customer-facing properties.

They do not demonstrate patch cadence on laptops, EDR deployment, or logging to a SIEM. Map header findings to web application exposure themes; do not attach them to endpoint rows.

What external scans miss by design

Internal controls — the ones carriers weight heavily — are invisible to DNS and HTTP probes:

• MFA enforcement and user-level exceptions
• EDR coverage and alert handling
• Backup immutability and restore tests
• Privileged access reviews
• Incident response drills

Callout: A strong external score does not imply acceptance, better terms, or claim outcomes. It reduces one class of easy findings brokers might otherwise chase in email threads.

Underwriters may still request tenant exports, MSP letters, or backup logs. External scan output belongs in an appendix, cross-linked from email and web themes, not as a replacement for verified identity evidence.

Interpreting noisy results

External reports often include:

• Benign warnings on marketing microsites with legacy trackers
• Third-party hosted assets outside your direct control
• Stale DNS from retired products

Triage with your MSP: fix what you own, document what is vendor-managed, and update crosswalk statuses instead of arguing with the scanner. Cannot prove becomes Verified when DNS or header changes are shown in dated evidence.

Pairing external and verified internal work

A practical workflow:

1. Run external scan; fix SPF/DMARC/DKIM/TLS/HSTS/CSP issues you control.
2. Draft crosswalk rows for email and web exposure using scan output.
3. Run read-only identity verification for MFA and logging themes.
4. Collect MSP/vendor artifacts for endpoint and backup rows.
5. Package with an index that separates external appendix from tenant-verified sections.

This sequencing prevents the “we fixed DNS so we’re done” trap while still delivering quick wins.

Limits, consent, and responsible use

External scans should respect rate limits, redirect rules, and denylisted domains. Scans are point-in-time; cloud migrations and marketing launches can change DNS overnight. Re-run before submission if material changes occurred.

Do not infer employee behavior, data classification, or regulatory compliance from headers alone. Those require policy and operational evidence.

Side-by-side: external signal vs internal control proof

Use the table internally so sales and leadership do not misread a perimeter report as full verification.

Multi-domain and brand complexity

SMBs often operate multiple domains — corporate, product, legacy acquisitions, campaign microsites. Questionnaires may reference one domain while payroll or AP workflows use another. External scans should cover each domain that sends mail or hosts authenticated apps, not only the public marketing site.

Document domains you do not control (franchise, partner co-brand) as out of scope in the crosswalk rather than implying group-wide coverage.

When to re-run external checks

Re-run after:

• Mail provider migration (SPF/DKIM/DMARC drift)
• Website launch or CDN change (header and TLS shifts)
• Certificate renewal failures reported by customers
• Carrier feedback citing email authentication gaps

Keep prior reports for trend comparison; underwriters notice improvement narratives backed by dated DNS evidence.

Disclaimer your team should internalize

Good external scores correlate with basic internet hygiene, not with comprehensive insurability. Carriers combine external signals with application answers, loss history, industry class, and internal control evidence. No scan vendor can speak for the underwriter’s final appetite.

If external results look strong but identity rows remain Cannot prove, prioritize verification before your broker submits. If external results look weak, fix mail and transport issues first — they are often faster than endpoint projects.

Closing perspective

Use external scanning to illuminate the perimeter and to give brokers concrete DNS and TLS artifacts. Use verified tenant exports and MSP reports to defend identity and operations. Keeping those lanes separate makes your submission clearer and reduces the chance that a glossy external PDF masks internal gaps.

Start with the external scan, then align internal themes via fit check. Overview at Cyber Ready.