How well protected are Poland's most popular websites? 1,000 .pl domains measured (September 2026)

I took the first 1,000 .pl domains in the Tranco ranking, a list built for research, and on the morning of 24 September 2026 checked them from the outside, the way any visitor or mail server sees them. The measurement was passive: DNS queries, one visit to each homepage and a few TLS connections per domain, with no vulnerability scanning and no login attempts. The results were counted by the same checks that run in ShieldWave's free tools. I do not name any of the domains.

Key findings

• On 24 September 2026, 460 of the 997 most popular .pl domains (46.1%) had a DMARC policy that tells receiving mail servers to reject or quarantine messages forging the domain. Among domains that receive mail (with MX records), it was 445 of 927 (48.0%).
• In the measurement of 24 September 2026, 406 of 882 popular Polish homepages served over HTTPS (46.0%) sent an HSTS header, and 217 of 887 (24.5%) enforced a Content-Security-Policy.
• In September 2026, 230 of 952 popular .pl domains (24.2%) still accepted TLS 1.0 connections. Of those 230, 149 are served through Cloudflare, which accepts TLS 1.0 until the owner raises the minimum version.
• There is no DMARC record at all for 274 of 997 domains (27.5%), and another 248 (24.9%) have one set to p=none, which blocks nothing.
• In the security headers check, 20 of 887 homepages (2.3%) got the top grade, A, and 290 (32.7%) the lowest, F.
• I found a security.txt file, which tells researchers where to report a vulnerability, on at least 78 of 881 sites (8.9%).
• Of the 46 sites that state their PHP version in a header, 26 run a version that no longer gets any fixes, 11 of them PHP 5.

E-mail: who can send mail as your domain

A forged e-mail with your company's address in the From field is all it takes to send a customer a fake invoice. Three DNS records protect against it: SPF, DKIM and DMARC, which I explain in SPF, DKIM and DMARC explained. DMARC is the one that decides: it tells the receiving server what to do with a message that claims to be yours but fails the checks.

SPF is nearly everywhere: 915 of 999 domains have it (91.6%). SPF alone does not check the address the recipient sees in the From field, though. Only DMARC does, and here the numbers are lower.

• No DMARC record27.5%274 of 997
• p=none: monitors, blocks nothing24.9%248 of 997
• quarantine or reject, but only for part of the mail (pct below 100)1.5%15 of 997
• quarantine or reject for all mail46.1%460 of 997

Domains with a definitive DNS answer. Only the domain's own record counts.

So 460 of 997 domains (46.1%) block spoofing. Among domains with MX records, the ones that receive mail, it is 445 of 927 (48.0%). The others either have no DMARC or have a record that only monitors. Whether a forged message then reaches the inbox is left entirely to the receiving side's own filters.

p=none is not a mistake but the recommended first step: the domain collects reports, and its owner sees who sends mail in its name. Of the 723 DMARC records, 622 (86.0%) include an address for aggregate reports (rua). Protection only starts with quarantine or reject, though. Among domains that have DMARC, the three settings are almost equally common: p=none on 248 of 723 (34.3%), quarantine on 263 (36.4%) and reject on 212 (29.3%).

Smaller SPF faults: 12 of 915 records (1.3%) need more than the 10 DNS lookups the standard allows, two domains publish two SPF records instead of one, and one ends its record in +all, which lets any server send mail in its name.

I do not report DKIM. The selectors under which DKIM keys are published cannot be listed through DNS, so "not found" would only mean "not under the common names".

Encryption: HTTPS, HSTS and TLS

HTTPS itself is standard. The differences are in what goes with it: the HSTS header, old TLS versions and the CAA record.

The denominators differ because each row counts only the domains where that check got an answer. The method section has the details.

HSTS is a header that tells the browser to use only HTTPS for the domain for a set time. Without it, every visit to an address typed without https:// starts with an unencrypted connection before the server redirects it, and on someone else's Wi-Fi that connection can be intercepted. HSTS is sent by 406 of 882 HTTPS homepages (46.0%), and by 268 (30.4%) with the recommended period of at least a year.

TLS 1.0 and 1.1 are old versions of the encryption protocol. Browsers switched them off in 2020, and the IETF formally deprecated them in 2021 (RFC 8996). TLS 1.0 is still accepted by 230 of 952 domains (24.2%). A visitor with a current browser connects over TLS 1.2 or 1.3 anyway, so this is not a way to take over a site. It does mean the server agrees to outdated encryption when asked, and auditors and supplier security questionnaires ask for the old versions to be switched off.

Of those 230 domains, 149 (64.8%) are served through Cloudflare, which accepts TLS 1.0 by default and stops only when the owner raises the minimum version in the dashboard. The other 81 accept TLS 1.0 on their own servers or with other providers.

CAA is a DNS record listing the certificate authorities that may issue certificates for the domain; the others must then refuse. I found one for 192 of 999 domains (19.2%).

Security headers

