internet.nl Test Explained: Check Your Website and Email Security (2026)

Ask a small business owner whether the website is secure and many cannot answer. A paid audit costs money. Doing nothing feels uncomfortable. In the Netherlands there is a free first step: internet.nl.

You enter a domain name, and it reports how closely your website and email follow modern internet standards, as a percentage. It is run jointly by Dutch government and community bodies, and Dutch municipalities and companies use it both for their own checks and to show suppliers and clients. But the results screen is full of abbreviations (IPv6, DNSSEC, HSTS, DMARC, DANE), and it is not obvious who should fix a failed item.

This article reads the Website test and Email test items along two axes: what each one checks, and what to ask your hosting company, domain registrar or email provider when it fails. It also covers how the score works, how to write a security.txt, how to raise DMARC safely, and how all this relates to the public-sector "pas toe of leg uit" list.

Whether the Dutch cybersecurity act (Cbw, the national law implementing NIS2) applies to you is covered in "The Dutch Cybersecurity Act (NIS2) and your SME website". What happens to email when you move domain or server is in "Moving your domain and server during a website redesign". This article sits between them: measure where you stand today, for free.

Main sources: internet.nl's About page, its "Explanation of test report" and badge pages, sample Website and Email test reports, Forum Standaardisatie's pas-toe-of-leg-uit pages and standards list, and RFC 9116. All checked on 1 November 2026.

1. What internet.nl is and what it tests

internet.nl is run by the Internet Standards Platform, a collaboration between internet community parties and the Dutch government. ECP provides its administrative home, the Internet Society Netherlands chapter provides the domain name, and NLnet Labs laid the foundation for the tool. Since 1 April 2021 the platform's project team has maintained and developed it. Its stated aim is a more accessible, safer and more reliable internet for everyone (internet.nl: About).

It is not a vendor selling its own product. That neutrality is why you can show a result to a Dutch client without explanation.

1-1. Three tests

Sources: About the website test and About the email test, checked 1 November 2026.

1-2. Its link to Forum Standaardisatie

The Dutch Standardisation Forum is one of the platform's participating parties. The About page does not describe how the test relates to the pas-toe-of-leg-uit list, so chapter 8 takes that from the Forum's own pages.

2. Reading the result: only required items score

The results page shows a percentage and coloured icons. The first thing to know is that some red or yellow items change the score and some do not. The rules are in internet.nl's Explanation of test report.

2-1. Required, recommended, optional

So leaving a "recommendation" unfixed does not lower your score; to raise it, start with required items. New subtests usually begin as recommended or optional and may later become required, so the same item can change level over time.

2-2. Categories weigh the same

Each main test has several categories, and every category has equal weight. Only categories that contain required subtests count, and they count equally, so how many categories are counted decides each one's weight. The explanation's own example: with five categories, each is worth at most 20%. Release 1.9 (28 January 2025), however, states that the maximum for the RPKI category is 25% in both the website and mail tests (release 1.9). So 20% or 25% depends on how the categories are counted at the time. A category with one failed required subtest does not get its full score.

For example, if the DNSSEC category scores zero, the weight of that category (20-25%) is lost. Partial scores move the real figure, so check your own report.

2-3. 100% is not a security guarantee

The explanation page states two limits. It is a standards compliance test, not a security test, and 100% does not guarantee compliance with all mandatory Dutch government standards, because some are not tested or cannot be tested. An outdated CMS, reused passwords or a wide-open admin panel stay invisible to it. The norm can also change, with changes announced in news items.

Domains that reach 100% enter the Hall of Fame and may use a 100% badge, but only on a site with the same domain, while the score holds, linking to internet.nl, ideally with the image served from your own server (Using the 100% badges).

3. Website test: five categories by who fixes them

Item names and levels below follow a sample report (example.nl, checked 1 November 2026). Levels get revised, so decide from your own report.

3-1. IPv6

It checks that at least two name servers have IPv6 addresses and are reachable over it, that the web server has an IPv6 address and answers on port 80 and/or 443, and that the site is the same over IPv4 and IPv6 (content differences above 10% only produce a warning).

Ask your hosting company. A useful request: "Can my plan get an IPv6 address, and may I add an AAAA record?" If you manage DNS, adding an AAAA record is easy, but adding it before the server answers over IPv6 leaves some visitors unable to connect. Confirm the server side first.

3-2. DNSSEC

