Product

Netskor

Netskor is a passive, external check of a company's domain. It needs nothing but the domain name. Netskor is in development and not yet publicly available.

What Netskor looks at

Netskor reads only what anyone on the internet can see: DNS records, email authentication, the website's HTTPS and security headers, certificate and domain expiry, and security.txt.

The report is in Icelandic first and English second.

Email

5 checks

SPF
DKIM
DMARC
MTA-STS
TLS reporting (TLS-RPT)

Website

10 checks

HTTPS and the website's certificate
The redirect from HTTP
Security headers
Cookies
Exposed software versions
security.txt

DNS and domain

4 checks

DNSSEC signing
Who may issue certificates (CAA)
When the domain registration expires
When the certificate expires

How Netskor works

Your domain
You enter your company's domain.
Netskor reads from outside
Netskor reads public DNS records, the homepage and a few public files. It sends only a handful of requests to the website and says who it is.
You get a report
You get a report with a grade, the three most important fixes and an explanation of every finding.

What Netskor does not do

Netskor does not scan ports, does not try to log in and never tries to exploit a weakness.

Netskor reads public DNS records, the homepage and a few public files. It sends only a handful of requests to the website and says who it is.

Principles

Passive and polite. Only public data is read, with few requests and an honest identity.
Explainable. Every finding shows the data it rests on and the standard it refers to.
Never wrong by silence. What could not be checked is marked as such and not counted.
Actionable. Every problem comes with a concrete way to fix it.
Not a legal opinion. The link to NIS2 is indicative.

What a finding looks like

An example of how a Netskor report words a finding, not a result about a real domain.

DMARC: what happens to forged email

Look at this

Policy none. Forged email is reported but still delivered.

Why it matters: DMARC tells receiving mail servers to reject email that fails SPF and DKIM checks for the domain. It is the main defence against invoice fraud and phishing in the company's name.
How to fix: Fix the senders the reports show, then move to p=quarantine and then p=reject.

HSTS: always use HTTPS

Failing

No HSTS header.

Why it matters: HSTS tells browsers to use only HTTPS for the site from then on, so an attacker on public Wi-Fi cannot quietly switch a visitor to plain HTTP.
How to fix: Send the header Strict-Transport-Security: max-age=31536000; includeSubDomains once HTTPS works everywhere.

Disclaimer

This is an automated, passive external check of publicly visible configuration at the time of scanning. It is not a penetration test, a full audit or legal advice, and does not confirm NIS2 compliance.