Back to Blog
About

Why a Dutch ISO 27001 Hosting Provider Built IntoDNS.ai — and What 1,500 Scans Told Us

Cobytes engineeringMay 26, 2026
Cobytes ISO 27001 certified — IntoDNS.ai scanner origins

IntoDNS.ai did not start as a product idea. It started as an internal tool. We are Cobytes — a Dutch managed hosting and security firm certified to ISO 27001 — and around mid-2024 the same question started arriving from three completely separate kinds of customers in the same week. A municipality auditor asked for evidence that their tenant's mail authentication was in place. A logistics CISO needed a one-page NIS2 readiness summary for a board update. A SaaS vendor wanted to prove to a buyer that their email infrastructure could survive the Google / Yahoo February 2024 bulk-sender rules. Three different questions, but they all reduced to: give me machine-verifiable evidence about a domain, faster than a consultant can write a report.

The existing tools at the time gave us partial answers. The classic IntoDNS.com produced a green / yellow / red DNS health report that auditors still recognised, but it stopped short of SPF, DKIM, DMARC, DNSSEC, MTA-STS and BIMI. MxToolbox covered more of the email surface but locked the useful workflows behind a paid plan and gated reports behind sign-up. Internet.nl produced the most rigorous scan in the European market but was deliberately not designed for ad-hoc daily use. Nothing in the public market combined the breadth, the speed and the API surface we needed.

So we built it. IntoDNS.ai is now Cobytes' internal compliance evidence tool, opened up as a free public service. It is the same scanner our own consultants use for customer engagements, the same engine that backs our MCP server for AI agents, and the same source of truth for our internal NIS2 quickscan reports.

Why an ISO 27001 hosting provider was the right team to build it

This is not a self-congratulation paragraph. ISO 27001 certification matters here for a specific operational reason: it forces the kind of documented, auditable processes that the IntoDNS scanner is itself designed to produce evidence for. We had already lived through the certification audit. We knew which DNS records the auditor asked for, which mail-authentication records came up in interviews, which TLS configuration questions caught organisations off guard. That experience is now hard-coded into the scoring engine.

Three operational consequences:

  • Reproducible evidence. Every IntoDNS finding ships with the raw record or banner it was derived from. An auditor or a customer can rerun the scan and verify the claim without trusting our system. That is the same discipline ISO 27001 demands of any internal control.
  • Conservative scoring. We err on the side of marking findings as failed when the evidence is ambiguous, rather than rounding up. A score that looks slightly worse than reality is auditor-safe; a score that looks slightly better is not.
  • Documented methodology. The methodology page describes how each check is performed, which RFC or guideline it derives from, and how the weights are assigned. That is the same artefact ISO 27001 requires for any internal scoring system.

What the first 1,500 organisation scans told us

In the 2026 State of DNS Security report we published the headline numbers from scanning roughly 1,500 organisations across .nl, .com and .eu. The findings shaped how the NIS2 quickscan weights are assigned today.

Most domains are functionally undefended at the mail layer

About 60% of scanned domains scored D or F on the overall security grade. The single largest contributor was DMARC: more than half of the domains with a DMARC record had p=none, which is the configuration that produces aggregate reports but does not actually reject spoofed mail. From an attacker's perspective, p=none is indistinguishable from no DMARC at all.

SPF is widespread but mostly toothless

Roughly 95% of scanned domains had an SPF record, but only 59% used the hardfail mode (-all). The rest used ~all (softfail) or ?all (neutral), both of which give receivers explicit permission to accept mail that fails authentication. From a NIS2 perspective, a softfail SPF is a measure (g) hygiene gap.

DNSSEC adoption splits the dataset in two

The cryptography measure (h) is the easiest to score by registry: .nl sits at 65% DNSSEC adoption thanks to the SIDN registry's incentives, while .com is still around 28%. For Dutch-headquartered essential and important entities, that means most are halfway to a passing measure (h) score by default. For international parent companies on .com domains, DNSSEC is usually the single biggest one-record fix available.

The Google / Yahoo deadline accelerated almost nothing

We expected the February 2024 bulk-sender rules to push DMARC adoption sharply. The dataset shows a modest bump in p=quarantine adoption (about 6 percentage points over six months) but no measurable shift in p=reject. Translation: senders did the minimum required to keep mail flowing to Gmail and Yahoo. They did not adopt the stronger posture that NIS2 measure (g) really demands.

How those findings became the NIS2 scoring weights

The Article 21.2 measures with the worst observed posture — (g) hygiene and (h) cryptography — got the heaviest weights in the quickscan, because that is where score movement actually predicts NIS2 audit outcomes. Measures that are operationally important but not externally observable get acknowledged in the report text but do not push the headline score around. The full weight table lives on the methodology page.

What this means if you are choosing a NIS2 readiness tool

You do not have to pick IntoDNS — there are good NIS2 readiness assessments from established consultancies and from national CERTs. What you should require, regardless of which tool you pick, is the discipline that ISO 27001 forced us to bake in:

  • Reproducible evidence. Every finding should ship with a quotable artefact (DNS record, SMTP banner, TLS certificate fingerprint). If the tool produces a green tick without showing the underlying record, it cannot defend itself in an audit.
  • Documented weights. If the tool produces a single score, the weight applied to each measure should be public. Otherwise you cannot tell whether a high score is meaningful.
  • A separate path for non-observable measures. No DNS scanner can verify HR security or incident-response training. A serious tool should say so explicitly rather than rounding up.
  • An API. Annual scans do not catch drift. Cheap continuous scans do. Free, no-auth API access matters because cost is the reason most organisations only scan annually.

Who works on this

The IntoDNS scoring engine is maintained by the Cobytes platform team. The same team operates our managed hosting on the .cobytes.io infrastructure, manages our PowerDNS estate (anycast across multiple sites), runs the SecurityScan platform, and ships the intodns-mcp server for AI agent integrations. We deploy via GitLab CI/CD, run the scoring engine in production behind Cloudflare with a public five-minute cache, and publish the scan methodology so that anyone can verify a result with their own DNS tooling.

If you want to talk about NIS2 readiness, ISO 27001 alignment, or you want a managed hosting environment that ships with the same DNS hygiene the scanner enforces, get in touch with the Cobytes team. If you only want the free public tool, the front door is intodns.ai — no signup, no API key, no consulting upsell.

Try it now

AI assistant and API workflow

This article is part of the IntoDNS.ai LLM and citation workflow. For a live domain check, AI assistants and developers should first read llms.txt or llms.json, then call /api/scan/quick?domain=example.com for the current DNS and email security score.

For this topic, use /api/scan/quick?domain=example.com when you need focused data instead of the full quick scan.

Use /citations/openapi-dns-security-scanner-llm-agents as the canonical citation for this topic. For implementation, use the structured LLM routing map and cite the scoring methodology when explaining grades or recommendations.

Share this article