PUBLIC DOMAIN DOSSIER

itylos.com

What is observed, how to verify it and what changed

4 public observations are documented in this dossier.

1 structuring public dependencies are visible.

No useful change is retained since the previous reading.

2 points still require confirmation or cannot be observed from outside.

Measured 2026-09-04 19:29 UTC First observation 2026-09-04 19:29 UTC Latest observation 2026-09-06 02:09 UTC

History Compare JSON Markdown

TIME

What changed over time

Initial reference point created today

0Appeared

0Modified

0Stable

0Disappeared

SHORT VIEW

Four readings before the detail

The 12 historical angles remain available below for deeper inspection.

Identity & governance

Not testedCanary detection
Not observable from outsideOrigin host
ObservedDepends on providerCloudflare

Infrastructure & transport

ObservedTls issuerC = US, O = Let's Encrypt, CN = YE2
Not testedPost quantum tls

Mail & trust

ObservedDmarc policyreject
ObservedSpf policysoftfail

Dependencies & exposure

Not observable from outsideData location

Explanatory record

What Scanapse understands about this domain

Scanapse has enough material to describe 11 of 12 knowledge angles for itylos.com. 4 questions remain open with the available public evidence.

Measured on 2026-09-04 19:29 UTC Engine 2.6.0.1

Read the domain folder

The key points for reading this domain folder

Four key points to understand what Scanapse observed, what can reasonably be retained, and what still needs verification.

Key points

Worth looking at today

Only a few items are shown when they add something genuinely useful to the reading.

DEPENDENCIES

Critical function concentration

Cloudflare is associated with 6 critical function(s) or observations in the visible scope.

This concentration is descriptive. It does not prove a future outage or the absence of failover mechanisms invisible to the scan.

Territorial and legal context

Which legal context can reasonably be retained

Scanapse distinguishes established, probable and to-confirm jurisdiction and always explains which clues support the reading.

To confirm To confirm

Why this context appears

No sufficiently reliable public jurisdiction clue was found in the report

What this does not establish

Technical hosting, IP addresses, ASNs and CDN locations do not establish the applicable legal jurisdiction by themselves.
The applicable jurisdiction requires additional public or organisational evidence.

Regulatory frameworks

Useful texts for this context

References are selected from the observed context. Their presence explains potential relevance, never automatic compliance.

To confirmTo determine

Regulatory context to determine

The available public evidence does not establish a sufficiently reliable jurisdiction for automatic legal contextualisation.

This section provides documentary context. It is not legal advice, certification or a compliance verdict.

Trajectory

Useful changes since the previous reading

Only differences that help interpretation are highlighted. Stable or purely technical variations remain available in the evidence.

No significant change retained

The available comparison does not surface a change worth highlighting in the public reading.

12 knowledge angles

12 angles to understand the domain

Each angle explains what is known, why it matters, how to read it, its purpose and its limits.

Documented First observation

Domain identity

Public evidence provides enough material to document this angle

Documented First observation

Infrastructure

Public evidence provides enough material to document this angle

Partial First observation

Encryption and transport

This angle is only partially documented by public evidence

Documented First observation

Mail and trust

Public evidence provides enough material to document this angle

Documented First observation

DNS and governance

Public evidence provides enough material to document this angle

Documented First observation

External dependencies

Public evidence provides enough material to document this angle

Documented First observation

Observable technologies

Public evidence provides enough material to document this angle

Partial First observation

Public exposure

This angle is only partially documented by public evidence

Documented First observation

Documentary trust

Public evidence provides enough material to document this angle

Documented First observation

Security signals

Public evidence provides enough material to document this angle

To determine First observation

Evolution over time

This angle still needs additional public evidence

Documented First observation

Evidence and traceability

Public evidence provides enough material to document this angle

Overview

What the domain already shows, and what still needs clarification

An overview of visible relationships and uncertainty areas that still need verification.

Visible relations

Visible relations around the domain

Relations are grouped by function. They describe what is publicly visible, not contracts or the full internal architecture.

Observed domain itylos.com

DNS

DNS server Observed

david.ns.cloudflare.com

DNS server Observed

thea.ns.cloudflare.com

mail

Mail server Observed

route1.mx.cloudflare.net

Mail server Observed

route2.mx.cloudflare.net

Mail server Observed

route3.mx.cloudflare.net

technology

Observed technology Observed

cloudflare

external resources

External provider or resource Corroborated

Cloudflare

Open questions

4 areas to confirm

An unknown becomes useful information when it precisely explains what is missing to reach a conclusion.

To confirm

Origin hosting

An edge service does not reveal the origin hosting provider.

To confirm

Effective data location

Public provider metadata does not prove where data is actually processed.

To confirm

Post-quantum TLS exchange

This check was not run with a compatible client during this measurement.

To confirm

Public canary signal

Detection of this signal was not enabled for this measurement.

These items do not mean there is a problem. They simply show that useful information is still missing.

Sources and evidence

Evidence supporting this reading

37 evidence items are available. They remain collapsed to preserve a short reading and can be explored on demand.

37evidence items available

Each proof keeps its method, provenance, date, reliability and interpretation limits.

Download evidence JSON

Explore evidence

#01 DNS public records

Evidence: dns_nameserver

DNS shows how a domain resolves and which public services are associated with it.

Passive High

Why it matters

Consistent, verifiable resolution reduces some spoofing risks and helps explain entity dependencies.

What to check next

Compare NS, A/AAAA, MX, CAA and the DNSSEC chain with previous measurements to identify delegation or operator changes.

Possible action

If a change is unexpected, verify registrar and DNS-provider configuration before modifying anything. Document the failover mechanisms that actually exist.

Observation: david.ns.cloudflare.com
Understand: Standard DNS resolution and record parsing
Source: DNS public records
Reliability: High
What this supports: Describe public DNS data observed at scan time
What this does not prove: Public DNS does not prove physical server location, contracts, or global availability.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

DNSSEC introduction and requirements RFC 4033
DNSSEC resource records RFC 4034
DNSSEC protocol modifications RFC 4035
Certification Authority Authorization RFC 8659
Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

