Wie gut sind die beliebtesten Websites Polens geschützt? 1.000 .pl-Domains gemessen (September 2026)

Ich habe die ersten 1.000 .pl-Domains im Tranco-Ranking genommen, einer für die Forschung erstellten Liste, und sie am Morgen des 24. September 2026 von außen geprüft, so wie jeder Besucher oder Mailserver sie sieht. Die Messung war passiv: DNS-Abfragen, ein Aufruf jeder Startseite und einige TLS-Verbindungen pro Domain, ohne Schwachstellenscans und ohne Anmeldeversuche. Gezählt wurden die Ergebnisse mit denselben Prüfungen, die in den kostenlosen Tools von ShieldWave laufen. Ich nenne keine der Domains.

Die wichtigsten Ergebnisse

• Am 24. September 2026 hatten 460 von 997 der beliebtesten .pl-Domains (46,
   %) eine DMARC-Richtlinie, die empfangende Mailserver anweist, Nachrichten mit gefälschter Domain abzuweisen oder in Quarantäne zu stellen. Unter den Domains, die E-Mail empfangen (mit MX-Einträgen), waren es 445 von 927 (48,
   %).
• In der Messung vom 24. September 2026 sendeten 406 von 882 beliebten polnischen Startseiten, die über HTTPS ausgeliefert werden (46,
   %), einen HSTS-Header, und 217 von 887 (24,
   %) setzten eine Content-Security-Policy durch.
• Im September 2026 akzeptierten 230 von 952 beliebten .pl-Domains (24,
   %) noch TLS-1.0-Verbindungen. Von diesen 230 laufen 149 über Cloudflare, das TLS 1.0 akzeptiert, bis der Inhaber die Mindestversion anhebt.
• Für 274 von 997 Domains (27,
   %) gibt es überhaupt keinen DMARC-Eintrag, und weitere 248 (24,
   %) haben einen mit p=none, der nichts blockiert.
• Bei der Prüfung der Sicherheits-Header bekamen 20 von 887 Startseiten (2,
   %) die Bestnote A und 290 (32,
   %) die schlechteste, F.
• Eine security.txt-Datei, die Forschern sagt, wohin sie eine Schwachstelle melden können, fand ich auf mindestens 78 von 881 Websites (8,
   %).
• Von den 46 Websites, die ihre PHP-Version in einem Header angeben, nutzen 26 eine Version, die keinerlei Korrekturen mehr bekommt, 11 davon PHP 5.

E-Mail: Wer im Namen Ihrer Domain Mails verschicken kann

Eine gefälschte E-Mail mit der Adresse Ihres Unternehmens im Absenderfeld genügt, um einem Kunden eine falsche Rechnung zu schicken. Dagegen schützen drei DNS-Einträge: SPF, DKIM und DMARC, die ich in SPF, DKIM und DMARC erklärt beschreibe. Entscheidend ist DMARC: Es sagt dem empfangenden Server, was er mit einer Nachricht tun soll, die angeblich von Ihnen stammt, die Prüfungen aber nicht besteht.

SPF ist fast überall vorhanden: 915 von 999 Domains haben es (91,
 %). SPF allein prüft allerdings nicht die Adresse, die der Empfänger im Absenderfeld sieht. Das tut nur DMARC, und hier sind die Zahlen niedriger.

• Kein DMARC-Eintrag27,5%274 von 997
• p=none: überwacht, blockiert nichts24,9%248 von 997
• quarantine oder reject, aber nur für einen Teil der Mails (pct unter 100)1,5%15 von 997
• quarantine oder reject für alle Mails46,1%460 von 997

Domains mit eindeutiger DNS-Antwort. Es zählt nur der eigene Eintrag der Domain.

460 von 997 Domains (46,
 %) blockieren also Spoofing. Unter den Domains mit MX-Einträgen, also denen, die E-Mail empfangen, sind es 445 von 927 (48,
 %). Die übrigen haben entweder kein DMARC oder einen Eintrag, der nur überwacht. Ob eine gefälschte Nachricht dann im Posteingang landet, hängt ganz von den Filtern der Empfängerseite ab.

