internet.nlテストの見方｜サイトとメールのセキュリティを無料で点検する（2026年）

「サイトのセキュリティは大丈夫ですか」と聞かれて、答えに困る事業者は少なくありません。専門の診断会社に頼めば費用がかかります。かといって、何も見ないままにしておくのも不安です。オランダには、その最初の一歩に使える無料の診断があります。internet.nl です。

ドメイン名を入れるだけで、サイトとメールが現代的なインターネット標準にどれだけ対応しているかが、パーセントで出ます。オランダ政府と民間団体が共同で運営していて、オランダの自治体や企業が、自社の点検にも取引先への説明にも使っています。ただ、結果の画面には IPv6、DNSSEC、HSTS、DMARC、DANE と略語が並び、落ちた項目を誰に直してもらえばよいのかが分かりにくいのが実情です。

この記事では、internet.nl の Website test と Email test の項目を、「何を見ているか」と「落ちたとき、ホスティング会社・ドメイン業者・メール事業者の誰に何を頼むか」の2つの軸で読み解きます。あわせて、スコアの仕組み、security.txt の書き方、DMARC を安全に上げる順序、そして公的機関向けの「pas toe of leg uit」リストとの関係も整理します。

NIS2 を国内法にしたサイバーセキュリティ法（Cbw）の対象かどうかは、「オランダのサイバーセキュリティ法（NIS2）と中小企業のサイト」で扱いました。ドメインやサーバーを移すときのメールの扱いは、「リニューアルでサーバー・ドメインを移転するときの注意点」にあります。この記事は、その間にある「いまの状態を、無料で測ってみる」話です。

この記事が主に根拠にした情報：internet.nl の「About」「テスト結果の説明（Explanation of test report）」「100%バッジの使い方」と、Website test・Email test のサンプルレポート、Forum Standaardisatie の「pas toe of leg uit」の案内と標準の一覧、RFC 9116（security.txt）です。いずれも2026年11月1日に確認しました。

1. internet.nl とは何か：誰が運営し、何を測るか

internet.nl は、Internet Standards Platform（インターネット標準プラットフォーム）が運営する診断サービスです。運営団体は、インターネットのコミュニティとオランダ政府の協力体制で、管理上の事務局を ECP が担い、ドメイン名は Internet Society のオランダ支部が提供しています。土台になるツールは NLnet Labs が作り、2021年4月1日からは、プラットフォームのプロジェクトチームが保守と開発を引き継いでいます。目的は「インターネットを、すべての人にとって、より使いやすく、安全で、信頼できるものにすること」と書かれています（internet.nl: About）。

つまり、特定の民間企業が自社製品を売るための診断ではありません。結果を見て何かを買わされる仕組みでもありません。この中立性が、オランダで取引先に結果を見せるときの通りのよさにつながっています。

1-1. テストは3種類ある

internet.nl のテストは3種類あります。この記事で扱うのは、事業者のサイトと関係が深い前の2つです。

出典は internet.nl: About the website test と About the email test です（2026年11月1日確認）。Connection test は自分の回線の話なので、サイトの点検には使いません。

1-2. 運営側の位置づけで押さえること

internet.nl は、Forum Standaardisatie（オランダ標準化フォーラム）が参加団体の1つです。ただし、「pas toe of leg uit」リストとの具体的な関係は、internet.nl の About ページには書かれていません。両者の関係は、第8章で、Forum Standaardisatie 側の資料から整理します。

2. 結果の読み方：スコアは「必須」項目だけで決まる

結果画面を開くと、パーセントと、緑・赤・黄色などのアイコンが並びます。ここで最初に押さえるのは、赤でも黄色でも、スコアに響くものと響かないものがあることです。internet.nl の「テスト結果の説明」ページ（Explanation of test report）に、仕組みが書かれています。

2-1. 必須・推奨・任意の3段階

各項目（サブテスト）には、RFC 2119 の用語に沿って3つの水準があります。

この表のあとに言えるのは、赤く「推奨」と出た項目を直さなくても、スコアは下がらないということです。逆に、スコアを上げたいなら、必須の項目から手を付ける必要があります。なお、新しく加わる項目は、最初は推奨か任意で始まり、のちに必須へ上がることがあると説明されています。つまり同じ項目でも、時期によって水準が変わります。