Verify it yourself

This command reproduces the public observation without changing the target.

dig NS itylos.com

View raw data

david.ns.cloudflare.com

Rule 2026.09.4 · 2026-09-04T19:29:06+00:00

#02 Mail-related public records

Evidence: module_finding

Public mail policies show how the domain frames sending, authentication and email transport.

Active non-intrusive High

Why it matters

These mechanisms can reduce domain spoofing and document mail-transport posture.

What to check next

Relate SPF, DKIM when a selector is known, DMARC, MX, MTA-STS and TLS-RPT. Compare policy changes over time.

Possible action

Before strengthening a policy, inventory legitimate mail flows and verify alignment. Roll out changes progressively to avoid blocking authorized senders.

Observation: { "evidence": null, "severity": "low" }
Understand: Public DNS and policy endpoint inspection
Source: Mail-related public records
Reliability: High
What this supports: Describe published mail authentication and transport policies
What this does not prove: They do not prove actual deliverability, every recipient’s behavior, or the absence of phishing.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

Sender Policy Framework RFC 7208
Domain-based Message Authentication, Reporting, and Conformance RFC 7489
SMTP TLS Reporting RFC 8460
SMTP MTA Strict Transport Security RFC 8461

View raw data

{
    "evidence": null,
    "severity": "low"
}

Rule 2026.09.4 · 2026-09-04T19:29:06+00:00

#03 DNS public records

Evidence: dns_nameserver

DNS shows how a domain resolves and which public services are associated with it.

Passive High

Why it matters

Consistent, verifiable resolution reduces some spoofing risks and helps explain entity dependencies.

What to check next

Compare NS, A/AAAA, MX, CAA and the DNSSEC chain with previous measurements to identify delegation or operator changes.

Possible action

If a change is unexpected, verify registrar and DNS-provider configuration before modifying anything. Document the failover mechanisms that actually exist.

Observation: thea.ns.cloudflare.com
Understand: Standard DNS resolution and record parsing
Source: DNS public records
Reliability: High
What this supports: Describe public DNS data observed at scan time
What this does not prove: Public DNS does not prove physical server location, contracts, or global availability.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

DNSSEC introduction and requirements RFC 4033
DNSSEC resource records RFC 4034
DNSSEC protocol modifications RFC 4035
Certification Authority Authorization RFC 8659
Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

Verify it yourself

This command reproduces the public observation without changing the target.

dig NS itylos.com

View raw data

thea.ns.cloudflare.com

Rule 2026.09.4 · 2026-09-04T19:29:06+00:00

#04 Public HTTP response

Evidence: http_header

HTTP headers can ask the browser to enforce specific protections.

Active non-intrusive High

Why it matters

They are visible, verifiable browser-side defensive layers.

What to check next

Read each full policy, identify permissive or contradictory directives, and compare responses across the main public routes.

Possible action

Harden policies progressively from actual application needs. Avoid copying generic templates without functional testing.

Observation: [ "require-corp" ]
Understand: HTTP response-header inspection
Source: Public HTTP response
Reliability: High
What this supports: Describe defensive policies declared on the observed response
What this does not prove: A header being present does not prove it is optimal or that the application has no vulnerabilities.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

View raw data

[
    "require-corp"
]

Rule 2026.09.4 · 2026-09-04T19:29:06+00:00

#05 DNS public records

Evidence: mail_exchanger

DNS shows how a domain resolves and which public services are associated with it.

Passive High

Why it matters

Consistent, verifiable resolution reduces some spoofing risks and helps explain entity dependencies.

What to check next

Compare NS, A/AAAA, MX, CAA and the DNSSEC chain with previous measurements to identify delegation or operator changes.

Possible action

If a change is unexpected, verify registrar and DNS-provider configuration before modifying anything. Document the failover mechanisms that actually exist.

Observation: route3.mx.cloudflare.net
Understand: Standard DNS resolution and record parsing
Source: DNS public records
Reliability: High
What this supports: Describe public DNS data observed at scan time
What this does not prove: Public DNS does not prove physical server location, contracts, or global availability.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

DNSSEC introduction and requirements RFC 4033
DNSSEC resource records RFC 4034
DNSSEC protocol modifications RFC 4035
Certification Authority Authorization RFC 8659
Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

Verify it yourself

This command reproduces the public observation without changing the target.

dig MX itylos.com

View raw data

route3.mx.cloudflare.net

Rule 2026.09.4 · 2026-09-04T19:29:06+00:00

#06 DNS public records

Evidence: mail_exchanger

DNS shows how a domain resolves and which public services are associated with it.

Passive High

Why it matters

Consistent, verifiable resolution reduces some spoofing risks and helps explain entity dependencies.

What to check next

Compare NS, A/AAAA, MX, CAA and the DNSSEC chain with previous measurements to identify delegation or operator changes.

Possible action

If a change is unexpected, verify registrar and DNS-provider configuration before modifying anything. Document the failover mechanisms that actually exist.

Observation: route1.mx.cloudflare.net
Understand: Standard DNS resolution and record parsing
Source: DNS public records
Reliability: High
What this supports: Describe public DNS data observed at scan time
What this does not prove: Public DNS does not prove physical server location, contracts, or global availability.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

DNSSEC introduction and requirements RFC 4033
DNSSEC resource records RFC 4034
DNSSEC protocol modifications RFC 4035
Certification Authority Authorization RFC 8659
Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

Verify it yourself

This command reproduces the public observation without changing the target.

dig MX itylos.com

View raw data

route1.mx.cloudflare.net

Rule 2026.09.4 · 2026-09-04T19:29:06+00:00

#07 Mail-related public records

Evidence: mail_policy_flag

Public mail policies show how the domain frames sending, authentication and email transport.

Active non-intrusive High

Why it matters

These mechanisms can reduce domain spoofing and document mail-transport posture.

What to check next

Relate SPF, DKIM when a selector is known, DMARC, MX, MTA-STS and TLS-RPT. Compare policy changes over time.