p=none ist kein Fehler, sondern der empfohlene erste Schritt: Die Domain sammelt Berichte, und ihr Inhaber sieht, wer in ihrem Namen Mails verschickt. Von den 723 DMARC-Einträgen enthalten 622 (86,
 %) eine Adresse für Sammelberichte (rua). Schutz beginnt aber erst mit quarantine oder reject. Unter den Domains mit DMARC sind die drei Einstellungen fast gleich häufig: p=none bei 248 von 723 (34,
 %), quarantine bei 263 (36,
 %) und reject bei 212 (29,
 %).

Kleinere SPF-Fehler: 12 von 915 Einträgen (1,
 %) brauchen mehr als die 10 DNS-Abfragen, die der Standard erlaubt, zwei Domains veröffentlichen zwei SPF-Einträge statt einem, und eine beendet ihren Eintrag mit +all, womit jeder Server in ihrem Namen Mails verschicken darf.

DKIM werte ich nicht aus. Die Selektoren, unter denen DKIM-Schlüssel veröffentlicht werden, lassen sich über DNS nicht auflisten, „nicht gefunden“ hieße also nur „nicht unter den gängigen Namen“.

Verschlüsselung: HTTPS, HSTS und TLS

HTTPS selbst ist Standard. Die Unterschiede liegen in dem, was dazugehört: dem HSTS-Header, alten TLS-Versionen und dem CAA-Eintrag.

Die Nenner unterscheiden sich, weil jede Zeile nur die Domains zählt, bei denen diese Prüfung eine Antwort bekam. Einzelheiten stehen im Abschnitt zur Methode.

HSTS ist ein Header, der den Browser anweist, für die Domain eine bestimmte Zeit lang nur HTTPS zu verwenden. Ohne ihn beginnt jeder Aufruf einer Adresse, die ohne https:// eingetippt wurde, mit einer unverschlüsselten Verbindung, bevor der Server umleitet, und in einem fremden WLAN kann diese Verbindung abgefangen werden. HSTS senden 406 von 882 HTTPS-Startseiten (46,
 %), 268 (30,
 %) davon mit der empfohlenen Dauer von mindestens einem Jahr.

TLS 1.0 und 1.1 sind alte Versionen des Verschlüsselungsprotokolls. Die Browser haben sie 2020 abgeschaltet, und die IETF hat sie 2021 offiziell für veraltet erklärt (RFC 8996). TLS 1.0 akzeptieren noch 230 von 952 Domains (24,
 %). Ein Besucher mit aktuellem Browser verbindet sich ohnehin über TLS 1.2 oder 1.3, ein Weg zur Übernahme einer Website ist das also nicht. Es bedeutet aber, dass der Server auf Nachfrage veraltete Verschlüsselung akzeptiert, und Prüfer sowie Sicherheitsfragebögen für Lieferanten verlangen, die alten Versionen abzuschalten.

Von diesen 230 Domains laufen 149 (64,
 %) über Cloudflare, das TLS 1.0 standardmäßig akzeptiert und erst damit aufhört, wenn der Inhaber die Mindestversion im Dashboard anhebt. Die übrigen 81 akzeptieren TLS 1.0 auf eigenen Servern oder bei anderen Anbietern.

CAA ist ein DNS-Eintrag, der die Zertifizierungsstellen auflistet, die für die Domain Zertifikate ausstellen dürfen. Alle anderen müssen dann ablehnen. Ich fand einen für 192 von 999 Domains (19,
 %).

Sicherheits-Header

Sicherheits-Header sind einige Zeilen mit Anweisungen, die der Server zusammen mit der Seite an den Browser schickt. Ich beschreibe sie in Sicherheits-Header für Websites: was sie sind und worum Sie bitten sollten. So oft kommen sie auf den Startseiten vor (HSTS steht im Abschnitt zur Verschlüsselung):

