WebInspect Tools FAQ

Yes. The tools listed in the WebInspect Tools section are available free of charge and do not require you to create an account.

Some tools offer optional notifications or additional functionality, but you can use the core tools directly from your browser.

Browse All WebInspect Tools

WebInspect currently provides tools covering DNS, domain information, website security and payment security monitoring.

Available tools include DNS Zone Recovery, DNS Propagation Checker, DNS Zone Transfer Test, WHOIS / RDAP Lookup, security.txt Checker, Email Security Checker, Payment Processor Watcher, Payment Page Monitor, SRI Checker and Payment Script Inventory.

Browse All WebInspect Tools

The individual tools are designed for specific tasks. For example, you might use the DNS Propagation Checker after changing a DNS record, the WHOIS / RDAP tool to investigate a domain, or the security.txt Checker to validate your vulnerability disclosure information.

The WebInspect Website Security Inspection is broader. It examines multiple externally visible security controls together, including SSL/TLS, HTTPS, HTTP security headers, DNS and email security configuration.

Run a Free Website Security Inspection

You should only perform security testing against systems you own or are authorized to test.

Some WebInspect tools simply query publicly available information, while others perform specific security related checks against a domain or website.

Use of the tools is subject to the WebInspect Terms of Use.

WebInspect processes the information necessary to perform the requested tool operation. Data handling, logging and retention are governed by the WebInspect Privacy Policy.

For details about how information is handled, please review our Privacy Policy and Terms of Use.

The DNS Zone Recovery tool queries publicly available DNS records for a domain and reconstructs them into an RFC 1035 compatible DNS zone file.

It can discover records including A, AAAA, CNAME, MX, TXT, NS, SOA and CAA records.

This can be useful if you are migrating to another DNS provider, have lost your original zone configuration, or want to create a snapshot of your current public DNS records before making changes.

Open the DNS Zone Recovery Tool

No. The tool can only discover DNS records that are publicly accessible through DNS queries. Private DNS records, split horizon DNS information and DNSSEC signing material cannot be reconstructed from public DNS.

The generated zone should therefore be reviewed before being used for a migration or imported into another DNS provider.

Yes. The DNS Zone Recovery tool can reconstruct your existing records and can also prepare the NS records for a new DNS provider.

This can make it easier to build the new zone before changing your domain's authoritative nameservers. You should still review the generated zone carefully before making a production DNS change.

The DNS Propagation Checker queries multiple major public DNS resolvers and compares the answers they return for your domain.

It can help determine whether a recent DNS change has begun reaching resolvers around the Internet. Supported record types include A, AAAA, CNAME, MX, NS, TXT and SOA.

Check DNS Propagation

There is no single propagation time that applies to every DNS change.

DNS resolvers cache records according to their TTL (Time to Live). A resolver may continue returning the previous value until that cached record expires and a new answer is retrieved from the authoritative nameserver.

This is why some resolvers may show your new record while others temporarily continue showing the previous value.

The DNS Zone Transfer Test checks whether a domain's authoritative nameservers accept an AXFR zone transfer request.

AXFR is legitimately used to replicate DNS zones between authorized DNS servers. However, an incorrectly configured nameserver may allow arbitrary Internet users to retrieve the complete DNS zone, exposing hostnames, IP addresses, mail infrastructure and other information useful for mapping an organization's network.

Test DNS Zone Transfer

Public zone transfers should normally be restricted.

If AXFR is required between primary and secondary DNS servers, transfers should be limited to specifically authorized systems rather than being available to arbitrary Internet clients.

A failed AXFR request from the WebInspect test is therefore normally the expected result for a properly restricted public nameserver.

A security.txt file provides a standardized way for an organization to tell security researchers how to report a vulnerability.

The format is defined by RFC 9116 and is normally published at /.well-known/security.txt.

A valid file includes contact and expiration information and can optionally provide information such as a vulnerability disclosure policy, encryption key, preferred languages and acknowledgments.

Check Your security.txt File

Not every website is required to publish one, but it can be a useful security practice.

Providing a clear vulnerability reporting contact makes it easier for researchers who discover a legitimate security problem to notify the appropriate person rather than searching for a contact address or abandoning the report.

WHOIS is the traditional protocol used to retrieve domain registration information.

RDAP (Registration Data Access Protocol) is its modern, structured successor and provides registration information in a more standardized format.

WebInspect queries RDAP first and automatically falls back to legacy WHOIS when necessary. Depending on the registry and information available, results may include the registrar, registration and expiration dates, nameservers, DNSSEC status and domain status codes.

Open the WHOIS / RDAP Lookup

Domain registration information depends on what the relevant registry or registrar makes publicly available.

Privacy protections and registration data policies may prevent information about the registrant from being displayed publicly.

WebInspect cannot retrieve registration information that the registry or registrar does not expose through RDAP or WHOIS.

The Email Security Checker inspects SPF, DMARC and DKIM for any domain and reports on each in a single view.

For SPF it resolves the full include chain recursively and counts every DNS lookup against the 10-lookup limit defined in RFC 7208. For DMARC it parses the policy record and surfaces issues with the policy strength, alignment settings and reporting configuration. For DKIM it queries a set of common selector names and reports any that are active or revoked.

Open the Email Security Checker

SPF (Sender Policy Framework) is a DNS record that lists the mail servers and services authorized to send email for a domain. Receiving mail servers check the SPF record to help determine whether an incoming message is from an authorized source.

RFC 7208 limits SPF evaluation to 10 DNS lookups. The mechanisms that consume lookups are include, a, mx, ptr, exists and redirect. Each include causes one lookup for itself, and any mechanisms inside the included record also count against the same total.