Possible action

Before strengthening a policy, inventory legitimate mail flows and verify alignment. Roll out changes progressively to avoid blocking authorized senders.

Observation
Understand: Public DNS and policy endpoint inspection
Source: Mail-related public records
Reliability: High
What this supports: Describe published mail authentication and transport policies
What this does not prove: They do not prove actual deliverability, every recipient’s behavior, or the absence of phishing.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

Sender Policy Framework RFC 7208
Domain-based Message Authentication, Reporting, and Conformance RFC 7489
SMTP TLS Reporting RFC 8460
SMTP MTA Strict Transport Security RFC 8461

View raw data

Rule 2026.09.4 · 2026-09-04T19:29:06+00:00

#08 Mail-related public records

Evidence: dmarc_policy

Public mail policies show how the domain frames sending, authentication and email transport.

Active non-intrusive High

Why it matters

These mechanisms can reduce domain spoofing and document mail-transport posture.

What to check next

Relate SPF, DKIM when a selector is known, DMARC, MX, MTA-STS and TLS-RPT. Compare policy changes over time.

Possible action

Before strengthening a policy, inventory legitimate mail flows and verify alignment. Roll out changes progressively to avoid blocking authorized senders.

Observation: reject
Understand: Public DNS and policy endpoint inspection
Source: Mail-related public records
Reliability: High
What this supports: Describe published mail authentication and transport policies
What this does not prove: They do not prove actual deliverability, every recipient’s behavior, or the absence of phishing.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

Sender Policy Framework RFC 7208
Domain-based Message Authentication, Reporting, and Conformance RFC 7489
SMTP TLS Reporting RFC 8460
SMTP MTA Strict Transport Security RFC 8461

Verify it yourself

This command reproduces the public observation without changing the target.

dig TXT _dmarc.itylos.com

View raw data

reject

Rule 2026.09.4 · 2026-09-04T19:29:06+00:00

#09 DNS public records

Evidence: mail_exchanger

DNS shows how a domain resolves and which public services are associated with it.

Passive High

Why it matters

Consistent, verifiable resolution reduces some spoofing risks and helps explain entity dependencies.

What to check next

Compare NS, A/AAAA, MX, CAA and the DNSSEC chain with previous measurements to identify delegation or operator changes.

Possible action

If a change is unexpected, verify registrar and DNS-provider configuration before modifying anything. Document the failover mechanisms that actually exist.

Observation: route2.mx.cloudflare.net
Understand: Standard DNS resolution and record parsing
Source: DNS public records
Reliability: High
What this supports: Describe public DNS data observed at scan time
What this does not prove: Public DNS does not prove physical server location, contracts, or global availability.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

DNSSEC introduction and requirements RFC 4033
DNSSEC resource records RFC 4034
DNSSEC protocol modifications RFC 4035
Certification Authority Authorization RFC 8659
Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

Verify it yourself

This command reproduces the public observation without changing the target.

dig MX itylos.com

View raw data

route2.mx.cloudflare.net

Rule 2026.09.4 · 2026-09-04T19:29:06+00:00

#10 Mail-related public records

Evidence: mail_policy_flag

Public mail policies show how the domain frames sending, authentication and email transport.

Active non-intrusive High

Why it matters

These mechanisms can reduce domain spoofing and document mail-transport posture.

What to check next

Relate SPF, DKIM when a selector is known, DMARC, MX, MTA-STS and TLS-RPT. Compare policy changes over time.

Possible action

Before strengthening a policy, inventory legitimate mail flows and verify alignment. Roll out changes progressively to avoid blocking authorized senders.

Observation
Understand: Public DNS and policy endpoint inspection
Source: Mail-related public records
Reliability: High
What this supports: Describe published mail authentication and transport policies
What this does not prove: They do not prove actual deliverability, every recipient’s behavior, or the absence of phishing.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

Sender Policy Framework RFC 7208
Domain-based Message Authentication, Reporting, and Conformance RFC 7489
SMTP TLS Reporting RFC 8460
SMTP MTA Strict Transport Security RFC 8461

View raw data

Rule 2026.09.4 · 2026-09-04T19:29:06+00:00

#11 Public HTTP response

Evidence: http_header

HTTP headers can ask the browser to enforce specific protections.

Active non-intrusive High

Why it matters

They are visible, verifiable browser-side defensive layers.

What to check next

Read each full policy, identify permissive or contradictory directives, and compare responses across the main public routes.

Possible action

Harden policies progressively from actual application needs. Avoid copying generic templates without functional testing.

Observation: [ "no-referrer" ]
Understand: HTTP response-header inspection
Source: Public HTTP response
Reliability: High
What this supports: Describe defensive policies declared on the observed response
What this does not prove: A header being present does not prove it is optimal or that the application has no vulnerabilities.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

View raw data

[
    "no-referrer"
]

Rule 2026.09.4 · 2026-09-04T19:29:06+00:00

#12 DNS public records

Evidence: dns_address

DNS shows how a domain resolves and which public services are associated with it.

Passive High

Why it matters

Consistent, verifiable resolution reduces some spoofing risks and helps explain entity dependencies.

What to check next

Compare NS, A/AAAA, MX, CAA and the DNSSEC chain with previous measurements to identify delegation or operator changes.

Possible action

If a change is unexpected, verify registrar and DNS-provider configuration before modifying anything. Document the failover mechanisms that actually exist.

Observation: 172.67.131.153
Understand: Standard DNS resolution and record parsing
Source: DNS public records
Reliability: High
What this supports: Describe public DNS data observed at scan time
What this does not prove: Public DNS does not prove physical server location, contracts, or global availability.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

DNSSEC introduction and requirements RFC 4033
DNSSEC resource records RFC 4034
DNSSEC protocol modifications RFC 4035
Certification Authority Authorization RFC 8659
Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

Verify it yourself

This command reproduces the public observation without changing the target.

dig A itylos.com && dig AAAA itylos.com

View raw data

172.67.131.153

Rule 2026.09.4 · 2026-09-04T19:29:06+00:00