Weitere 26 Startseiten (2,
 %) haben CSP nur im Modus Report-Only, in dem der Browser nichts blockiert.

Der kostenlose Sicherheits-Header-Check (auf Englisch) bewertet sie von A bis F. Jeder Header bekommt eine Note, HSTS und CSP zählen doppelt, die übrigen einfach, und der Durchschnitt ergibt die Gesamtnote. Die Studie hat genau diese Skala verwendet.

• A2,3%20 von 887
• B21,8%193 von 887
• C21,1%187 von 887
• D22,2%197 von 887
• F32,7%290 von 887

Die Skala des kostenlosen Header-Checks von ShieldWave. HSTS und CSP zählen doppelt, die übrigen Header einfach.

Ein F heißt nicht, dass eine Website eine Lücke hat, und ein A garantiert nicht, dass sie keine hat. Header sind eine zweite Verteidigungslinie: Sie begrenzen den Schaden, wenn etwas anderes versagt. Fehlende Header bedeuten meist die Standardkonfiguration eines Servers, die sie nicht hinzufügt. Oft ergänzt sie später ein CDN oder ein Plugin.

Am selben Tag und mit derselben Methode habe ich die 500 beliebtesten .ae-Domains und die 500 beliebtesten .sa-Domains gemessen (Vereinigte Arabische Emirate und Saudi-Arabien). Ihre Startseiten haben häufiger CSP (280 von 656, 42,
 %) und HSTS (408 von 652, 62,
 %). Der Vergleich ist grob: Diese Listen reichen weiter in das Ranking hinunter, und 344 der 1.000 Startseiten dort ließen sich von Polen aus nicht analysieren. Einzelheiten stehen im Bericht zu dieser Messung.

Plattformen und veraltete Software

Eine Plattform habe ich auf jeder vierten Startseite erkannt. Auf 663 von 884 Startseiten (75,
 %) fand ich keine Spur einer bekannten Plattform: Das sind individuell entwickelte Websites oder solche, die nicht verraten, worauf sie laufen. Die folgenden Anteile sind deshalb Untergrenzen.

WordPress betreibt 101 von 884 Startseiten (11,
 %). Danach folgen Drupal (25), Magento (21) und TYPO3 (13). Polnische Shopplattformen (IdoSell, Shoper, AtomStore und RedCart) betreiben zusammen 12.

Die WordPress-Version ist bei 54 der 101 sichtbar. Das sind kleine Zahlen, deshalb nenne ich nur Anzahlen:

• 28 der 54 sind nicht auf der neuesten Version 7.1.2,
• 22 laufen auf einem Zweig älter als 7.1,
• 18 sind nicht auf der neuesten Version ihres eigenen Zweigs und verpassen damit Sicherheitskorrekturen, die für ihn schon veröffentlicht sind,
• die älteste sichtbare Version ist WordPress 3.5.1 aus dem Jahr 2013.

Nur 46 von 887 Startseiten nennen ihre PHP-Version in einem Header. Das Folgende beschreibt also diese 46, nicht das ganze Web. Davon laufen 26 auf Zweigen, die keinerlei Korrekturen mehr bekommen (8.1 und älter), 11 davon auf PHP 5, dessen letzter Zweig Ende 2018 den Support verlor. Weitere 12 bekommen nur noch Sicherheitskorrekturen (8.2 und 8.3), und 8 werden voll unterstützt (8.4 und 8.5).

Ein Servername mit Versionsnummer, etwa Apache/2.4.41, erscheint in den Headern von 74 von 887 Startseiten (8,
 %). Die Version preiszugeben, ist für sich keine Lücke, grenzt aber ein, welche bekannten Fehler in Frage kommen.

Plugins habe ich in dieser Studie nicht geprüft. Läuft Ihre Website mit WordPress, beginnen Sie mit Veraltete WordPress-Plugins: was Sie zuerst aktualisieren und was Sie löschen sollten.