When a domain's SPF record requires more than 10 lookups to evaluate, the result is a PermError. Many receiving servers treat a PermError as an SPF failure, which means legitimate email may be rejected or sent to spam even though the sending server is genuinely authorized.

The lookup count is recursive. An include: in your SPF record causes one lookup, but the included record may itself contain further includes, each of which also counts toward your total.

Email service providers such as Google Workspace, Microsoft 365, Mailchimp, Salesforce and Sendgrid each publish their own SPF records with multiple includes inside them. Adding several of these providers to your SPF record can quickly push the total past 10 even when your own record appears short.

The lookup tree in the Email Security Checker shows each numbered lookup and which included domain it came from, so you can identify which provider is consuming the most of your budget.

DMARC (Domain-based Message Authentication, Reporting and Conformance) is a DNS record that tells receiving mail servers what to do with messages that fail SPF or DKIM checks and how to report the results back to you.

The three policy options are none (monitoring only, no action taken), quarantine (treat failing messages as suspicious) and reject (refuse to accept failing messages). A domain that publishes p=reject and has properly configured SPF and DKIM is significantly harder for attackers to impersonate in email.

DMARC also requires alignment: the domain in the From header must align with the domain that passed SPF or DKIM. This alignment requirement is what makes DMARC effective against direct domain impersonation.

DKIM (DomainKeys Identified Mail) allows outgoing email to be cryptographically signed. The sending mail server attaches a signature to the message headers. The receiving server retrieves the corresponding public key from DNS and verifies the signature.

A valid DKIM signature confirms that the signed portions of the message were not modified in transit and that the signature was created by a server with access to the private key for that domain.

DKIM public keys are published as DNS TXT records under a selector name chosen by the domain owner. Because the selector name is not publicly listed anywhere, the WebInspect tool checks a set of commonly used selector names rather than being able to discover all selectors definitively.

Not necessarily. DKIM selector names are chosen by the domain owner or email provider and are not published in a discoverable location in DNS. The WebInspect checker tests a set of common selector names used by popular email providers and configurations.

If your domain uses DKIM with a non-standard or provider-specific selector name that is not in the checked set, the tool will not find it. Your email provider's documentation or control panel will show you which selector name is in use.

WebInspect PCI Tools are focused on payment related security monitoring that may be relevant to PCI DSS v4 activities.

The tools are designed to monitor publicly observable information from outside your environment. They complement internal security controls and compliance processes but do not provide PCI DSS certification or replace a formal compliance assessment.

Explore PCI Security Tools

The Payment Processor Watcher monitors selected third-party payment processor scripts for unexpected changes.

WebInspect calculates SHA-256 hashes of monitored scripts and checks them daily. A public change history makes detected changes visible, and users can subscribe to browser or email notifications.

The tool currently monitors scripts from payment providers including Stripe, Authorize.Net, PayPal, Square, Checkout.com, Worldpay, Mollie, Klarna, Cybersource and Amazon Pay.

This monitoring can support activities relevant to PCI DSS requirement 6.4.3.

Open the Payment Processor Watcher

The Payment Page Monitor checks a checkout or payment page for externally visible security controls and content, including HTTPS enforcement, HTTP security headers, external scripts and mixed content issues.

It also generates a SHA-256 fingerprint of the page, which can be used to help identify unexpected changes between checks. The tool is designed to support payment page monitoring activities relevant to PCI DSS requirement 11.6.1.

Open the Payment Page Monitor

No. The Payment Page Monitor is a supporting security tool and does not certify PCI DSS compliance.

It can help identify and monitor externally visible payment page characteristics relevant to PCI DSS, but compliance depends on your complete environment, applicable requirements, processes and controls.

The SRI Checker scans a webpage for externally loaded JavaScript and stylesheet resources and identifies those that do not use Subresource Integrity (SRI). It can generate SHA-256 and SHA-384 integrity hashes that can be added directly to your HTML.

SRI helps browsers verify that externally hosted resources have not been unexpectedly modified before they are loaded. This can be particularly useful for third-party scripts used on payment pages and can support activities related to PCI DSS requirement 6.4.3.

Open the SRI Checker

No. The SRI Checker does not modify your website. It identifies applicable external resources and generates integrity values for you to review and implement in your HTML.

Before implementing SRI, make sure the external resource is suitable for integrity checking. Resources that are intentionally changed by their provider may require the integrity hash to be updated whenever their content changes.

The Payment Script Inventory scans any checkout page and produces a structured list of all externally loaded scripts and stylesheets. It automatically identifies known payment processor domains, checks Subresource Integrity status and generates SHA-256 and SHA-384 hashes for each resource.

Each inventory gets a permanent URL. The Owner, Justification and Approved columns can be filled in and saved directly in the browser, and the completed inventory can be exported as a CSV for your compliance records. Supporting activities relevant to PCI DSS requirement 6.4.3 where applicable.

Open the Payment Script Inventory

No. The tool only reads the publicly visible HTML source of the page you provide. It does not modify your website, install anything or interact with your server beyond a standard HTTP request.

The Owner, Justification and Approved fields are stored in the inventory record on WebInspect, not on your website.

No.

WebInspect PCI Tools support monitoring and security activities that may be relevant to PCI DSS requirements. They do not certify PCI DSS compliance, replace a Qualified Security Assessor (QSA), or constitute an Approved Scanning Vendor (ASV) scan.

The PCI DSS requirements applicable to an organization depend on its payment environment, architecture and compliance scope.

Learn About PCI DSS Security Readiness