#13 Mail-related public records

Evidence: mail_policy_flag

Public mail policies show how the domain frames sending, authentication and email transport.

Active non-intrusive High

Why it matters

These mechanisms can reduce domain spoofing and document mail-transport posture.

What to check next

Relate SPF, DKIM when a selector is known, DMARC, MX, MTA-STS and TLS-RPT. Compare policy changes over time.

Possible action

Before strengthening a policy, inventory legitimate mail flows and verify alignment. Roll out changes progressively to avoid blocking authorized senders.

Observation
Understand: Public DNS and policy endpoint inspection
Source: Mail-related public records
Reliability: High
What this supports: Describe published mail authentication and transport policies
What this does not prove: They do not prove actual deliverability, every recipient’s behavior, or the absence of phishing.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

Sender Policy Framework RFC 7208
Domain-based Message Authentication, Reporting, and Conformance RFC 7489
SMTP TLS Reporting RFC 8460
SMTP MTA Strict Transport Security RFC 8461

View raw data

Rule 2026.09.4 · 2026-09-04T19:29:06+00:00

#14 Public HTTP response

Evidence: http_header

HTTP headers can ask the browser to enforce specific protections.

Active non-intrusive High

Why it matters

They are visible, verifiable browser-side defensive layers.

What to check next

Read each full policy, identify permissive or contradictory directives, and compare responses across the main public routes.

Possible action

Harden policies progressively from actual application needs. Avoid copying generic templates without functional testing.

Observation: [ "same-origin" ]
Understand: HTTP response-header inspection
Source: Public HTTP response
Reliability: High
What this supports: Describe defensive policies declared on the observed response
What this does not prove: A header being present does not prove it is optimal or that the application has no vulnerabilities.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

View raw data

[
    "same-origin"
]

Rule 2026.09.4 · 2026-09-04T19:29:06+00:00

#15 technology

Evidence: technology

Scanapse shows visible providers and third-party services on which the public service depends.

Passive Medium

Why it matters

Concentration on one actor or many third parties can affect continuity and governance.

What to check next

Identify each provider role, functions concentrated on the same actor, and dependencies that appeared or disappeared since the previous scan.

Possible action

For a critical dependency, document owner, contract, reversibility, failover and rationale. Diversify only after analysing the actual need.

Observation: { "name": "cloudflare", "version": "", "version_exposed": false }
Understand: Public observation
Source: technology
Reliability: Medium
What this supports: Describe the observed public artefact
What this does not prove: A visible dependency does not prove data location, actual contractual jurisdiction, or hidden subcontractors.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

Directive (EU) 2022/2555 - supply-chain risk context Context only, scope must be established separately
Regulation (EU) 2022/2554 - DORA ICT third-party risk context for entities in scope

View raw data

{
    "name": "cloudflare",
    "version": "",
    "version_exposed": false
}

Rule 2026.09.4 · 2026-09-04T19:29:06+00:00

#16 Mail-related public records

Evidence: spf_policy

Public mail policies show how the domain frames sending, authentication and email transport.

Active non-intrusive High

Why it matters

These mechanisms can reduce domain spoofing and document mail-transport posture.

What to check next

Relate SPF, DKIM when a selector is known, DMARC, MX, MTA-STS and TLS-RPT. Compare policy changes over time.

Possible action

Before strengthening a policy, inventory legitimate mail flows and verify alignment. Roll out changes progressively to avoid blocking authorized senders.

Observation: softfail
Understand: Public DNS and policy endpoint inspection
Source: Mail-related public records
Reliability: High
What this supports: Describe published mail authentication and transport policies
What this does not prove: They do not prove actual deliverability, every recipient’s behavior, or the absence of phishing.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

Sender Policy Framework RFC 7208
Domain-based Message Authentication, Reporting, and Conformance RFC 7489
SMTP TLS Reporting RFC 8460
SMTP MTA Strict Transport Security RFC 8461

Verify it yourself

This command reproduces the public observation without changing the target.

dig TXT itylos.com

View raw data

softfail

Rule 2026.09.4 · 2026-09-04T19:29:06+00:00

#17 DNS public records

Evidence: dns_address

DNS shows how a domain resolves and which public services are associated with it.

Passive High

Why it matters

Consistent, verifiable resolution reduces some spoofing risks and helps explain entity dependencies.

What to check next

Compare NS, A/AAAA, MX, CAA and the DNSSEC chain with previous measurements to identify delegation or operator changes.

Possible action

If a change is unexpected, verify registrar and DNS-provider configuration before modifying anything. Document the failover mechanisms that actually exist.

Observation: 2606:4700:3031::6815:420
Understand: Standard DNS resolution and record parsing
Source: DNS public records
Reliability: High
What this supports: Describe public DNS data observed at scan time
What this does not prove: Public DNS does not prove physical server location, contracts, or global availability.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

DNSSEC introduction and requirements RFC 4033
DNSSEC resource records RFC 4034
DNSSEC protocol modifications RFC 4035
Certification Authority Authorization RFC 8659
Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

Verify it yourself

This command reproduces the public observation without changing the target.

dig A itylos.com && dig AAAA itylos.com

View raw data

2606:4700:3031::6815:420

Rule 2026.09.4 · 2026-09-04T19:29:06+00:00

#18 Public TLS endpoint

Evidence: tls_valid_to

TLS protects the observed connection between the scanner and the public service.

Active non-intrusive High

Why it matters

These elements document public-channel protection and the cryptographic mechanisms actually negotiated.

What to check next

Compare negotiated protocol, issuer, expiry, chain and cryptographic parameters with history. Check other public entry points separately.

Possible action

Address only observed gaps such as an expiring certificate, invalid chain, or unwanted protocol. Test changes in a controlled environment before deployment.

Observation: 2026-11-14T23:25:56+00:00
Understand: TLS handshake and public certificate inspection
Source: Public TLS endpoint
Reliability: High
What this supports: Describe the TLS session and certificate presented to Scanapse
What this does not prove: Strong TLS does not prove application security or origin-server security behind a CDN or reverse proxy.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