security.txt: wohin man eine Schwachstelle meldet

Die Datei /.well-known/security.txt (RFC 9116) nennt die Adresse, an die ein Sicherheitsforscher eine gefundene Schwachstelle melden kann. Ohne sie geht eine Meldung an eine allgemeine Kontaktadresse oder nirgendwohin.

Eine mit dem Feld Contact: fand ich auf 78 von 881 Websites (8,
 %). Das ist eine Untergrenze: Weitere 41 Websites antworteten mit einer Umleitung auf eine security.txt-Datei an einer anderen Adresse, und Umleitungen bin ich nicht gefolgt. Selbst wenn jede davon zu einer gültigen Datei führte, wären es 119 von 881 (13,
 %). Von den 78 Dateien haben 55 das Feld Expires, das der Standard vorschreibt.

Tracker und Consent-Plattformen

Dieser Teil ist beschreibend. Es lief kein JavaScript, ich sehe also nur Werkzeuge, die im HTML der Startseite genannt sind. Ob und wann sie laufen, kann ich nicht sagen: Ein Skript kann auf die Einwilligung des Besuchers warten, und der Google Tag Manager kann Werkzeuge laden, die nicht im Seitencode stehen.

• Google Tag Manager45,6%403 von 884
• Google Analytics30,3%268 von 884
• Gemius12,3%109 von 884
• Meta Pixel10,2%90 von 884
• Microsoft Clarity3,4%30 von 884
• Hotjar2,5%22 von 884
• Matomo2,0%18 von 884

In jeder Form: Skript, Installations-Snippet oder bloßer Aufruf. Dass ein Werkzeug im Code steht, zeigt nicht, ob es vor der Einwilligung läuft.

Google Analytics oder Google Tag Manager erscheint im Code von 572 von 884 Startseiten (64,
 %). Gemius, das polnische System zur Reichweitenmessung, steht auf 109 von 884 (12,
 %). Der Google Consent Mode mit Standard „verweigert“, bei dem Googles Werkzeuge bis zur Einwilligung ohne Cookies arbeiten, zeigt sich auf 103 von 884 Startseiten (11,
 %).

Eine bekannte Consent-Plattform wie Cookiebot, OneTrust, Didomi oder eine, die das IAB-TCF-Framework nutzt, zeigt sich auf 293 von 884 Startseiten (33,
 %). Das heißt nicht, dass die übrigen kein Cookie-Banner haben. Eigene Banner, in Shopplattformen eingebaute Banner und über den Google Tag Manager geladene Werkzeuge sind mit dieser Methode unsichtbar. Rückschlüsse auf die Rechtskonformität ziehe ich aus diesen Zahlen deshalb nicht.

Was das für Ihr Unternehmen bedeutet

Wenn diese Einstellungen bei einigen der beliebtesten Websites des Landes fehlen, werden sie auch auf einer kleineren leicht übersehen. Jede der folgenden Prüfungen dauert eine Minute und braucht keinen Zugang zu Ihrem Server.

1. E-Mail. Führen Sie den SPF-, DKIM- und DMARC-Check (auf Englisch) aus. Haben Sie kein DMARC oder p=none, wechseln Sie schrittweise zu quarantine, wie in SPF, DKIM und DMARC erklärt beschrieben. Das schützt vor falschen Rechnungen, die von Ihrer Domain verschickt werden.
2. Verschlüsselung. Der SSL-Zertifikats-Check (auf Englisch) zeigt das Zertifikat, die HTTPS-Umleitung und die TLS-Versionen. Liegt Ihre Website hinter Cloudflare, ändern Sie die Mindestversion im Dashboard unter SSL/TLS, Edge Certificates, Minimum TLS Version. Stellen Sie TLS 1.2 ein.
3. Header. Der Sicherheits-Header-Check (auf Englisch) zeigt, was fehlt. Sicherheits-Header für Websites enthält eine fertige Vorgabe für Ihren Entwickler: Beginnen Sie mit HSTS mit kurzem max-age und CSP im Modus Report-Only.
4. security.txt. Veröffentlichen Sie /.well-known/security.txt mit den Feldern Contact und Expires. Das sind ein paar Zeilen Text.
5. Software. Aktualisieren Sie CMS und Plugins und entfernen Sie Versionsnummern aus den Server-Headern. Für WordPress siehe Veraltete WordPress-Plugins.
6. Tracker und Einwilligung. Der Check „Cookies vor der Einwilligung“ (auf Englisch) zeigt, ob Ihre Startseite Tracking-Cookies setzt oder Analyse- und Werbewerkzeuge lädt, bevor der Besucher zustimmt. Wenn Sie Datenschutzbeauftragter sind, lesen Sie auch Was ein Datenschutzbeauftragter auf der Website eines Mandanten ohne IT prüfen kann.

