Observed
The requested public signal met the specifically evaluated condition. This does not prove correct operation throughout the business.
Free Website, Email & Domain Check
Check your website, domain, and email public signals.
Run a public-signal check for core website, browser-header, and email control presence. No login, credential testing, exploit testing, or port scanning.
Public-signal progress
Ready for a safe public check
Start with a quick public website and email signal check. No login, exploit testing, port scanning, or credential testing.
Ready. Enter a domain to start the public check.
- 1Checking HTTPS reachability
- 2Checking HTTP to HTTPS redirect
- 3Checking security headers
- 4Checking DNS/email signals
- 5Checking SPF/DMARC indicators
- 6Preparing public-signal summary
Need more than public signals?
The Free Website, Email & Domain Check is a quick public website and email signal check. The $199 Website, Email & Domain Security Snapshot adds an 11-check review, a plain-English report, prioritized findings, recommended fix order, and vendor-ready next steps.
Public DNS lookups
Safe HTTPS header requests
No login or exploit testing
Public-signal only. We perform DNS lookups for SPF, DMARC, MX, and DNSSEC, plus safe HTTP/HTTPS header requests to confirm core controls and passive observations. No login attempts. No exploit testing. No port scanning. No credential testing. No data submitted to the scanned domain except a basic website request where applicable.
How to read your result
The result count is not a security verdict. It shows which defined public-facing controls were observed during completed checks. Configuration concerns and controls not observed may need provider review; not-checked or needs-verification states are not treated as failed controls.
Observed
the requested public signal met the specifically evaluated condition
Configuration concern
public evidence exists, but the configuration has a concern
Not observed
the lookup completed without observing the requested control
Not checked
the check lacked reliable data and is not counted as failed
Needs verification
some evidence exists, but the complete control could not be validated
Understanding your results
What the public-signal result means
The result shows which defined public website, DNS, email, TLS, and browser-header signals were observed. It is not a security verdict or a full audit.
Configuration concern
Public evidence exists, but the configuration is permissive, incomplete, malformed, duplicated, or otherwise has a configuration concern.
Not observed
The lookup completed without observing the requested control. Confirm ownership and intent before changing the setting.
Not checked
The scanner lacked reliable data or required input. This state is not counted as a failed control.
Needs verification
Some public evidence exists, but the complete control or operational outcome could not be validated safely.
Security headers
What common website security headers do
Headers are browser instructions. They help reduce common web risks, but they must be added with testing and context.
HSTS
Strict-Transport-Security tells browsers to keep using HTTPS after a secure visit. It should be enabled only after HTTPS is stable.
Content Security Policy
CSP controls where scripts, images, styles, frames, and other content can load from. It is powerful but must be tested so it does not break forms, payments, or widgets.
X-Frame-Options / frame-ancestors
Frame protection reduces the chance of the site being embedded inside a deceptive page. Modern CSP frame-ancestors can serve the same purpose.
X-Content-Type-Options
This helps browsers avoid guessing file types in unsafe ways. It is a small but useful hardening header.
Referrer-Policy
This controls how much page and URL information is shared when someone clicks away from the site.
Permissions-Policy
This limits browser features like camera, microphone, location, USB, or payment APIs when the site does not need them.
COOP, COEP, and CORP
These advanced isolation headers can help some applications, but they are not always needed for simple small-business sites and can affect embedded content.
CORS
CORS controls which websites can read browser responses from a site or API. Broad CORS settings should be reviewed with the developer.
TLS, email authentication, and domain context
How TLS, SPF, DKIM, DMARC, WHOIS, and DNS fit together
These signals live across your website host, CDN, DNS provider, registrar, and email platform. The right fix depends on who owns each setting.
TLS and certificates
TLS powers HTTPS. Owners should watch for certificate expiration, wrong-domain certificates, redirect loops, and old provider handoff problems.
TLS versions and cipher suites
Modern platforms usually manage TLS versions and cipher suites. If a scanner reports weak settings, the fix may belong with the host, CDN, or proxy provider.
OCSP and certificate status
Certificate status checks can help browsers learn whether a certificate was revoked. Many small-business owners rely on managed hosting or CDN defaults here.
SPF
SPF lists services allowed to send mail for the domain. Review all legitimate senders before tightening the policy.
DKIM
DKIM signs outgoing mail from providers such as Google Workspace, Microsoft 365, marketing tools, and transactional email services. Selectors vary by provider.
DMARC
DMARC tells receivers what to do when mail fails SPF or DKIM alignment. Move toward stronger enforcement only after legitimate senders are aligned.
WHOIS and registrar context
WHOIS can show registrar and registry context, but privacy services may hide contacts. Owners should still document renewal, auto-renew, DNSSEC, and registrar access internally.
DNSSEC and CAA
DNSSEC and CAA can add useful domain assurance, but they are provider-dependent and should be changed carefully to avoid website or email disruption.
Common issues
Common reasons the free check finds review items
Most findings are configuration or ownership questions. They should be reviewed calmly with the provider that controls the setting.
Website cannot be reached over HTTPS
Start with DNS, hosting, certificate, redirect, and CDN ownership before interpreting missing headers.
HTTP does not redirect to HTTPS
Ask the website host, platform, CDN, or developer to send visitors to the HTTPS version consistently.
CSP is missing or loose
CSP is valuable but site-specific. Add or tighten it with testing so forms, booking widgets, checkout, analytics, and images still work.
SPF configuration concern
Softfail and long include chains are common. Confirm all legitimate senders before removing services or switching to hardfail.
DMARC is missing or monitoring only
A monitoring policy is a common starting point. Review reports and DKIM alignment before moving toward quarantine or reject.
Ownership is unclear
If nobody knows who controls DNS, registrar, email, website host, CDN, or forms, fix ownership documentation before making broad changes.
How to improve
Practical improvement sequence
Use this order to avoid breaking a working site while improving public signals.
- 1Confirm the domain, DNS host, registrar, website host, CDN, and email provider.
- 2Fix reachability and HTTPS before interpreting individual security headers.
- 3Review SPF, DKIM, and DMARC together instead of changing one record in isolation.
- 4Ask the website host, CDN, or developer to add missing browser headers safely.
- 5Document who owns each setting and what changed after a fix is made.
- 6Rerun the free check after changes are live, then use the Snapshot if you need prioritized business context.
Owner checklist
What to collect before asking for help
- Domain registrar and DNS provider
- Website host, CDN, and platform
- Email provider and all approved senders
- SPF, DKIM, and DMARC ownership
- Certificate/TLS owner and renewal path
- Known vendor, insurance, or questionnaire deadline
Related CyberBit tools
Use the right check for the question
Business Email Trust Check
Review public MX, SPF, DMARC, TLS-RPT, DNSSEC, DKIM verification needs, and a published MTA-STS policy.
Vendor Access & Ownership Check
Create a browser-only checklist for domain, vendor, workspace, recovery, and backup ownership.
IP, DNS & WebRTC Connection Check
Review public IP and browser signals, then compare factual changes after switching networks.
Tool limitations
What this free check cannot determine
What this tool cannot determine
- Private admin pages, dashboards, intranets, databases, source code, or customer records.
- Whether the website has malware, vulnerable plugins, or exploitable application bugs.
- Whether passwords, MFA, backups, endpoint security, or staff access are configured correctly.
- Full DKIM validation when selector names are unknown.
- WHOIS ownership certainty when privacy services, resellers, or old vendors are involved.
- Compliance status, cyber insurance approval, vendor approval, or breach prevention.
Frequently asked questions
Is this a penetration test?
No. This is public-signal review only. It does not include exploit testing, credential testing, malware scanning, or port scanning.
Will this affect my website?
No. The scan uses public DNS lookups and a basic website request where applicable. It is designed to be lightweight and safe.
What does Observed mean?
Observed means the signal was visible publicly during the check. It is good context, but it is not a guarantee that the control is perfectly configured.
What does Configuration concern mean?
A public record or control was observed, but the configuration is permissive, incomplete, malformed, duplicated, or otherwise has a concern that should be reviewed before changes are made.
What does Not observed mean?
The lookup completed, but the requested public signal was not observed. Confirm ownership and intent with the provider before changing the setting.
What does Not checked mean?
The check lacked reliable data or required input. It is excluded from the completed-check count and is not treated as a failed control.
What does Needs verification mean?
Some public evidence was observed, but the complete control or operational outcome could not be validated safely.
Does this check DKIM?
The free check focuses on public MX, SPF, and DMARC signals. DKIM often requires known selector names, so CyberBit treats DKIM as a deeper review item.
Does this check WHOIS?
This free scan focuses on DNS, website, TLS, email, and header signals. WHOIS and registrar ownership are important context, but they usually need owner confirmation and registrar review.
Can this prove my site is secure?
No. A strong score means core public signals were visible. It does not prove the site, users, passwords, plugins, hosting, backups, or internal systems are secure.
Why do I need a Snapshot if the scan is free?
The Free Website, Email & Domain Check confirms visible public website and email signals. The $199 Website, Email & Domain Security Snapshot adds 11 defined checks, a plain-English report, prioritized findings, recommended fix order, and vendor-ready next steps.
Who should fix issues this finds?
It depends on ownership. DNS and email records usually belong with the DNS/email provider. Headers and TLS usually belong with the website host, CDN, or developer.
When should I contact CyberBit?
Contact CyberBit when you need help interpreting results, deciding what to fix first, or translating findings into vendor-ready next steps.