2-2. 分野ごとの重みは等しい

もう1つの仕組みが、重みです。1つのテストの中は複数の分野（カテゴリ）に分かれ、各分野は同じ重みで計算されます。スコアに入るのは、必須の項目がある分野だけで、分野どうしは均等です。何分野が数えられるかで、1分野の重みは変わります。説明ページの例では、分野が5つなら1分野は最大で20%分です。一方、2025年1月28日のリリース1.9では、RPKI の分野の最大が Website・Email のどちらも25%と告知されています（release 1.9）。つまり、20%か25%かは、そのときの分野の数え方で決まります。必須の項目が1つでも落ちた分野は、満点になりません。

図の内容は本文の通りです。たとえば DNSSEC の分野が0点なら、その分野の重み（20〜25%）が失われます。実際の点は項目ごとの部分点で動くため、自分の結果画面で確かめてください。

2-3. 100%でも「安全」の保証にはならない

説明ページは、100%について2つの限界を明記しています。

• 標準への適合度のテストであり、セキュリティテストではない。
• オランダ政府の必須標準の全てに適合した保証にもならない。 テストされていない標準や、テストできない標準があるため。

つまり、更新が止まった CMS、使い回しのパスワード、権限の広すぎる管理画面は、このテストでは見えません。internet.nl は、入り口の設定を機械的に点検する道具として使い、サイトの中身の安全は別に見る、と整理しておくと誤解がありません。判断基準そのものが変わることもあり、変更はお知らせで告知されると説明されています。

100%になったドメインは、「Hall of Fame（殿堂）」に載り、100%バッジを使えます。バッジは、100%を取ったドメインと同じドメインのサイトにだけ貼れること、画像は自社サーバーから配信するのが望ましいこと、リンク先は internet.nl にすることが条件です（Using the 100% badges）。100%を保っている間だけ使える点にも注意が必要です。

3. Website test：5つの分野を「誰が直すか」で読む

ここからは、Website test の項目を順に見ます。各項目で見るのは、「何を見ているか」「落ちたとき誰に何を頼むか」の2点です。項目名と水準は、internet.nl のサンプルレポート（example.nl のレポート、2026年11月1日確認）の表記に基づきます。水準は改訂されるため、実際の判断は自分のレポートで行ってください。

3-1. IPv6（現代的なアドレス）

見ているのは、サイトとネームサーバーが IPv6 に対応しているかです。サンプルレポートの項目は5つで、「ネームサーバーのうち少なくとも2台が IPv6 アドレスを持つ」「それが IPv6 で実際につながる」「ウェブサーバーが IPv6 アドレスを持つ」「それが80番か443番ポートで応答する」「IPv4 と IPv6 で同じサイトが表示される」です。内容の差が10%を超えても、警告にとどまります。

落ちたとき、頼み先はホスティング会社です。ウェブサーバーのアドレスも、多くの場合はネームサーバーも、契約先のホスティング会社が持っているためです。依頼は「このプランで IPv6 のアドレスを割り当てられますか。DNS に AAAA レコードを入れてよいですか」と具体的に聞きます。DNS を自分で管理しているなら、AAAA レコードは自分で入れられますが、サーバー側が IPv6 に応答しないまま入れると、サイトにつながらない人が出ます。サーバー側の対応を確認してから入れてください。

3-2. DNSSEC（ドメイン名の署名）

見ているのは、ドメインの SOA レコードが DNSSEC で署名されていることと、その署名が正しく検証できること（「secure」の状態）の2点です。DNSSEC は、DNS の回答が途中で偽造されていないことを確かめる仕組みです。

頼み先は、ドメイン業者（レジストラ）と DNS を運用している事業者の両方になりえます。署名する側（DNS の運用者）と、署名の「しるし」を上位のドメイン（.nl など）に登録する側（レジストラ）が、別の会社のことがあるからです。オランダの .nl ドメインを扱う事業者は、管理画面で DNSSEC をオンにできることが多いのですが、これは一般的な説明であり、業者ごとに画面と対応が違います。設定を誤ると、サイトとメールが名前解決できなくなるため、ドメインを移転するタイミングや、DNS 事業者を変えるタイミングでは、特に慎重に扱います。この点は、先ほどの移転の記事で扱った注意点と重なります。