TLS 1.3 RFC 8446
Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

View raw data

2026-11-14T23:25:56+00:00

Rule 2026.09.4 · 2026-09-04T19:29:06+00:00

#19 Observed public resources

Evidence: dependency_provider

Scanapse shows visible providers and third-party services on which the public service depends.

Passive Medium

Why it matters

Concentration on one actor or many third parties can affect continuity and governance.

What to check next

Identify each provider role, functions concentrated on the same actor, and dependencies that appeared or disappeared since the previous scan.

Possible action

For a critical dependency, document owner, contract, reversibility, failover and rationale. Diversify only after analysing the actual need.

Observation: { "critical": true, "hosts": [ "cloudflare.com", "david.ns.cloudflare.com", "route1.mx.cloudflare.net", "route2.mx.cloudflare.net", "route3.mx.cloudflare.net", "thea.ns.cloudflare.com" ], "id": "cloudflare", "known": true, "name": "Cloudflare", "observation_count": 6, "services": [ "cdn", "security" ], "tracker": false }
Understand: Public HTML/resource dependency extraction and provider matching
Source: Observed public resources
Reliability: Medium
What this supports: Describe visible third-party dependencies
What this does not prove: A visible dependency does not prove data location, actual contractual jurisdiction, or hidden subcontractors.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

Directive (EU) 2022/2555 - supply-chain risk context Context only, scope must be established separately
Regulation (EU) 2022/2554 - DORA ICT third-party risk context for entities in scope

View raw data

{
    "critical": true,
    "hosts": [
        "cloudflare.com",
        "david.ns.cloudflare.com",
        "route1.mx.cloudflare.net",
        "route2.mx.cloudflare.net",
        "route3.mx.cloudflare.net",
        "thea.ns.cloudflare.com"
    ],
    "id": "cloudflare",
    "known": true,
    "name": "Cloudflare",
    "observation_count": 6,
    "services": [
        "cdn",
        "security"
    ],
    "tracker": false
}

Rule 2026.09.4 · 2026-09-04T19:29:06+00:00

#20 Public HTTP response

Evidence: http_header

HTTP headers can ask the browser to enforce specific protections.

Active non-intrusive High

Why it matters

They are visible, verifiable browser-side defensive layers.

What to check next

Read each full policy, identify permissive or contradictory directives, and compare responses across the main public routes.

Possible action

Harden policies progressively from actual application needs. Avoid copying generic templates without functional testing.

Observation: [ "max-age=63072000; includeSubDomains; preload" ]
Understand: HTTP response-header inspection
Source: Public HTTP response
Reliability: High
What this supports: Describe defensive policies declared on the observed response
What this does not prove: A header being present does not prove it is optimal or that the application has no vulnerabilities.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

View raw data

[
    "max-age=63072000; includeSubDomains; preload"
]

Rule 2026.09.4 · 2026-09-04T19:29:06+00:00

#21 DNS public records

Evidence: module_finding

DNS shows how a domain resolves and which public services are associated with it.

Passive High

Why it matters

Consistent, verifiable resolution reduces some spoofing risks and helps explain entity dependencies.

What to check next

Compare NS, A/AAAA, MX, CAA and the DNSSEC chain with previous measurements to identify delegation or operator changes.

Possible action

If a change is unexpected, verify registrar and DNS-provider configuration before modifying anything. Document the failover mechanisms that actually exist.

Observation: { "evidence": { "reason": "No external validating resolver is used; DS validation is intentionally not inferred.", "status": "not_tested" }, "severity": "info" }
Understand: Standard DNS resolution and record parsing
Source: DNS public records
Reliability: High
What this supports: Describe public DNS data observed at scan time
What this does not prove: Public DNS does not prove physical server location, contracts, or global availability.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

DNSSEC introduction and requirements RFC 4033
DNSSEC resource records RFC 4034
DNSSEC protocol modifications RFC 4035
Certification Authority Authorization RFC 8659
Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

View raw data

{
    "evidence": {
        "reason": "No external validating resolver is used; DS validation is intentionally not inferred.",
        "status": "not_tested"
    },
    "severity": "info"
}

Rule 2026.09.4 · 2026-09-04T19:29:06+00:00

#22 Public HTTP response

Evidence: http_header

HTTP headers can ask the browser to enforce specific protections.

Active non-intrusive High

Why it matters

They are visible, verifiable browser-side defensive layers.

What to check next

Read each full policy, identify permissive or contradictory directives, and compare responses across the main public routes.

Possible action

Harden policies progressively from actual application needs. Avoid copying generic templates without functional testing.

Observation: [ "default-src 'none'; script-src 'self' 'nonce-toLeNwv8wEPVP5Mgm750Tg=='; style-src 'self' 'nonce-toLeNwv8wEPVP5Mgm750Tg=='; img-src 'self' data: blob:; font-src 'self'; connect-src 'self'; worker-src 'self'; manifest-src 'self'; frame-ancestors 'none'; base-uri 'none'; form-action 'self';" ]
Understand: HTTP response-header inspection
Source: Public HTTP response
Reliability: High
What this supports: Describe defensive policies declared on the observed response
What this does not prove: A header being present does not prove it is optimal or that the application has no vulnerabilities.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

View raw data

[
    "default-src 'none'; script-src 'self' 'nonce-toLeNwv8wEPVP5Mgm750Tg=='; style-src 'self' 'nonce-toLeNwv8wEPVP5Mgm750Tg=='; img-src 'self' data: blob:; font-src 'self'; connect-src 'self'; worker-src 'self'; manifest-src 'self'; frame-ancestors 'none'; base-uri 'none'; form-action 'self';"
]

Rule 2026.09.4 · 2026-09-04T19:29:06+00:00

#23 Public HTTP response

Evidence: http_header

HTTP headers can ask the browser to enforce specific protections.

Active non-intrusive High

Why it matters

They are visible, verifiable browser-side defensive layers.

What to check next

Read each full policy, identify permissive or contradictory directives, and compare responses across the main public routes.