Security headers are a few lines of instructions the server sends the browser with the page. I describe them in Website security headers: what they are and what to ask for. This is how often they appear on the homepages (HSTS is in the encryption section):

Another 26 homepages (2.9%) have CSP only in Report-Only mode, in which the browser blocks nothing.

The free security headers check grades them from A to F. Each header gets a letter, HSTS and CSP count twice, the others once, and the average gives the final grade. The study used exactly that scale.

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

The scale of the ShieldWave free headers check. HSTS and CSP count twice, the other headers once.

An F does not mean a site has a hole, and an A does not guarantee it has none. Headers are a second line of defence: they limit the damage when something else fails. Missing headers usually mean a server's default setup, which does not add them. Often a CDN or a plugin adds them later.

On the same day and with the same method I measured the 500 most popular .ae domains and the 500 most popular .sa domains (the UAE and Saudi Arabia). Their homepages have CSP (280 of 656, 42.7%) and HSTS (408 of 652, 62.6%) more often. The comparison is a rough one: those lists reach further down the ranking, and 344 of the 1,000 homepages there could not be analysed from Poland. The details are in the write-up of that measurement.

Platforms and outdated software

I recognised a platform on one homepage in four. On 663 of 884 homepages (75.0%) I found no trace of any known platform: these are custom-built sites or ones that do not reveal what they run on. The shares below are therefore lower bounds.

WordPress runs 101 of 884 homepages (11.4%). Next come Drupal (25), Magento (21) and TYPO3 (13). Polish shop platforms (IdoSell, Shoper, AtomStore and RedCart) run 12 between them.

The WordPress version is visible on 54 of the 101. These are small numbers, so I give counts only:

• 28 of the 54 are not on the latest release, 7.1.2,
• 22 are on a branch older than 7.1,
• 18 are not on the latest release of their own branch, so they miss security fixes already published for it,
• the oldest visible version is WordPress 3.5.1, from 2013.

Only 46 of 887 homepages state their PHP version in a header, so this describes those 46, not the whole web. Of those, 26 run branches that no longer get any fixes (8.1 and older), 11 of them PHP 5, whose last branch lost support at the end of 2018. Another 12 get security fixes only (8.2 and 8.3), and 8 are fully supported (8.4 and 8.5).

A server name with a version number, such as Apache/2.4.41, shows in the headers of 74 of 887 homepages (8.3%). Disclosing the version is not a hole in itself, but it narrows down which known bugs apply.

I did not check plugins in this study. If your site runs on WordPress, start with Outdated WordPress plugins: what to update first and what to delete.

security.txt: where to report a vulnerability

The file /.well-known/security.txt (RFC 9116) gives the address where a security researcher can report a vulnerability they found. Without it, a report goes to a general contact address, or nowhere.

I found one with a Contact: field on 78 of 881 sites (8.9%). That is a lower bound: another 41 sites answered with a redirect to a security.txt file at another address, and I did not follow redirects. Even if every one of them led to a valid file, it would be 119 of 881 (13.5%). Of the 78 files, 55 have the Expires field the standard requires.

Trackers and consent platforms

This part is descriptive. No JavaScript ran, so I only see tools named in the homepage's HTML. Whether and when they run I cannot tell: a script may wait for the visitor's consent, and Google Tag Manager can load tools that are not in the page code.

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

In any form: script, install snippet or a bare call. Being in the code does not show whether the tool runs before consent.

Google Analytics or Google Tag Manager appears in the code of 572 of 884 homepages (64.7%). Gemius, Poland's audience measurement system, is on 109 of 884 (12.3%). Google Consent Mode with default denied, in which Google's tools work without cookies until consent is given, shows on 103 of 884 homepages (11.7%).

A known consent platform, such as Cookiebot, OneTrust, Didomi or one using the IAB TCF framework, shows on 293 of 884 homepages (33.1%). That does not mean the rest have no consent banner. Custom banners, banners built into shop platforms and tools loaded through Google Tag Manager are invisible to this method, so I draw no conclusions about legal compliance from these numbers.

What this means for your company

If these settings are missing on some of the most popular sites in the country, they are easy to miss on a smaller one too. Each check below takes a minute and needs no access to your server.

1. E-mail. Run the SPF, DKIM and DMARC check. If you have no DMARC or p=none, move to quarantine step by step as described in SPF, DKIM and DMARC explained. It protects against fake invoices sent from your domain.
2. Encryption. The SSL certificate check shows the certificate, the HTTPS redirect and the TLS versions. If your site is behind Cloudflare, change the minimum in the dashboard under SSL/TLS, Edge Certificates, Minimum TLS Version. Set TLS 1.2.
3. Headers. The security headers check shows what is missing. Website security headers has a brief ready for your developer: start with HSTS with a short max-age and CSP in Report-Only mode.
4. security.txt. Publish /.well-known/security.txt with Contact and Expires fields. It is a few lines of text.
5. Software. Update the CMS and plugins, and remove version numbers from server headers. For WordPress, see Outdated WordPress plugins.
6. Trackers and consent. The cookies before consent check shows whether your homepage sets tracking cookies or loads analytics and advertising tools before the visitor agrees. If you are a data protection officer, see also What a DPO can check on a client's website without IT.