3-3. HTTPS（安全な接続）と HSTS

HTTPS の分野は項目が最も多く、サンプルレポートでは20項目を超えます。大きくは次の4つのまとまりです。

この表のあとに言えるのは、TLS の細かい設定はサーバーの持ち主の領域だということです。共有ホスティングでは、利用者が TLS のバージョンや暗号スイートを選べないことが多く、落ちた項目は「プランの変更か、ホスティング会社の設定変更」を依頼することになります。

HSTS は、サイトに最初に接続した時点で確かめられます（転送の前）。max-age は1年以上が十分とされます。一方で、同じガイダンスは、includeSubDomains や preload は結果を確信できる場合に限って使うよう注意しています。いったん preload に載せると、取り消しに時間がかかります。サブドメインに HTTPS 未対応のものがある会社は、max-age だけで始めるのが安全です。internet.nl も、preload は検査対象にしていません。

推奨に分類されている項目に、CAA レコード（どの認証局が証明書を出してよいかをDNSで宣言する）があります。スコアには入りませんが、証明書の誤発行を防ぐ効果があるため、DNS を自分で触れるなら入れておく価値があります。

3-4. セキュリティオプション（ヘッダーと security.txt）

この分野は、HTTP のセキュリティヘッダーと security.txt を見ます。サンプルレポートでの水準は次の通りです。

この分野の項目はすべて、サンプルレポートでは「任意」か「推奨」で、スコアには入らない扱いでした。それでも点検する価値があるのは、ヘッダーがサイトの守りの基本であり、security.txt が脆弱性の報告窓口になるからです。ただし水準は改訂されるため、必須に上がる可能性は残ります。

ヘッダーの追加は、サーバーの設定ファイルか、CMS のプラグイン、または CDN の管理画面で行います。Content-Security-Policy は、設定を誤るとサイトの表示や計測タグが止まります。解析タグや埋め込み動画を使っているサイトでは、いきなり強い値を入れず、制作会社と一緒に動作を確かめながら進めます。

3-5. RPKI（経路の認可）

RPKI は、インターネットの経路情報（BGP）の乗っ取りや誤りを防ぐ仕組みです。internet.nl では、ウェブサーバーとネームサーバーの IP アドレスについて、ROA（Route Origin Authorisation）が存在することと、その経路広告が「Valid」と判定されることを見ます。サンプルレポートでは4項目です。

なお、internet.nl のリリース1.9（2025年1月28日）から、RPKI は総合スコアに入っています。RPKI の分野の最大は25%で、RPKI が不合格だと100%にはなりません。分野の中では、ROA の存在が3分の1、経路広告の検証が3分の2の重みです。internet.nl が見るのは ROA の存在（公開）であり、ネットワークが経路の検証（ROV）をしているかは見ません（release 1.9、2026年11月1日確認）。

ROA は、IP アドレスの持ち主が作るものです。小さな事業者が自分で作る場面はほとんどなく、頼み先はホスティング会社になります。「当社のサイトの IP アドレスについて、RPKI の ROA を作成しているか」と聞きます。これは一般的な説明であり、ホスティング会社によって対応の有無が違います。答えが「していない」だった場合、事業者側でできることは多くありません。そのときは、RPKI に対応した事業者へ移すことも、更新時の選択肢に入れます。

4. Email test：認証と暗号化を「誰のものか」で読む

Email test は、メールアドレスのドメイン（例：info@example.nl なら example.nl）に対して行います。サンプルレポートの分野は4つで、IPv6、DNSSEC、認証（DMARC・DKIM・SPF）、STARTTLS と DANE です。Email test の About ページとリリース1.9のお知らせでは、メールでも RPKI がスコアに入るとされています。しかし、私が確認したサンプルレポートには RPKI の分野が見当たらず、外部テストへのリンクだけでした。公式の説明とサンプルが食い違っているため、分野の数は自分の結果で確かめてください（internet.nl のメールテスト結果の例、2026年11月1日確認）。