It checks that the domain's SOA record is signed and that the signature validates ("secure"). DNSSEC lets resolvers confirm a DNS answer was not forged.

The party to ask may be your registrar and your DNS operator, because the party that signs and the party that registers the signature with the parent zone can be different companies. Many registrars offer a switch in their panel, but that is a general statement and varies by supplier. A wrong DNSSEC setup can stop both the site and email resolving, so be careful when you move domain or change DNS provider, as discussed in the migration article.

3-3. HTTPS and HSTS

The HTTPS category is the largest, with more than twenty subtests in the sample report.

TLS details belong to whoever owns the server. On shared hosting you often cannot pick versions or ciphers, so a failure means asking for a plan change or a configuration change.

HSTS is checked on first contact, before any redirect. A max-age of one year is treated as sufficient, and the guidance warns against includeSubDomains and preload unless you are sure of the consequences. Preload is not tested. Start with max-age alone if any subdomain still lacks HTTPS.

A CAA record (which certificate authorities may issue for your domain) is only recommended and does not score, but it is worth adding if you manage DNS.

3-4. Security options: headers and security.txt

In the sample report every item here was optional or recommended, so none counted towards the score. They still matter: headers are basic defence and security.txt is your reporting channel. Levels can be revised upward.

A wrong Content-Security-Policy can break the page or analytics tags. If you use tracking tags or embedded video, work with your developer and test, rather than switching on a strict value at once.

3-5. RPKI

RPKI protects against hijacked or mistaken internet routes. The test looks for a Route Origin Authorisation (ROA) for the web server and name server IP addresses, and checks that their route announcements are "Valid" (four subtests in the sample).

Since release 1.9 (28 January 2025), RPKI counts towards the overall score. Its category maximum is 25%, and a domain that fails RPKI can no longer reach 100%. Within the category, the existence check carries one third and the validation check two thirds. internet.nl checks only that ROAs exist, not whether networks perform route origin validation (release 1.9, checked 1 November 2026).

The holder of the IP addresses creates ROAs, so a small business almost never does it itself. Ask your hosting company: "Have you created RPKI ROAs for the addresses my site uses?" That is a general explanation, and support differs by host. If the answer is no, there is little you can do except consider an RPKI-capable host at renewal.

4. Email test: authentication and encryption by owner

The Email test uses your email domain (for info@example.nl, enter example.nl). The sample report has four categories: IPv6, DNSSEC, authentication (DMARC, DKIM, SPF), and STARTTLS and DANE. The About page and the release 1.9 announcement say RPKI counts for email too. Yet the sample report I checked showed no RPKI category, only links to outside tests. The official description and the sample disagree, so check your own report (sample email report, checked 1 November 2026).

4-1. Authentication: SPF, DKIM, DMARC

• SPF lists the servers allowed to send for your domain.
• DKIM signs outgoing mail so recipients can verify it.
• DMARC tells receivers what to do with mail that fails: nothing, quarantine or reject.

Note that SPF is checked down to its ending, and DKIM only for existence, so a pass does not prove your signatures validate in practice. For domains that send no mail, the report recommends p=reject with SPF -all, and says DKIM is not needed.

You can change SPF and DMARC yourself if you control DNS (both are TXT records). DKIM usually means copying a public key from your mail provider into DNS. If invoicing, booking or newsletter tools send mail as your domain, each needs its own SPF entry and DKIM setup.

4-2. STARTTLS and DANE

STARTTLS encrypts mail between servers. DANE publishes the mail server certificate's fingerprint in DNSSEC-signed DNS so senders can confirm the server.

What matters: these items examine the servers that receive your mail (MX). If you use Google Workspace, Microsoft 365 or mail bundled with hosting, the MX domain belongs to the provider, and you cannot change DANE or TLS yourself.

Ask the provider whether it supports DANE and DNSSEC, but expect that nothing may change. A realistic choice is to accept those failures and prioritise other items. Switching provider only for DANE is rarely needed; consider it if a client demands encrypted mail transport.

4-3. DNSSEC and IPv6 on the mail side

Email DNSSEC covers your address domain and the MX servers' domains, the latter being a prerequisite for DANE. IPv6 covers two name servers, AAAA records on MX servers and port 25 over IPv6. The MX side again belongs to your mail provider.

5. Fix it yourself or ask a supplier

Sending a request to the wrong party costs days. Sorting items by owner first avoids that.

The same grouping as a table:

