Inspect response headers, redirects and security
DNS & Records
DNS Lookup Every DNS record for any domain A Record Lookup IPv4 addresses for a domain AAAA Record Lookup IPv6 addresses for a domain MX Lookup Mail servers for a domain NS Lookup Authoritative name servers TXT Lookup TXT records, SPF, verification CNAME Lookup Canonical name (alias) records SOA Lookup Start of Authority record SRV Lookup Service location records CAA Lookup Which CAs may issue certificates Reverse DNS (PTR) IP address to hostname DNSSEC Check Is the domain signed and validated? DNS Health Check A full delegation & DNS report cardEmail Deliverability
SPF Check Validate your Sender Policy Framework record DMARC Check Inspect and grade your DMARC policy DKIM Check Find and validate your DKIM public key Blacklist Check Check an IP against email blocklists (DNSBLs) SMTP Test Connect to a mail server and check STARTTLS MTA-STS Check Enforced TLS policy for inbound mail BIMI Check Brand logo record for email TLS-RPT Check SMTP TLS reporting policyNetwork & Web
SSL Certificate Check Inspect a site's TLS certificate and expiry HTTP Header Check Inspect response headers, redirects and security Ping (TCP) Reachability and latency over TCP Port Check Which common ports are openDomain
WHOIS Lookup Registration data for domains, IPs and ASNsHTTP response headers reveal how a web server behaves: the status code it returns, where it redirects, what software it runs and which security hardening headers it sends. Missing headers like HSTS, Content-Security-Policy or X-Frame-Options leave sites exposed to downgrade, injection and clickjacking attacks. IPeek follows the full redirect chain and grades the response against the key security headers.
Every HTTP response starts with a status code and a set of headers before the page body. The status code tells the client what happened: 200 means success, 301 and 302 mean the resource moved, 404 means not found, and 5xx means the server failed. Headers carry metadata such as Content-Type, Server, Cache-Control and the security directives that instruct the browser how to treat the page. IPeek requests the URL, captures these headers exactly as the server sent them, and follows each redirect so you see the full path to the final response.
First confirm the final status code is the one you expect, typically 200 for a live page. Then walk the redirect chain: a clean setup redirects HTTP to HTTPS and any non-canonical host to the canonical one in as few hops as possible, since every extra redirect adds latency. Watch for redirect loops or a chain that lands on the wrong host. The Server header reveals the software in use, and the security-header grade shows at a glance which protective headers are present and which are missing.
Strict-Transport-Security (HSTS) forces browsers to use HTTPS, preventing downgrade attacks. Content-Security-Policy limits where scripts and resources can load from, the strongest defense against cross-site scripting. X-Frame-Options or a CSP frame-ancestors directive blocks clickjacking by controlling who can embed your page. X-Content-Type-Options: nosniff stops MIME sniffing. The most common gap is a site that serves none of these, leaving the browser with no extra protection. Add them at the web server or CDN, then recheck to confirm they appear on the live response.
Check headers after deploying, after changing your CDN or reverse proxy, and whenever you harden a site's security posture, since these are the moments headers get added, dropped or overridden. It is the quickest way to confirm an HTTP-to-HTTPS redirect actually works, to debug an unexpected redirect chain, or to verify that a security header you configured is reaching real browsers rather than being stripped somewhere in the delivery path.
It shows the status code, redirect chain, server software and security headers a site returns. You see whether the URL redirects correctly, how many hops it takes, what server is responding, and which protective headers like HSTS and Content-Security-Policy are present or missing. That makes it a fast diagnostic for both routing problems and security gaps.
HTTP Strict-Transport-Security is a header that tells browsers to only connect over HTTPS for a set period. It matters because it prevents downgrade and man-in-the-middle attacks where an attacker forces an insecure HTTP connection. Once a browser sees HSTS, it refuses plain HTTP to that host until the policy expires, closing a real attack window.
Redirect chains usually stack up when separate rules each fix one thing: HTTP to HTTPS, non-www to www, and trailing-slash normalization. Each hop adds latency and a chance of error. Collapse them into a single redirect to the final canonical URL where possible, and watch for loops where two rules send the request back and forth.
At minimum, send Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options: nosniff, and frame protection via X-Frame-Options or CSP frame-ancestors. HSTS enforces HTTPS, CSP limits script injection, nosniff stops MIME confusion, and frame protection blocks clickjacking. Together they cover the most common browser-side attack classes with directives you set once at the server or CDN.
A 301 is a permanent redirect and a 302 is temporary. A 301 tells browsers and search engines the resource has moved for good, so they update bookmarks and pass ranking signals to the new URL. A 302 says the move is temporary, so clients keep using the original URL. Use 301 for canonical and HTTPS redirects.