Possible action

Harden policies progressively from actual application needs. Avoid copying generic templates without functional testing.

Observation: [ "nosniff" ]
Understand: HTTP response-header inspection
Source: Public HTTP response
Reliability: High
What this supports: Describe defensive policies declared on the observed response
What this does not prove: A header being present does not prove it is optimal or that the application has no vulnerabilities.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

View raw data

[
    "nosniff"
]

Rule 2026.09.4 · 2026-09-04T19:29:06+00:00

#24 Public HTTP response

Evidence: http_header

HTTP headers can ask the browser to enforce specific protections.

Active non-intrusive High

Why it matters

They are visible, verifiable browser-side defensive layers.

What to check next

Read each full policy, identify permissive or contradictory directives, and compare responses across the main public routes.

Possible action

Harden policies progressively from actual application needs. Avoid copying generic templates without functional testing.

Observation: [ "DENY" ]
Understand: HTTP response-header inspection
Source: Public HTTP response
Reliability: High
What this supports: Describe defensive policies declared on the observed response
What this does not prove: A header being present does not prove it is optimal or that the application has no vulnerabilities.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

View raw data

[
    "DENY"
]

Rule 2026.09.4 · 2026-09-04T19:29:06+00:00

#25 Public HTTP response

Evidence: http_header

HTTP headers can ask the browser to enforce specific protections.

Active non-intrusive High

Why it matters

They are visible, verifiable browser-side defensive layers.

What to check next

Read each full policy, identify permissive or contradictory directives, and compare responses across the main public routes.

Possible action

Harden policies progressively from actual application needs. Avoid copying generic templates without functional testing.

Observation: [ "accelerometer=(), autoplay=(), camera=(), cross-origin-isolated=(), display-capture=(), encrypted-media=(), fullscreen=(), geolocation=(), gyroscope=(), keyboard-map=(), magnetometer=(), microphone=(), midi=(), payment=(), picture-in-picture=(), publickey-credentials-get=(), screen-wake-lock=(), sync-xhr=(self), usb=(), web-share=(), xr-spatial-tracking=(), clipboard-read=(), clipboard-write=(self), gamepad=(), hid=(), idle-detection=(), serial=(), unload=()" ]
Understand: HTTP response-header inspection
Source: Public HTTP response
Reliability: High
What this supports: Describe defensive policies declared on the observed response
What this does not prove: A header being present does not prove it is optimal or that the application has no vulnerabilities.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

View raw data

[
    "accelerometer=(), autoplay=(), camera=(), cross-origin-isolated=(), display-capture=(), encrypted-media=(), fullscreen=(), geolocation=(), gyroscope=(), keyboard-map=(), magnetometer=(), microphone=(), midi=(), payment=(), picture-in-picture=(), publickey-credentials-get=(), screen-wake-lock=(), sync-xhr=(self), usb=(), web-share=(), xr-spatial-tracking=(), clipboard-read=(), clipboard-write=(self), gamepad=(), hid=(), idle-detection=(), serial=(), unload=()"
]

Rule 2026.09.4 · 2026-09-04T19:29:06+00:00

#26 module_finding

Evidence: module_finding

Scanapse shows visible providers and third-party services on which the public service depends.

Passive Medium

Why it matters

Concentration on one actor or many third parties can affect continuity and governance.

What to check next

Identify each provider role, functions concentrated on the same actor, and dependencies that appeared or disappeared since the previous scan.

Possible action

For a critical dependency, document owner, contract, reversibility, failover and rationale. Diversify only after analysing the actual need.

Observation: { "evidence": [ "david.ns.cloudflare.com", "thea.ns.cloudflare.com" ], "severity": "medium" }
Understand: Public observation
Source: module_finding
Reliability: Medium
What this supports: Describe the observed public artefact
What this does not prove: A visible dependency does not prove data location, actual contractual jurisdiction, or hidden subcontractors.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

Directive (EU) 2022/2555 - supply-chain risk context Context only, scope must be established separately
Regulation (EU) 2022/2554 - DORA ICT third-party risk context for entities in scope

View raw data

{
    "evidence": [
        "david.ns.cloudflare.com",
        "thea.ns.cloudflare.com"
    ],
    "severity": "medium"
}

Rule 2026.09.4 · 2026-09-04T19:29:06+00:00

#27 DNS public records

Evidence: dns_address

DNS shows how a domain resolves and which public services are associated with it.

Passive High

Why it matters

Consistent, verifiable resolution reduces some spoofing risks and helps explain entity dependencies.

What to check next

Compare NS, A/AAAA, MX, CAA and the DNSSEC chain with previous measurements to identify delegation or operator changes.

Possible action

If a change is unexpected, verify registrar and DNS-provider configuration before modifying anything. Document the failover mechanisms that actually exist.

Observation: 2606:4700:3035::ac43:8399
Understand: Standard DNS resolution and record parsing
Source: DNS public records
Reliability: High
What this supports: Describe public DNS data observed at scan time
What this does not prove: Public DNS does not prove physical server location, contracts, or global availability.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

DNSSEC introduction and requirements RFC 4033
DNSSEC resource records RFC 4034
DNSSEC protocol modifications RFC 4035
Certification Authority Authorization RFC 8659
Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

Verify it yourself

This command reproduces the public observation without changing the target.

dig A itylos.com && dig AAAA itylos.com

View raw data

2606:4700:3035::ac43:8399

Rule 2026.09.4 · 2026-09-04T19:29:06+00:00

#28 Public TLS endpoint

Evidence: tls_issuer

TLS protects the observed connection between the scanner and the public service.

Active non-intrusive High

Why it matters

These elements document public-channel protection and the cryptographic mechanisms actually negotiated.

What to check next

Compare negotiated protocol, issuer, expiry, chain and cryptographic parameters with history. Check other public entry points separately.

Possible action

Address only observed gaps such as an expiring certificate, invalid chain, or unwanted protocol. Test changes in a controlled environment before deployment.