What follows from the table: the fastest score gains come from TXT records and headers you can touch yourself. Items that depend on your host, such as IPv6 and RPKI, take longer and may end in "not supported".

5-1. A request template

Use the test's own item names. For a hosting company:

On the internet.nl Website test, these items failed (result URL: ...).

1. IPv6 addresses for web server
2. Route Origin Authorisation existence (RPKI) Can our plan support them, and if not, which plan can?

The result URL lets the other side see the same screen. Ask the mail provider for DKIM steps and DANE support, and the registrar for how to enable DNSSEC and register the DS record.

6. How to write a security.txt

security.txt is a small text file telling people who find a vulnerability where to report it. It is defined in RFC 9116 (checked 1 November 2026).

6-1. Location and fields

• Location: /.well-known/security.txt, over HTTPS as text/plain in UTF-8. A top-level copy or redirect is allowed for legacy use, but /.well-known/ wins if both exist.
• Required: Contact and Expires; Expires must not appear twice.
• Optional: Acknowledgments, Canonical, Encryption, Hiring, Policy, Preferred-Languages.
• Expiry: Expires should be less than a year ahead.
• Signing: An OpenPGP cleartext signature is recommended; if you sign, also add Canonical.

6-2. A minimal example

Contact: mailto:security@example.nl
Expires: 2027-10-31T23:00:00.000Z
Preferred-Languages: nl, en
Canonical: https://www.example.nl/.well-known/security.txt

example.nl is a made-up domain. Use an address someone actually reads, preferably a shared one such as security@ so it survives staff changes.

6-3. Decide before you publish

What happens after a report matters more than the file. Who receives it, how fast do you reply, who is told to fix it? A Contact line that nobody monitors does more harm than none. An expired file reads as stale, so put the renewal in the calendar a month ahead. If a web agency maintains your site, list your own contact, not theirs, and have it forwarded.

In the sample report security.txt is a recommended item checking for a valid file under /.well-known/. It is also on the Forum Standaardisatie list as RFC 9116.

7. Raising DMARC safely

DMARC is the item most likely to fail and the one to change most carefully. p=none does not pass, but jumping to p=reject can block legitimate mail.

As the figure shows, internet.nl passes quarantine and reject. The sequence below is a working practice, not a specification.

7-1. Stage by stage

The pass starts at stage 2. If there is no hurry, spend longer in stage 1. There is no official timeline; how long it takes depends on how many senders you have and how long reports take to settle.

7-2. Senders people forget

Trouble after raising DMARC comes from non-obvious senders: automatic invoices, booking notifications, contact-form auto-replies, newsletters, and mail sent by your CMS. If they send as your domain without SPF or DKIM set up, they stop arriving the day you move to reject. Inventory senders before changing DMARC.

8. The Forum Standaardisatie "pas toe of leg uit" list

internet.nl's items map onto the Dutch government's standardisation framework. The Standardisation Forum maintains a list of open standards for public bodies, and its core is the "pas toe of leg uit" ("apply or explain") list.

8-1. The standards on the list

The Forum's list of mandatory standards (checked 1 November 2026) includes those behind internet.nl's items:

So internet.nl's main items largely coincide with the government list. The internet.nl About page does not describe a formal link, so I do not claim the two are officially tied together.

8-2. Who is bound

The policy (checked 1 November 2026) covers municipalities, provinces, central government, water authorities and executive bodies. When they buy or build ICT, they apply the listed standard or explain why not; acceptable reasons are that a standard is insufficiently available, insufficiently safe or reliable, or another reason of special weight. It applies to data-exchange and archiving ICT of at least EUR 50,000, with compliance and deviations reported in the annual report.

The page names no obligation for private companies. It does say HTTPS, HSTS and DigiToegankelijk are currently legally mandatory under the Wet digitale overheid.

8-3. What it means for a private business

No direct duty, but two situations can touch you. Both are my inference, not official statements.

1. Selling to public bodies. Tenders and supplier questionnaires may reference listed standards, and an internet.nl result helps you answer.
2. NIS2-related client questionnaires, as covered in the earlier article, where in-scope organisations check their supply chain.

Either way, the result is a shared yardstick a client can look at. It does not mean 100% is mandatory.

9. How high should you aim

There is no official "good enough" percentage, and I found no sourced figure for typical Dutch SME scores. What follows is reasoning from how the score works.

Rather than chasing 100%, fix required failures in an agreed order. Aim for 100% if you want the badge or to show a client. Without that goal, simply fixing the DNS items already makes mail more trustworthy and the site better defended.

