Executive Summary

Domain & DNS Security

Layer: Internet resolution and authenticity. Checks included: DNSSEC validation, nameserver configuration, IPv6 DNS support for name servers and web servers. Why this matters: DNS is foundational. If DNS is compromised, everything else is irrelevant. Attackers can redirect traffic, intercept communications, or impersonate your domain if DNS security is weak. Responsibility: Domain administrator manages DNS records, DNSSEC keys, and nameserver configuration.

Web Transport Security (HTTPS & TLS)

Layer: Client-to-server encryption. Checks included: HTTPS availability, HTTPS redirect enforcement, TLS version support, cipher configuration, TLS renegotiation security, 0-RTT status, compression settings, HSTS configuration. Why this matters: TLS is one logical system that protects data in transit between browsers and servers. Weak TLS configuration allows attackers to intercept, decrypt, or modify communications. Modern standards require TLS 1.2 or higher with secure cipher suites. Responsibility: Web and infrastructure team configures web server TLS settings, certificate deployment, and HTTPS redirect rules.

Certificate & Trust Policy

Layer: Cryptographic trust and issuance control. Checks included: Certificate validity, trust chain verification, public key validation, signature verification, domain name matching, CAA (Certificate Authority Authorization) records. Why this matters: Certificates and CAA are about who is allowed to issue trust, not transport mechanics. Invalid certificates or missing CAA records allow attackers to obtain fraudulent certificates for your domain, enabling man-in-the-middle attacks. Trust chain validation ensures certificates are issued by legitimate Certificate Authorities. Responsibility: Security and PKI administrators manage certificate lifecycle, CAA DNS records, and trust chain configuration.

HTTP Application Security Headers

Layer: Browser-side attack prevention. Checks included: X-Frame-Options, X-Content-Type-Options, Referrer-Policy, security.txt file presence. Why this matters: Headers mitigate XSS, clickjacking, data leakage. They are not TLS controls but application-level security directives that instruct browsers how to handle your content. Missing headers allow attackers to embed your site in malicious frames, execute XSS attacks, or leak sensitive referrer information. The security.txt file provides a standardized way for security researchers to report vulnerabilities. Responsibility: Web application owner configures HTTP response headers in web server or application framework settings.

Email Authentication & Transport Security

Layer: Identity and message integrity. Checks included: SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), DMARC (Domain-based Message Authentication, Reporting & Conformance), MTA-STS (Mail Transfer Agent Strict Transport Security), TLS-RPT (TLS Reporting). Why this matters: Email is a completely separate attack surface from web security. Without proper authentication, attackers can spoof emails from your domain, leading to phishing attacks, reputation damage, and email delivery failures. SPF defines authorized sending servers, DKIM cryptographically signs messages, DMARC provides policy enforcement, MTA-STS enforces secure email transport, and TLS-RPT provides visibility into email transport security issues. Responsibility: Email and messaging administrators configure DNS records for SPF, DKIM, and DMARC, deploy MTA-STS policies, and monitor TLS-RPT reports.

Layer: Transparency and context. Information included: Hosting provider identification, web and email IP addresses, MX record configuration, platform detection (WordPress), website scanning results (email addresses found, broken links). Why this matters: This section provides context for auditors and IT staff but does not represent security controls. Understanding hosting infrastructure helps assess risk exposure, identify shared hosting concerns, and track platform dependencies. WordPress detection helps identify if version monitoring is required. Website scanning identifies potential information disclosure issues. Responsibility: IT staff and auditors use this information for risk assessment and compliance documentation.

Network & Infrastructure Trust

Layer: Internet routing and reputation. Checks included: RPKI (Resource Public Key Infrastructure) validation for route origin authorization, IP abuse checks against blacklists, domain reputation analysis, PTR record validation. Why this matters: These controls protect against hijacking, spoofing, and reputation-based blocking. RPKI prevents BGP route hijacking by cryptographically validating that IP address blocks are announced by authorized networks. IP abuse checks identify if your IP addresses are on spam or malware blacklists, which can cause email delivery failures and website blocking. Domain reputation affects email deliverability and search engine rankings. Responsibility: ISP and infrastructure providers manage RPKI ROA (Route Origin Authorization) records, IP address allocation, and network routing announcements.