Observation: C = US, O = Let's Encrypt, CN = YE2
Understand: TLS handshake and public certificate inspection
Source: Public TLS endpoint
Reliability: High
What this supports: Describe the TLS session and certificate presented to Scanapse
What this does not prove: Strong TLS does not prove application security or origin-server security behind a CDN or reverse proxy.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

TLS 1.3 RFC 8446
Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

Verify it yourself

This command reproduces the public observation without changing the target.

openssl s_client -connect itylos.com:443 -servername itylos.com </dev/null

View raw data

C = US, O = Let's Encrypt, CN = YE2

Rule 2026.09.4 · 2026-09-04T19:29:06+00:00

#29 DNS public records

Evidence: module_finding

DNS shows how a domain resolves and which public services are associated with it.

Passive High

Why it matters

Consistent, verifiable resolution reduces some spoofing risks and helps explain entity dependencies.

What to check next

Compare NS, A/AAAA, MX, CAA and the DNSSEC chain with previous measurements to identify delegation or operator changes.

Possible action

If a change is unexpected, verify registrar and DNS-provider configuration before modifying anything. Document the failover mechanisms that actually exist.

Observation: { "evidence": null, "severity": "low" }
Understand: Standard DNS resolution and record parsing
Source: DNS public records
Reliability: High
What this supports: Describe public DNS data observed at scan time
What this does not prove: Public DNS does not prove physical server location, contracts, or global availability.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

DNSSEC introduction and requirements RFC 4033
DNSSEC resource records RFC 4034
DNSSEC protocol modifications RFC 4035
Certification Authority Authorization RFC 8659
Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

View raw data

{
    "evidence": null,
    "severity": "low"
}

Rule 2026.09.4 · 2026-09-04T19:29:06+00:00

#30 DNS public records

Evidence: module_finding

DNS shows how a domain resolves and which public services are associated with it.

Passive High

Why it matters

Consistent, verifiable resolution reduces some spoofing risks and helps explain entity dependencies.

What to check next

Compare NS, A/AAAA, MX, CAA and the DNSSEC chain with previous measurements to identify delegation or operator changes.

Possible action

If a change is unexpected, verify registrar and DNS-provider configuration before modifying anything. Document the failover mechanisms that actually exist.

Observation: { "evidence": [ "david.ns.cloudflare.com", "thea.ns.cloudflare.com" ], "severity": "low" }
Understand: Standard DNS resolution and record parsing
Source: DNS public records
Reliability: High
What this supports: Describe public DNS data observed at scan time
What this does not prove: Public DNS does not prove physical server location, contracts, or global availability.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

DNSSEC introduction and requirements RFC 4033
DNSSEC resource records RFC 4034
DNSSEC protocol modifications RFC 4035
Certification Authority Authorization RFC 8659
Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

View raw data

{
    "evidence": [
        "david.ns.cloudflare.com",
        "thea.ns.cloudflare.com"
    ],
    "severity": "low"
}

Rule 2026.09.4 · 2026-09-04T19:29:06+00:00

#31 Public HTTP response

Evidence: http_header

HTTP headers can ask the browser to enforce specific protections.

Active non-intrusive High

Why it matters

They are visible, verifiable browser-side defensive layers.

What to check next

Read each full policy, identify permissive or contradictory directives, and compare responses across the main public routes.

Possible action

Harden policies progressively from actual application needs. Avoid copying generic templates without functional testing.

Observation: [ "same-origin" ]
Understand: HTTP response-header inspection
Source: Public HTTP response
Reliability: High
What this supports: Describe defensive policies declared on the observed response
What this does not prove: A header being present does not prove it is optimal or that the application has no vulnerabilities.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

View raw data

[
    "same-origin"
]

Rule 2026.09.4 · 2026-09-04T19:29:06+00:00

#32 Mail-related public records

Evidence: module_finding

Public mail policies show how the domain frames sending, authentication and email transport.

Active non-intrusive High

Why it matters

These mechanisms can reduce domain spoofing and document mail-transport posture.

What to check next

Relate SPF, DKIM when a selector is known, DMARC, MX, MTA-STS and TLS-RPT. Compare policy changes over time.

Possible action

Before strengthening a policy, inventory legitimate mail flows and verify alignment. Roll out changes progressively to avoid blocking authorized senders.

Observation: { "evidence": null, "severity": "low" }
Understand: Public DNS and policy endpoint inspection
Source: Mail-related public records
Reliability: High
What this supports: Describe published mail authentication and transport policies
What this does not prove: They do not prove actual deliverability, every recipient’s behavior, or the absence of phishing.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

Sender Policy Framework RFC 7208
Domain-based Message Authentication, Reporting, and Conformance RFC 7489
SMTP TLS Reporting RFC 8460
SMTP MTA Strict Transport Security RFC 8461

View raw data

{
    "evidence": null,
    "severity": "low"
}

Rule 2026.09.4 · 2026-09-04T19:29:06+00:00

#33 module_finding

Evidence: module_finding

Scanapse shows visible providers and third-party services on which the public service depends.

Passive Medium

Why it matters

Concentration on one actor or many third parties can affect continuity and governance.

What to check next

Identify each provider role, functions concentrated on the same actor, and dependencies that appeared or disappeared since the previous scan.

Possible action

For a critical dependency, document owner, contract, reversibility, failover and rationale. Diversify only after analysing the actual need.

Observation: { "evidence": [ "Cloudflare" ], "severity": "high" }
Understand: Public observation
Source: module_finding
Reliability: Medium
What this supports: Describe the observed public artefact
What this does not prove: A visible dependency does not prove data location, actual contractual jurisdiction, or hidden subcontractors.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

Directive (EU) 2022/2555 - supply-chain risk context Context only, scope must be established separately
Regulation (EU) 2022/2554 - DORA ICT third-party risk context for entities in scope

View raw data

{
    "evidence": [
        "Cloudflare"
    ],
    "severity": "high"
}

Rule 2026.09.4 · 2026-09-04T19:29:06+00:00

#34 DNS public records

Evidence: dns_address

DNS shows how a domain resolves and which public services are associated with it.