4-1. 認証：SPF・DKIM・DMARC

3つは、なりすましメール（フィッシング）対策として組み合わせて働きます。

• SPF：このドメインのメールを送ってよいサーバーを、DNS で宣言する。
• DKIM：送信するメールに電子署名を付け、受信側が検証できるようにする。
• DMARC：SPF か DKIM が合わなかったメールを、受信側がどう扱うか（何もしない・隔離・拒否）を宣言する。

サンプルレポートで読み取れる合格の条件は、次の通りです。

この表のあとに言えるのは、SPF は「入れてあるだけ」では足りず、末尾の書き方まで見られることです。DKIM は存在の確認にとどまり、署名が実際に合っているかまでは、このテストでは分かりません。DMARC を p=reject にして、正当なメールが落ちていないかは、別に確かめる必要があります。

メールを送らないドメイン（使っていない別名ドメインなど）には、別の扱いがあります。サンプルレポートでは、そうしたドメインには p=reject と SPF の -all を勧め、DKIM は不要としています。使っていないドメインが、なりすましの踏み台にされるのを防ぐ設定です。

この分野の頼み先は、メールを運用している事業者とDNS を管理している人の両方です。SPF と DMARC は DNS の TXT レコードなので、DNS に触れる権限があれば自分で直せます。DKIM は、メール事業者が発行する鍵の情報（公開鍵）を DNS に登録する形が一般的なので、事業者の管理画面で手順を見て、その通りに DNS へ入れます。請求書システム、予約システム、メルマガ配信などで別の事業者がドメインを使って送っている場合は、そのサービスごとに SPF への追加と DKIM の設定が要ります。

4-2. STARTTLS と DANE：メールサーバー間の暗号化

STARTTLS は、メールサーバー同士のやり取りを暗号化する仕組みです。DANE は、DNS（DNSSEC で署名されたもの）に、メールサーバーの証明書の「指紋」を載せて、相手が本物のサーバーだと確かめられるようにする仕組みです。サンプルレポートでは、次のように見ます。

重要なのは、これらの項目を見ているのは、メールを受け取るサーバー（MX）だという点です。多くの小さな会社は、Google Workspace や Microsoft 365、あるいはホスティング会社付属のメールを使っています。その場合、MX のドメインはメール事業者のものであり、DANE や TLS の設定を自分で変えることはできません。

頼み先は、メール事業者です。ただし、頼んでも設定が変わらないことが多いため、現実的な判断は2つです。ひとつは、事業者に DANE と DNSSEC に対応しているかを聞くこと。もうひとつは、この項目で落ちることを承知で、他の項目を優先することです。DANE のためだけに、メール事業者を乗り換える必要はありません。取引先がメールの暗号化を求めてきた場合に初めて、選択肢として検討すれば足ります。

4-3. DNSSEC と IPv6（メール側）

メールの DNSSEC は、メールアドレスのドメイン自体と、MX サーバーのドメインの両方を見ます。後者は DANE の前提になります。IPv6 は、ネームサーバー2台以上の IPv6 アドレス、MX サーバーの AAAA レコード、ポート25での IPv6 接続を見ます。ここも、MX 側はメール事業者の領域です。

5. 自分で直す項目と、業者に頼む項目

ここまでの内容を、頼み先で整理します。依頼の出し先を間違えると、「それはうちでは対応できません」と返されて、数日が過ぎます。

図の内容は、次の表にも書きました。

この表のあとに言えるのは、スコアを短期間で上げやすいのは、自分で触れる TXT レコードとヘッダーだということです。逆に、IPv6 や RPKI のようにホスティング会社の対応が前提の項目は、依頼しても時間がかかり、答えが「対応していない」になることもあります。

5-1. 業者に頼むときの文面

依頼は、テストの項目名をそのまま使うと通じやすくなります。たとえば、ホスティング会社への依頼は次のようにまとめます。

internet.nl の Website test で、次の項目が不合格でした（結果の URL：…）。

1. IPv6 addresses for web server（ウェブサーバーの IPv6 アドレス）
2. Route Origin Authorisation existence（RPKI の ROA） 当社のプランで対応できるか、できない場合はどのプランなら可能かを教えてください。