10. Common pitfalls

Most of these come from changing something without checking what it affects. Retest after any redesign or hosting change.

11. How to proceed in common situations

What you do after the result depends on your situation. Here are three common ones as conditions and steps.

11-1. DMARC is p=none and you have few senders

Condition: DMARC is p=none, you control DNS, and you have confirmed only two senders, the mail service and invoicing software. Steps: keep p=none, receive aggregate reports, check that the invoicing tool's DKIM aligns, then move to quarantine. DANE depends on the mail provider, so accept that failure for now.

11-2. A client questionnaire asks about SPF, DKIM and DMARC

Condition: SPF and DKIM exist but DMARC does not. Steps: add DMARC at p=none, read the reports to confirm senders, and answer truthfully, for example "DMARC rollout in progress". Never write "done" for something not done.

11-3. A public-sector deal mentions the listed standards

Condition: HTTPS passes but IPv6 and RPKI fail. Steps: ask the host in writing, citing item names, what is supported and what a plan change would allow. If the answer is "not planned", record the reason and use it when comparing hosts at renewal.

12. What not to do

13. Steps for today

1. Run the Website test at internet.nl on your domain, with and without www.
2. Run the Email test on what follows the @ in your address.
3. Save each result URL and percentage with the date.
4. List required failures and use chapter 5 to pick the owner.
5. Start with what you can fix: SPF, DMARC, headers, security.txt.
6. Ask suppliers in writing, with item names and the result URL.
7. Retest after every change and note the difference.

13-1. Checklist

• Tested website and email; saved the results
• Listed every sender (invoices, bookings, newsletters)
• SPF ends in ~all or -all, within 10 lookups
• DMARC is quarantine or reject, or a staged plan exists
• HTTPS redirect and HSTS (max-age of a year or more) confirmed
• security.txt published; a reader and a renewal date assigned
• IPv6, DNSSEC and RPKI status confirmed with suppliers
• Retested after changes

14. Summary

• internet.nl is a free, jointly run test of standards compliance. It is not a guarantee of security.
• Only required items score, and categories weigh the same. Yellow recommendations don't move the number.
• You can fix SPF, DMARC, headers and security.txt with DNS and server access.
• IPv6, RPKI and TLS are for your host, DNSSEC for your registrar, DANE and STARTTLS on mail for your mail provider. Ask with item names.
• DMARC p=none does not pass. Inventory senders and raise in stages.
• Pas toe of leg uit binds public bodies, not private firms, though you may meet it in public-sector deals.
• Retest after every change, especially after a move or redesign.

Talk to us

Understanding the result is one thing; knowing whom to write to, and what to say, is where many stop. DevNJ is based in The Hague and helps with building and running websites for European markets.

To see what we do, read about our services. If you want help deciding what to fix first, send your domain and your current hosting and mail suppliers through the contact page.

Sources

internet.nl (Internet Standards Platform)

• internet.nl: About: organisation, aim, Forum Standaardisatie as participant
• About the website test: Website test categories
• About the email test: Email test categories
• Explanation of test report: required, recommended, optional; category weights; limits of 100%
• Using the 100% badges: badge conditions
• Website test sample report (example.nl): subtests and levels
• Email test sample report (internet.nl): pass conditions for DMARC, SPF, DKIM, STARTTLS, DANE
• Release 1.9 (January 2025): RPKI added to the overall score, 25%, existence 1/3 and validation 2/3
• Security options (HTTP security headers and security.txt): reference material
• HTTPS: HSTS, TLS and certificate specifications
• Internet Standards Platform toolbox wiki: how-tos for DMARC, DKIM, SPF, STARTTLS, DANE

Forum Standaardisatie and standards

• Pas toe leg uit standards (mandatory), Forum Standaardisatie: the listed standards
• Pas toe of leg uit policy, Forum Standaardisatie: who is bound, the EUR 50,000 threshold, legal status of HTTPS and HSTS
• RFC 9116: A File Format to Aid in Security Vulnerability Disclosure: the security.txt specification

DevNJ

• The Dutch Cybersecurity Act (NIS2) and your SME website: what clients may ask of you
• Moving your domain and server during a website redesign: moving DNS and mail without downtime

All checked on 1 November 2026. internet.nl items and levels are revised from time to time, so base decisions on the latest result for your own domain.

For a check of your website and email, or help building and running a site for European markets, see our services or the contact page.