example.com
This domain does not receive email, so the scan checks that nobody can send email in its name.
Grade B, 87 of 100
Scanner version 1.0.0
Grade B
Checked 2 hours ago, 23 October 2026 at 18:49. Checked 23 October 2026 at 18:49.
A Cloudflare bot check runs when you press Check now. Read the privacy notice
Scores
Website
75%
- DNSSEC100%
- HTTPS50%
- IPv6not yet scored
- RPKInot yet scored
100%
- Authentication100%
- Secure transportnot yet scored
- IPv6not yet scored
- RPKInot yet scored
A good setup with some gaps worth closing.
7 passed, 0 to look at, 2 failing, 6 recommendations, 0 not checked
Fix these first
- Redirect from HTTP to HTTPSSet a permanent (301) redirect from
http://tohttps://on the same address first, and only then to another address (for example fromexample.comtowww.example.com). - HSTS: always use HTTPSSend the header
Strict-Transport-Security: max-age=31536000; includeSubDomainsonce HTTPS works everywhere.
2 passed, 0 to look at, 0 failing, 0 recommendations, 0 not checked
One valid SPF record that ends in -all.
Why it matters
SPF lists the servers allowed to send email from your domain. Without it, anyone can send mail that claims to come from you, and your real mail lands in spam more often.
What the scan saw
record: v=spf1 -all lookups: 0 all: -all
NIS2 Art. 21(2): (g) Cyber hygiene; (j) Secured communications
Policy reject: receivers act on forged email. No reports are requested (rua), so you will not see who sends in your name.
Why it matters
DMARC tells receiving mail servers to quarantine or reject email that fails SPF and DKIM checks for your domain. It is the main defence against invoice fraud and phishing in your name.
What the scan saw
record: v=DMARC1;p=reject;sp=reject;adkim=s;aspf=s
NIS2 Art. 21(2): (g) Cyber hygiene; (j) Secured communications
Does not apply: the domain does not receive email.
Why it matters
DKIM signs outgoing email so receivers can tell it really came from you and was not changed. DMARC needs SPF or DKIM to pass, and DKIM survives forwarding where SPF does not.
NIS2 Art. 21(2): (g) Cyber hygiene; (j) Secured communications
Does not apply: the domain does not receive email.
Why it matters
Mail between servers is often encrypted only if nobody interferes. MTA-STS tells sending servers to require encryption and a valid certificate when they deliver to you.
NIS2 Art. 21(2): (h) Cryptography and encryption; (j) Secured communications
Does not apply: the domain does not receive email.
Why it matters
TLS reports tell you when other mail servers fail to deliver to you securely, for example because of a broken certificate or an attack on the connection.
NIS2 Art. 21(2): (j) Secured communications
3 passed, 0 to look at, 2 failing, 5 recommendations, 0 not checked
The website works over HTTPS.
Why it matters
Without working HTTPS, visitors see warnings, and passwords and form data can be read on the way. Browsers and search engines treat sites without HTTPS as unsafe.
What the scan saw
url: https://example.com/ status: 200
NIS2 Art. 21(2): (h) Cryptography and encryption
The website is served over plain HTTP (status 200) without a redirect to HTTPS.
How to fix
Set a permanent (301) redirect from http:// to https:// on the same address first, and only then to another address (for example from example.com to www.example.com). Otherwise browsers never get the HSTS header for this address. Cloudflare: SSL/TLS, Edge Certificates, Always Use HTTPS. WordPress: set the site address to https:// and turn on the host's HTTPS redirect.
Why it matters
Many visitors still type the address without https://. A permanent redirect sends them to the secure site straight away, before anything can be intercepted.
What the scan saw
hops: [{"url":"http://example.com/","status":200,"location":null}]
NIS2 Art. 21(2): (h) Cryptography and encryption
No HSTS header.
How to fix
Send the header Strict-Transport-Security: max-age=31536000; includeSubDomains once HTTPS works everywhere. Cloudflare: SSL/TLS, Edge Certificates, HSTS. On your own server, add it in the web server or CMS settings.
Why it matters
HSTS tells browsers to use only HTTPS for your site from then on, so an attacker on public Wi-Fi cannot quietly switch a visitor to plain HTTP.
NIS2 Art. 21(2): (h) Cryptography and encryption
example.com is not on the HSTS preload list. It cannot be submitted yet, because the first response from https://example.com/, before any redirect, has no HSTS header.
What you can do
To join, send Strict-Transport-Security: max-age=63072000; includeSubDomains; preload on the main address, redirect plain HTTP to HTTPS on the same address first, check every subdomain, and then submit the domain at hstspreload.org. To leave, remove preload from the header and ask for removal at hstspreload.org/removal. Browsers drop the entry with their later releases, which takes months.
Why it matters
Preloading puts your domain on a list built into browsers. They then use HTTPS for the domain and every subdomain from the first visit, before they have seen your HSTS header. It is close to a one-way commitment: every subdomain, old and internal ones too, must serve HTTPS, and leaving the list takes months. This is a note and does not change your score.
What the scan saw
status: unknown
errors:
response.no_header
redirects.http.no_redirect
cache: {"status":"hit","fetchedAt":"2026-10-23T11:01:47.968Z","source":"hstspreload"}
NIS2 Art. 21(2): (h) Cryptography and encryption
No X-XSS-Protection header. That is correct: browsers no longer use it, and a Content-Security-Policy protects against XSS.
What you can do
Do not send the header, or send X-XSS-Protection: 0. Protect against XSS with a Content-Security-Policy instead.
Why it matters
X-XSS-Protection turned on an XSS filter in old browsers. Browsers have removed that filter, and MDN marks the header as deprecated and points to a Content-Security-Policy instead. The OWASP HTTP Headers Cheat Sheet says: "Do not set this header or explicitly turn it off", because it "can create XSS vulnerabilities in otherwise safe websites". This is a note and does not change your score.
NIS2 Art. 21(2): (e) Secure development and vulnerability handling
No Cross-Origin-Embedder-Policy header. That is fine unless you need cross-origin isolation.
What you can do
Most sites do not need it. To turn on cross-origin isolation (together with Cross-Origin-Opener-Policy: same-origin), first make sure every embedded third-party resource allows it, with Cross-Origin-Resource-Policy or CORS. Test with Cross-Origin-Embedder-Policy-Report-Only, then send Cross-Origin-Embedder-Policy: require-corp.
Why it matters
Cross-Origin-Embedder-Policy is only needed for cross-origin isolation, which some browser features, such as SharedArrayBuffer and precise timers, require. With require-corp, the browser blocks every cross-origin resource that is not marked as allowed, so a site that is not prepared can break. MDN describes the header. The OWASP HTTP Headers Cheat Sheet recommends require-corp and warns that it "will block cross-origin resources not configured correctly". This is a note and does not change your score.
NIS2 Art. 21(2): (e) Secure development and vulnerability handling
No X-DNS-Prefetch-Control header. The browser default suits most websites.
What you can do
You do not need to do anything. To stop the lookups, send X-DNS-Prefetch-Control: off.
Why it matters
X-DNS-Prefetch-Control tells the browser whether to look up the domains of links on the page before a visitor clicks them. It is not a standard. MDN describes it. The OWASP HTTP Headers Cheat Sheet says the browser default "is good for most websites" and suggests off only "if you do not control links on your website". This is a note and does not change your score.
NIS2 Art. 21(2): (e) Secure development and vulnerability handling
No Content Security Policy.
How to fix
Start with Content-Security-Policy-Report-Only to see what breaks, then send Content-Security-Policy with script-src 'self' plus the services you use. Avoid 'unsafe-inline' and 'unsafe-eval'; use nonces or hashes for inline scripts.
Why it matters
A Content Security Policy limits which scripts a page may run. If an attacker injects code into the site, a strict policy stops it from running.
NIS2 Art. 21(2): (e) Secure development and vulnerability handling
The X-Content-Type-Options header is missing.
How to fix
Send X-Content-Type-Options: nosniff on every response. It is one line in the web server or CDN settings.
Why it matters
This header stops browsers from guessing file types, which attackers can abuse to run an uploaded file as a script.
NIS2 Art. 21(2): (e) Secure development and vulnerability handling
Any site can load this website in a frame.
How to fix
Send Content-Security-Policy: frame-ancestors 'self' (or 'none'), or the older X-Frame-Options: SAMEORIGIN.
Why it matters
Another site can load your pages in an invisible frame and trick visitors into clicking buttons they cannot see (clickjacking).
NIS2 Art. 21(2): (e) Secure development and vulnerability handling
No Referrer-Policy. Browsers fall back to a reasonable default, but setting it is safer.
How to fix
Send Referrer-Policy: strict-origin-when-cross-origin, or no-referrer for the strictest setting.
Why it matters
When a visitor follows a link, the browser may tell the other site which page they came from. Full addresses can leak internal paths or tokens.
NIS2 Art. 21(2): (e) Secure development and vulnerability handling
No software versions are shown.
Why it matters
Version numbers in headers and page code tell attackers exactly which known vulnerabilities to try. Hiding them does not fix old software, but it stops easy automated targeting.
NIS2 Art. 21(2): (e) Secure development and vulnerability handling; (g) Cyber hygiene
The homepage sets no cookies.
Why it matters
Cookies often hold the login session. Without Secure, HttpOnly and SameSite they can be sent over plain HTTP, read by scripts or sent along with forged requests.
NIS2 Art. 21(2): (h) Cryptography and encryption
No security.txt file.
How to fix
Publish https://<your domain>/.well-known/security.txt with a Contact: line (email or web form) and an Expires: date less than a year ahead, for example Expires: 2027-10-01T00:00:00Z. Renew it before it expires.
Why it matters
security.txt tells people who find a security problem how to reach you. Without it, warnings often go nowhere.
What the scan saw
url: https://example.com/.well-known/security.txt status: 404
NIS2 Art. 21(2): (e) Secure development and vulnerability handling
The certificate from SSL Corporation is valid for 63 more days (until 25 December 2026).
Why it matters
When the website's certificate expires, browsers block the site with a full-page warning until it is renewed.
What the scan saw
source: rynir
notAfter: 2026-12-25T22:56:35.000Z
daysLeft: 63
issuer: CN=Cloudflare TLS Issuing ECC CA 3,O=SSL Corporation,C=US
tlsVersion: TLS1.3
verification: {"valid":true,"code":"ok","message":""}
cache: {"status":"miss","fetchedAt":"2026-10-23T18:49:53.737Z","source":"rynir"}
NIS2 Art. 21(2): (h) Cryptography and encryption; (c) Business continuity
2 passed, 0 to look at, 0 failing, 1 recommendation, 0 not checked
The domain is signed with DNSSEC and validates.
Why it matters
DNSSEC signs your DNS records, so nobody can send visitors or email to a fake address by forging DNS answers.
What the scan saw
states: secure secure ds: 2371 13 2 c988ec423e3880eb8dd8a46fe06ca230ee23f35b578d64e78b29c3e1c83d245a
NIS2 Art. 21(2): (g) Cyber hygiene
No CAA records: any certificate authority may issue for this domain.
How to fix
Add CAA records for the authorities you use, for example 0 issue "letsencrypt.org". Cloudflare adds its own authorities automatically when you create CAA records there.
Why it matters
CAA records name the certificate authorities allowed to issue certificates for your domain, which makes a wrongly issued certificate less likely.
What the scan saw
names: example.com
NIS2 Art. 21(2): (h) Cryptography and encryption
The domain is registered until 13 August 2027, 293 days from now.
Why it matters
If the registration lapses, the website and email stop working and someone else can register the name.
What the scan saw
source: rdap
url: https://rdap.verisign.com/com/v1/domain/example.com
expiry: 2027-08-13T04:00:00.000Z
registrar: RESERVED-Internet Assigned Numbers Authority
cache: {"status":"hit","fetchedAt":"2026-10-23T11:01:48.342Z","source":"rdap"}
NIS2 Art. 21(2): (c) Business continuity