結果ページの URL を添えると、相手が同じ画面を見て確認できます。メール事業者には「DKIM の設定手順」と「DANE への対応の有無」を、ドメイン業者には「DNSSEC の有効化の手順と、DS レコードの登録方法」を聞きます。

6. security.txt の書き方

security.txt は、脆弱性を見つけた人がどこに連絡すればよいかを、サイトの決まった場所に書いておく小さなテキストファイルです。RFC 9116 で定められています（RFC 9116、2026年11月1日確認）。

6-1. 置き場所と必須項目

• 場所：/.well-known/security.txt（HTTPS で、text/plain、文字コードは UTF-8）。旧来のためにサイト直下に置くことや転送も許されますが、両方あれば /.well-known/ が優先されます。
• 必須の項目：Contact（連絡方法）と Expires（有効期限）の2つ。Expires は重複させません。
• 任意の項目：Acknowledgments、Canonical、Encryption、Hiring、Policy、Preferred-Languages。
• 有効期限の目安：Expires は、1年未満先の日時にするのが望ましいとされています。
• 署名：OpenPGP の署名が推奨されています。署名するなら、場所を確認できるよう Canonical も入れます。

6-2. 最小の例

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 は説明用の架空のドメインです。連絡先には、実際に読まれるアドレスを入れます。個人の担当者のメールアドレスより、security@ のような共有の窓口にしておくと、人が替わっても届きます。

6-3. 公開前に決めておくこと

ファイルを置くことより、報告を受けた後の動きのほうが重要です。誰が受け取り、何日以内に返信し、誰に連絡して修正を頼むのか。これが決まっていない会社が Contact だけを公開すると、報告が届いても放置されます。Expires を過ぎたファイルは「古い」と見なされるため、期限の1か月前に更新の予定を入れておきます。サイト制作を外注している場合は、制作会社の窓口を Contact に書くのではなく、自社の窓口を書き、制作会社に転送してもらう形が安全です。

internet.nl のサンプルレポートでは、security.txt は「/.well-known/ に置かれた構文の正しいファイルがあるか」を見る推奨項目でした。Forum Standaardisatie の標準の一覧にも、security.txt（RFC 9116）が載っています。

7. DMARC を安全に上げる順序

DMARC は、internet.nl のメールテストで最も落ちやすく、最も慎重に直す項目です。p=none のままではテストに合格できませんが、いきなり p=reject にすると、正当なメールが届かなくなる危険があるからです。

図の通り、internet.nl が合格とするのは quarantine と reject です。進め方は、DevNJ が実務で勧めている順序として、次のように整理します。出典のある仕様ではなく、運用上の考え方です。

7-1. 段階ごとにやること

この表のあとに言えるのは、internet.nl の合格は段階2からだということです。急ぐ必要がないなら、段階1で十分な期間レポートを見てから進めるほうが、事故が起きません。必要な期間に公式の基準はなく、送信元の数と、レポートで問題が出尽くすまでの長さで大きく変わります。

7-2. 見落としやすい送信元

DMARC を上げたあとに困るのは、普段のメール以外の送信元です。請求書の自動送信、予約システムの通知、問い合わせフォームの自動返信、メルマガ配信、ウェブサイトの CMS から出るメールなどです。これらが、自社のドメインを差出人にして送っているのに、SPF や DKIM が設定されていないと、reject にした日から届かなくなります。DMARC を変える前に、送信元の棚卸しをするのが、一番の予防になります。

8. Forum Standaardisatie の「pas toe of leg uit」との関係

internet.nl の項目名は、オランダ政府の標準化の枠組みと対応しています。Forum Standaardisatie（標準化フォーラム）は、公的機関が使うべきオープン標準の一覧を管理していて、その中核が「pas toe of leg uit（適用せよ、さもなくば説明せよ）」リストです。

8-1. 一覧に載っている標準

Forum Standaardisatie の「'Pas toe of leg uit'-standaarden (verplicht)」のページ（forumstandaardisatie.nl、2026年11月1日確認）には、internet.nl の項目と重なる標準が載っています。