If your clients fall under NIS2, their supplier questionnaires ask about the same settings. NIS2 and your website explains how to prepare.

Method

Domains. Tranco list L5PV4, generated on 23 September 2026 at 22:00 UTC from 30 days of data (25 August to 23 September 2026) from five providers: Chrome UX Report, Farsight, Majestic, Cloudflare Radar and Cisco Umbrella. Tranco is a ranking built for research and hardened against manipulation. I took the first 1,000 domains ending in .pl in rank order, second-level domains such as com.pl, gov.pl and edu.pl included. The top million holds 9,214 .pl domains; the chosen 1,000 rank from 667 to 136,495. Tranco ranks domains, not websites, so the list also holds technical domains (CDNs, ad and measurement hosts) without a homepage.

When and from where. 24 September 2026, from 07:39 to 07:43 UTC (09:39 to 09:43 Polish time), from one network connection in Poland. DNS queries went to the public resolvers 1.1.1.1 and 8.8.8.8. Every HTTP request identified itself as ShieldWaveResearch/1.0 with a link to shieldwave.io; it did not pretend to be a browser.

What was sent. Per domain, only:

1. DNS queries: addresses, MX, TXT (SPF and DMARC), CAA,
2. one visit to the homepage (https://, or http:// when https did not answer; at most 5 redirects),
3. one plain http:// request to see whether it redirects to https,
4. TLS handshakes on port 443: one full handshake and four version probes (1.0, 1.1, 1.2 and 1.3),
5. one request for /.well-known/security.txt.

Nothing else: no probing for files, admin panels or backups, and no forms, logins or test payloads.

Same checks as the free tools. The results were computed by the same code that runs ShieldWave's free tools (certificate, e-mail, headers and cookies), as of commit 8db196d. Anyone can check their own domain by the same measure.

Denominators and exclusions. Each figure has its own denominator, because not every check gets an answer from every domain. Of the 1,000 domains, 887 homepages could be analysed. Of the rest, 38 domains gave no HTTP answer (13 of them have no address in DNS at all), 52 answered with a bot wall or a block such as a 403, and 23 returned another error. These 113 are left out of the homepage figures (headers, HTML, security.txt, redirect) but stay in the DNS, e-mail and TLS figures, which do not depend on the page. DNS figures count only definitive answers (for DMARC, 997 of 1,000).

Definitions. A DMARC policy that blocks spoofing is the domain's own record with p=quarantine or p=reject and pct=100 or no pct. A record inherited from a parent domain does not count. HSTS is counted only on homepages that end on HTTPS, and CSP only when enforced. security.txt counts when the answer is a 200 with a Contact: field; an HTML page never counts.

Limitations.

• Homepage only, one visit, one day. Other pages may send other headers.
• No JavaScript: trackers and consent tools are read from the HTML. I cannot see what Google Tag Manager loads or what scripts store later.
• Many results reflect a CDN's or host's defaults (TLS 1.0 on Cloudflare, headers added or not at the edge).
• Sites that blocked the automated visit are missing from the homepage figures, and they may differ from the ones that remain.
• security.txt is a lower bound, because redirects were not followed.
• Platform detection is a lower bound (75.0% of homepages unrecognised).
• DKIM is not reported.
• Measured from Poland: sites that vary by visitor location may look different elsewhere.

Repeatability and checks. About a quarter of an hour earlier I ran a first full pass over the same list. I do not publish it, because I fixed the Gemius detection after it. Apart from the Gemius figures, none of the 250 metrics differed between the two runs by more than 0.9 percentage points, and the median difference was 0.0. Separately, I re-measured 36 randomly chosen domains, 20 of them from the Polish list, with other tools: DMARC and SPF through a different resolver (9.9.9.9), HSTS and the Server header with curl, TLS 1.0 with openssl, security.txt with curl. All 216 comparisons agreed.

Data. I do not publish the raw data, because it names individual sites. All aggregate figures, each with numerator, denominator, percentage and population, are free to download under CC BY 4.0: pl-2026-09.csv and pl-2026-09.json. The measurement can be repeated: the Tranco list is public, and every check runs in ShieldWave's free tools.

How to cite

Short: Source: ShieldWave, measurement of the 1,000 most popular .pl domains, 24 September 2026, https://shieldwave.io/blog/polish-websites-security-2026/

Full: Radosław Fedorczuk (ShieldWave, ENSOMEDIA), "How well protected are Poland's most popular websites? 1,000 .pl domains measured (September 2026)", 24 September 2026, https://shieldwave.io/blog/polish-websites-security-2026/. Aggregate data under CC BY 4.0.

Questions about the method or the data: support@shieldwave.io.