Domains & Verification
Why Domain Verification Exists
Before you can pentest any target, TurboPentest needs proof that you own or are authorized to test the domain. This is not bureaucracy - it is a legal and ethical safeguard. Running penetration tests against infrastructure you do not own is illegal in most jurisdictions. Domain verification ensures that every pentest on the platform is authorized by the domain owner.
Without verification, anyone could point TurboPentest at a competitor's website and launch a full pentest against it. The verification step makes this impossible by requiring you to demonstrate control over the domain's DNS or file system before any testing can begin.
The TLD Verification Hierarchy
TurboPentest uses a top-level domain (TLD) verification model. You verify the root domain once, and all subdomains are automatically covered. For example, verifying example.com automatically authorizes pentesting of api.example.com, app.example.com, staging.example.com, and any other subdomain.
This hierarchy model has several practical benefits. You do not need to re-verify each time you add a new microservice on a subdomain. Your development team can spin up feature-branch.staging.example.com and immediately add it as a pentest target without waiting for a verification cycle. The root domain verification acts as a blanket authorization for your entire domain tree.
However, this also means that only people with access to the root domain's DNS or hosting can authorize testing. A developer who manages api.example.com but does not control example.com DNS cannot independently verify their subdomain. This is intentional - domain verification should be controlled by the organization, not individual teams.
DNS TXT Record Verification
The primary verification method uses DNS TXT records. When you register a domain with TurboPentest, the platform generates a unique verification token. You add this token as a TXT record on your root domain, then trigger the verification check.
Step 1: Register the domain. Navigate to your TurboPentest dashboard and add your root domain (e.g., example.com), or use the API:
curl -X POST https://turbopentest.com/api/tlds \
-H "X-API-Key: $TURBOPENTEST_API_KEY" \
-H "Content-Type: application/json" \
-d '{"domain": "example.com"}'The response includes a verificationToken that you will use in the next step.
Step 2: Add the DNS TXT record. In your DNS provider's control panel, create a TXT record on the root domain (@ or example.com) with the value turbopentest-verify=<your-token>. Set the TTL to 300 seconds (5 minutes) for faster propagation.
Step 3: Trigger verification. After DNS propagation (typically 1-5 minutes), click the "Verify" button on the dashboard or call the verify API endpoint. TurboPentest performs a DNS lookup, finds your TXT record, confirms the token matches, and marks the domain as verified.
Cloud Provider Verification
For assets hosted with a supported cloud provider, you can prove ownership by connecting that provider instead of adding a DNS record. TurboPentest supports two cloud-backed methods:
- OAuth connection. Authorize TurboPentest with your cloud provider (the same connection used to discover assets). Proving you control the account that hosts the asset establishes ownership without touching DNS.
- Cloud discovery. When a provider is connected, TurboPentest enumerates the domains and resources in that account; assets surfaced through discovery are treated as verified because they belong to the connected account.
DNS TXT verification is the primary method and works even when the web server is not yet deployed. The cloud-provider methods are useful when DNS is managed by a separate team or when the asset is a cloud resource rather than a standalone domain.
Verification Expiration and Renewal
Domain verifications are valid for one year from the date of verification. TurboPentest sends reminder emails at 60 days, 30 days, and 7 days before expiration. When a verification expires, all scheduled pentests under that domain are automatically paused until you re-verify.
Re-verification follows the same process - your existing TXT record (or cloud provider connection) may still be in place, so you can often just trigger the check again without making any infrastructure changes. It is good practice to set a calendar reminder alongside the platform's email notifications, especially if your DNS or hosting team is separate from your security team.
Limitations
There are a few constraints to keep in mind. IP addresses cannot be verified - you must use a hostname. The TXT record must be on the root domain, not on a subdomain. And you must register the top-level domain; subdomains cannot be registered independently. These constraints ensure the verification model remains simple, consistent, and enforceable.
Defense-in-Depth: Multi-Layered Scope Protection
Domain verification is the first of several layers that prevent TurboPentest from being used against unauthorized targets:
- Domain Ownership Verification - You must prove you control the domain before any pentest can run (DNS TXT or file-based).
- AI Agent Scope Binding - Paladin's system prompt includes a hard-coded list of your verified domains. The AI rejects findings on any domain not in the authorized list.
- DNS Guard Sidecar - Every tool container runs alongside a DNS guard that only resolves your authorized domains. Even if a tool attempts to reach an unauthorized domain, DNS resolution fails at the network level, returning NXDOMAIN.
- Container Isolation - Each tool runs in its own ephemeral container that is destroyed after the pentest. No tool can access another container's data or network.
This multi-layered approach means that even if one layer were somehow bypassed, the remaining layers would still prevent unauthorized testing. The DNS Guard provides network-level enforcement that does not rely on software configuration or AI compliance.
Understanding domain verification thoroughly is important because every other step in TurboPentest - adding targets, scheduling pentests, and viewing results - depends on having a verified domain as the foundation.