この表のあとに言えるのは、internet.nl の主な項目は、ほぼそのまま政府の一覧にあるということです。ただし、internet.nl の About ページには一覧との関係の説明がないため、両者が公式に連動しているとまでは言えません。

8-2. 誰に義務があるか

「pas toe of leg uit」の方針は、国・県・市町村・水管理委員会など、公的機関に適用されます。ICT の製品やサービスを買う、あるいは作るときに、一覧にある標準を適用するか、適用しない理由を説明します。説明する理由として認められるのは、標準が十分に使えない、安全性や信頼性が足りない、その他の特別に重い理由がある場合に限られます。対象は、データ交換や電子保管に使う、5万ユーロ以上の調達です。遵守状況は、年次報告で報告します（Forum Standaardisatie: Pas toe leg uit-beleid、2026年11月1日確認）。

このページに、民間企業への義務は書かれていません。ただし、同ページによれば、HTTPS・HSTS・DigiToegankelijk は、デジタル政府法（Wet digitale overheid）に基づく法的な義務にもなっています。

8-3. 民間の事業者にとっての意味

民間の事業者に直接の義務はありませんが、次の2つの場面では関係してきます。いずれも、公式資料ではなく、筆者の推測を含みます。

1. 公的機関と取引する場合。 調達の仕様や、委託先の確認の質問票に、一覧の標準が含まれる可能性があります。internet.nl の結果は、説明の材料になります。
2. NIS2（サイバーセキュリティ法）の関連で、取引先から質問票が届く場合。 こちらは前の記事で扱った通り、対象の組織が供給網の安全を確かめる流れです。

どちらの場合も、internet.nl の結果は取引先が見られる共通の物差しになります。ただし、100%が義務という意味ではありません。

9. スコアの目安：どこまで目指すか

「何%なら十分か」には、公式の基準はありません。一般的なオランダの中小企業のスコア分布についても、私は出典のある数字を見つけられませんでした。ここでは、仕組みから導ける考え方だけを示します。

この表のあとに言えるのは、100%を目標にするより、必須の不合格をなくす順番を決めるほうが、現実的だということです。100%バッジを使いたい、取引先に見せたいという目的があるなら、100%を目指す意味があります。目的がないなら、DNS で直せる項目を直すだけでも、メールの信頼性とサイトの守りは確実に上がります。

10. つまずきやすいところ

この表のあとに言えるのは、多くのつまずきが、変更の影響範囲を確かめずに進めることから起きるということです。サイトのリニューアルやホスティングの変更のあとは、必ず再測定してください。

11. 状況別の進め方

結果が出たあとの動きは、状況で変わります。ここでは、よくある3つの状況を、条件と手順の形で整理します。

11-1. DMARC が p=none で、送信元が少ない場合

条件：DMARC が p=none、DNS を自分で管理でき、送信元がメールサービスと請求ソフトの2つだけと確認できている。手順：p=none のまま集計レポートを受け取り、請求ソフトの DKIM が合っていることを確かめてから quarantine に進めます。DANE はメール事業者の対応次第なので、落ちることを承知で後回しにします。

11-2. 取引先のセキュリティ質問票に、SPF・DKIM・DMARC の設定を聞かれた場合

条件：SPF と DKIM はあるが、DMARC がない。手順：まず DMARC を p=none で追加し、レポートで送信元を確認します。質問票には「DMARC を段階導入中」と事実の通りに書きます。やっていないことを「対応済み」と書かないのが基本です。

11-3. 公的機関との取引で、標準への言及がある場合

条件：HTTPS は合格だが、IPv6 と RPKI が不合格。手順：ホスティング会社に、対応状況とプラン変更の可否を、項目名を添えて文書で問い合わせます。回答が「当面は対応しない」なら、その理由を記録し、更新時に事業者を比較する材料にします。

12. やってはいけないこと

13. 手順：今日から始める

1. internet.nl の Website test に、サイトのドメイン（www あり・なし）を入れて測る。
2. 同じく Email test に、メールアドレスの @ 以降を入れて測る。
3. 結果ページの URL と、パーセントを記録する（日付つき）。
4. 必須の不合格を一覧にし、第5章の表で頼み先を決める。
5. 自分で直せる項目（SPF・DMARC・ヘッダー・security.txt）から手を付ける。
6. 業者への依頼は、項目名と結果 URL を添えて文書で出す。
7. 変更のたびに再測定し、差を記録する。