Passive High

Why it matters

Consistent, verifiable resolution reduces some spoofing risks and helps explain entity dependencies.

What to check next

Compare NS, A/AAAA, MX, CAA and the DNSSEC chain with previous measurements to identify delegation or operator changes.

Possible action

If a change is unexpected, verify registrar and DNS-provider configuration before modifying anything. Document the failover mechanisms that actually exist.

Observation: 104.21.4.32
Understand: Standard DNS resolution and record parsing
Source: DNS public records
Reliability: High
What this supports: Describe public DNS data observed at scan time
What this does not prove: Public DNS does not prove physical server location, contracts, or global availability.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

DNSSEC introduction and requirements RFC 4033
DNSSEC resource records RFC 4034
DNSSEC protocol modifications RFC 4035
Certification Authority Authorization RFC 8659
Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

Verify it yourself

This command reproduces the public observation without changing the target.

dig A itylos.com && dig AAAA itylos.com

View raw data

104.21.4.32

Rule 2026.09.4 · 2026-09-04T19:29:06+00:00

#35 DNS public records

Evidence: spf_record

DNS shows how a domain resolves and which public services are associated with it.

Passive High

Why it matters

Consistent, verifiable resolution reduces some spoofing risks and helps explain entity dependencies.

What to check next

Compare NS, A/AAAA, MX, CAA and the DNSSEC chain with previous measurements to identify delegation or operator changes.

Possible action

If a change is unexpected, verify registrar and DNS-provider configuration before modifying anything. Document the failover mechanisms that actually exist.

Observation: v=spf1 include:_spf.mx.cloudflare.net ~all
Understand: Standard DNS resolution and record parsing
Source: DNS public records
Reliability: High
What this supports: Describe public DNS data observed at scan time
What this does not prove: Public DNS does not prove physical server location, contracts, or global availability.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

DNSSEC introduction and requirements RFC 4033
DNSSEC resource records RFC 4034
DNSSEC protocol modifications RFC 4035
Certification Authority Authorization RFC 8659
Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

View raw data

v=spf1 include:_spf.mx.cloudflare.net ~all

Rule 2026.09.4 · 2026-09-04T19:29:06+00:00

#36 DNS public records

Evidence: dmarc_record

DNS shows how a domain resolves and which public services are associated with it.

Passive High

Why it matters

Consistent, verifiable resolution reduces some spoofing risks and helps explain entity dependencies.

What to check next

Compare NS, A/AAAA, MX, CAA and the DNSSEC chain with previous measurements to identify delegation or operator changes.

Possible action

If a change is unexpected, verify registrar and DNS-provider configuration before modifying anything. Document the failover mechanisms that actually exist.

Observation: v=DMARC1; p=reject; rua=mailto:8870125b546740519c318961703dc7fd@dmarc-reports.cloudflare.net;
Understand: Standard DNS resolution and record parsing
Source: DNS public records
Reliability: High
What this supports: Describe public DNS data observed at scan time
What this does not prove: Public DNS does not prove physical server location, contracts, or global availability.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

DNSSEC introduction and requirements RFC 4033
DNSSEC resource records RFC 4034
DNSSEC protocol modifications RFC 4035
Certification Authority Authorization RFC 8659
Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

View raw data

v=DMARC1; p=reject; rua=mailto:8870125b546740519c318961703dc7fd@dmarc-reports.cloudflare.net;

Rule 2026.09.4 · 2026-09-04T19:29:06+00:00

#37 Public HTTP response

Evidence: http_header

HTTP headers can ask the browser to enforce specific protections.

Active non-intrusive High

Why it matters

They are visible, verifiable browser-side defensive layers.

What to check next

Read each full policy, identify permissive or contradictory directives, and compare responses across the main public routes.

Possible action

Harden policies progressively from actual application needs. Avoid copying generic templates without functional testing.

Observation: [ "cloudflare" ]
Understand: HTTP response-header inspection
Source: Public HTTP response
Reliability: High
What this supports: Describe defensive policies declared on the observed response
What this does not prove: A header being present does not prove it is optimal or that the application has no vulnerabilities.

Standards and reference context

Regulatory references are contextual only. Scanapse does not determine whether a framework applies to the organization and does not issue an automatic compliance verdict.

Directive (EU) 2022/2555 - NIS2 Risk-management context only
Regulation (EU) 2024/2847 - Cyber Resilience Act Product cybersecurity context only

View raw data

[
    "cloudflare"
]

Rule 2026.09.4 · 2026-09-04T19:29:06+00:00

Show technical details

{
    "schema_version": "2.0",
    "engine_version": "2.6.0.1",
    "pattern_version": "2026.09.4",
    "scope": {
        "mode": "passive",
        "coverage": "full",
        "access_level": "full",
        "access_reason": "public_document_available",
        "requests": 2,
        "homepage_only": true,
        "javascript_executed": false,
        "ports_scanned": false,
        "private_networks_blocked": true,
        "protection_bypassed": false,
        "max_body_bytes": 1572864,
        "scan_budget_seconds": 24,
        "budget_exhausted": false,
        "transport": "curl_with_socket_fallback"
    },
    "entity": {
        "id": "8f8b65cf22bd4f60655cdba1957a5f134123dc9373e86803f2a45668ef0948f2",
        "display_name": "itylos.com",
        "slug": "itylos-com",
        "entity_type": "domain_subject",
        "auto_created": true,
        "primary_asset": "itylos.com"
    },
    "methodology": {
        "version": "2.3.1",
        "model": "evidence_first",
        "principles": [
            "absence_of_evidence_is_not_evidence_of_absence",
            "unknown_remains_unknown",
            "provider_metadata_is_not_data_location",
            "edge_provider_is_not_origin_host",
            "single_snapshot_does_not_prove_resilience"
        ]
    },
    "trajectory_summary": {
        "has_previous_scan": false,
        "change_counts": [],
        "observation_count": 37,
        "evidence_count": 37,
        "provider_count": 1,
        "strategic_signal_count": 1,
        "top_signal_count": 1
    }
}