Fallen Ihre Kunden unter NIS2, fragen deren Lieferantenfragebögen nach denselben Einstellungen. NIS2 und Ihre Website erklärt, wie Sie sich vorbereiten.

Methode

Domains. Tranco-Liste L5PV4, erstellt am 23. September 2026 um 22:00 UTC aus 30 Tagen Daten (25. August bis 23. September 2026) von fünf Anbietern: Chrome UX Report, Farsight, Majestic, Cloudflare Radar und Cisco Umbrella. Tranco ist ein für die Forschung erstelltes Ranking, das gegen Manipulation gehärtet ist. Ich habe die ersten 1.000 Domains mit der Endung .pl in Rangfolge genommen, einschließlich Second-Level-Domains wie com.pl, gov.pl und edu.pl. Die Top-Million enthält 9.214 .pl-Domains, die ausgewählten 1.000 liegen auf den Rängen 667 bis 136.495. Tranco bewertet Domains, nicht Websites, deshalb enthält die Liste auch technische Domains (CDNs, Werbe- und Messhosts) ohne Startseite.

Wann und von wo. 24. September 2026, von 07:39 bis 07:43 UTC (09:39 bis 09:43 Uhr polnischer Zeit), über eine einzige Netzwerkverbindung in Polen. DNS-Abfragen gingen an die öffentlichen Resolver 1.1.1.1 und 8.8.8.8. Jede HTTP-Anfrage gab sich als ShieldWaveResearch/1.0 mit einem Link auf shieldwave.io zu erkennen und gab sich nicht als Browser aus.

Was gesendet wurde. Pro Domain nur:

1. DNS-Abfragen: Adressen, MX, TXT (SPF und DMARC), CAA,
2. ein Aufruf der Startseite (https://, oder http://, wenn https nicht antwortete, höchstens 5 Umleitungen),
3. eine einfache http://-Anfrage, um zu sehen, ob sie auf https umleitet,
4. TLS-Handshakes auf Port 443: ein vollständiger Handshake und vier Versionsproben (1.0, 1.1, 1.2 und 1.3),
5. eine Anfrage nach /.well-known/security.txt.

Sonst nichts: keine Suche nach Dateien, Admin-Bereichen oder Backups, keine Formulare, Anmeldungen oder Test-Payloads.

Dieselben Prüfungen wie in den kostenlosen Tools. Die Ergebnisse wurden mit demselben Code berechnet, der die kostenlosen Tools von ShieldWave betreibt (Zertifikat, E-Mail, Header und Cookies), Stand Commit 8db196d. Jeder kann seine eigene Domain mit demselben Maßstab prüfen.

Nenner und Ausschlüsse. Jede Zahl hat ihren eigenen Nenner, weil nicht jede Prüfung von jeder Domain eine Antwort bekommt. Von den 1.000 Domains ließen sich 887 Startseiten analysieren. Von den übrigen gaben 38 Domains keine HTTP-Antwort (13 davon haben überhaupt keine Adresse im DNS), 52 antworteten mit einer Bot-Sperre oder einer Blockade wie einem 403, und 23 lieferten einen anderen Fehler. Diese 113 fehlen in den Zahlen zur Startseite (Header, HTML, security.txt, Umleitung), bleiben aber in den Zahlen zu DNS, E-Mail und TLS, die nicht von der Seite abhängen. DNS-Zahlen zählen nur eindeutige Antworten (für DMARC 997 von 1.000).

Definitionen. Eine DMARC-Richtlinie, die Spoofing blockiert, ist der eigene Eintrag der Domain mit p=quarantine oder p=reject und pct=100 oder ohne pct. Ein von einer übergeordneten Domain geerbter Eintrag zählt nicht. HSTS wird nur auf Startseiten gezählt, die auf HTTPS enden, CSP nur, wenn sie durchgesetzt wird. security.txt zählt, wenn die Antwort ein 200 mit einem Feld Contact: ist. Eine HTML-Seite zählt nie.

Grenzen.

• Nur die Startseite, ein Aufruf, ein Tag. Andere Seiten können andere Header senden.
• Kein JavaScript: Tracker und Consent-Werkzeuge werden aus dem HTML gelesen. Was der Google Tag Manager lädt oder Skripte später speichern, sehe ich nicht.
• Viele Ergebnisse spiegeln die Standardeinstellungen eines CDN oder Hosters wider (TLS 1.0 bei Cloudflare, Header, die am Edge hinzugefügt werden oder nicht).
• Websites, die den automatisierten Aufruf blockiert haben, fehlen in den Zahlen zur Startseite und können sich von den übrigen unterscheiden.
• security.txt ist eine Untergrenze, weil Umleitungen nicht gefolgt wurde.
• Die Plattformerkennung ist eine Untergrenze (75,
   % der Startseiten nicht erkannt).
• DKIM wird nicht ausgewertet.
• Gemessen von Polen aus: Websites, die je nach Standort des Besuchers variieren, können anderswo anders aussehen.

Wiederholbarkeit und Kontrollen. Etwa eine Viertelstunde vorher hatte ich einen ersten vollständigen Durchlauf über dieselbe Liste gemacht. Ich veröffentliche ihn nicht, weil ich danach die Erkennung von Gemius korrigiert habe. Abgesehen von den Gemius-Zahlen wich keine der 250 Kennzahlen zwischen den beiden Durchläufen um mehr als 0,9 Prozentpunkte ab, der Median der Abweichung lag bei 0,0. Unabhängig davon habe ich 36 zufällig gewählte Domains, 20 davon aus der polnischen Liste, mit anderen Werkzeugen nachgemessen: DMARC und SPF über einen anderen Resolver (9.9.9.9), HSTS und den Server-Header mit curl, TLS 1.0 mit openssl, security.txt mit curl. Alle 216 Vergleiche stimmten überein.

Daten. Die Rohdaten veröffentliche ich nicht, weil sie einzelne Websites benennen. Alle aggregierten Zahlen, jeweils mit Zähler, Nenner, Prozentwert und Grundgesamtheit, stehen unter CC BY 4.0 kostenlos zum Download: pl-2026-09.csv und pl-2026-09.json (auf Englisch). Die Messung lässt sich wiederholen: Die Tranco-Liste ist öffentlich, und jede Prüfung läuft in den kostenlosen Tools von ShieldWave.

So zitieren Sie

Kurz: Quelle: ShieldWave, Messung der 1.000 beliebtesten .pl-Domains, 24. September 2026, https://shieldwave.io/blog/sicherheit-polnischer-websites-2026/

Vollständig: Radosław Fedorczuk (ShieldWave, ENSOMEDIA), „Wie gut sind die beliebtesten Websites Polens geschützt? 1.000 .pl-Domains gemessen (September 2026)“, 24. September 2026, https://shieldwave.io/blog/sicherheit-polnischer-websites-2026/. Aggregierte Daten unter CC BY 4.0.

Fragen zur Methode oder zu den Daten: support@shieldwave.io.