13-1. チェックリスト

• サイトとメールの両方を測り、結果を保存した
• 送信元（請求・予約・配信など）を洗い出した
• SPF の末尾が ~all か -all で、参照が10回以内
• DMARC が quarantine か reject（または段階導入の計画がある）
• HTTPS への転送と HSTS（max-age 1年以上）を確認した
• security.txt を置き、連絡先を読む人と期限更新の予定を決めた
• IPv6・DNSSEC・RPKI の対応状況を、業者に確認した
• 変更後に再測定した

14. まとめ

• internet.nl は、サイトとメールの標準への対応度を測る、官民共同の無料診断です。 セキュリティの保証ではありません。
• スコアに入るのは必須の項目だけで、分野の重みは等しいです。 推奨・任意の黄色は、点に響きません。
• 自分で直せるのは、SPF・DMARC・ヘッダー・security.txt です。 DNS とサーバー設定に触れる権限があれば足ります。
• IPv6・RPKI・TLS はホスティング会社、DNSSEC はドメイン業者、メール側の DANE と STARTTLS はメール事業者の領域です。 項目名を添えて依頼します。
• DMARC は p=none では合格しません。 送信元を洗い出し、quarantine、reject と段階的に上げます。
• pas toe of leg uit は公的機関向けで、民間に義務はありません。 公的機関や大企業との取引で、物差しとして目にする可能性があります。
• 変更のたびに再測定します。 移転やリニューアルのあとは特に確認が必要です。

相談するなら

結果の読み方は分かっても、「どの業者に、何と言えばよいか」で止まる場面は多くあります。DevNJ は、オランダ・デン・ハーグを拠点に、欧州向けのサイト制作と運用を支援しています。

まず状況を整理したい方は、サービスの内容をご覧ください。自社のサイトとメールの点検結果をもとに、何から直すかを相談したい方は、お問い合わせから、ドメインと、今のホスティング・メールの契約先をお知らせください。

参考にした情報源

internet.nl（Internet Standards Platform）

• internet.nl: About：運営体制、目的、Forum Standaardisatie が参加団体であること
• About the website test：Website test の分野（IPv6、DNSSEC、HTTPS、セキュリティオプション、RPKI）
• About the email test：Email test の分野
• Explanation of test report：必須・推奨・任意、分野の重み、100%の限界
• Using the 100% badges：100%バッジの条件
• Website test のサンプルレポート（example.nl）：サブテストの一覧と水準
• Email test のサンプルレポート（internet.nl）：DMARC・SPF・DKIM・STARTTLS・DANE の合格条件
• internet.nl: Release 1.9（2025年1月）：RPKI が総合スコアに入ったこと、25%、存在1/3・検証2/3
• internet.nl: Security options（HTTP security headers and security.txt）：ヘッダーと security.txt の参考資料
• internet.nl: HTTPS：HSTS、TLS、証明書の関連仕様
• Internet Standards Platform: Toolbox wiki：DMARC・DKIM・SPF・STARTTLS・DANE の導入手順

Forum Standaardisatie と標準

• Pas toe leg uit-standaarden (verplicht) — Forum Standaardisatie：リストに載る標準
• Pas toe of leg uit-beleid — Forum Standaardisatie：対象機関、5万ユーロの目安、HTTPS と HSTS の法的義務
• RFC 9116: A File Format to Aid in Security Vulnerability Disclosure — RFC Editor：security.txt の仕様

DevNJ の公開情報

• オランダのサイバーセキュリティ法（NIS2）と中小企業のサイト — DevNJ：取引先から求められること
• リニューアルでサーバー・ドメインを移転するときの注意点 — DevNJ：DNS とメールを止めない移転

いずれも2026年11月1日に確認したものです。internet.nl の項目や水準は改訂されることがあるため、実際の判断は自分のドメインの最新の結果画面で行ってください。

サイトとメールの点検や、欧州向けのサイトの制作・運用のご相談は、サービスの内容またはお問い合わせからどうぞ。