Verify ownership
before any scan runs
Every external, authenticated, and continuous scan in SecPortal targets a verified domain. Three verification methods (DNS TXT, HTML meta tag, and .well-known file) prove the user owns or is authorised to test the target before scanner traffic ever reaches it.
No credit card required. Free plan available forever.
Three verification methods, one authorisation gate
Vulnerability scanning is a privileged action. Sending unsolicited scanner traffic at a domain you do not own is, at best, noisy and unprofessional and, at worst, a violation of the Computer Fraud and Abuse Act, the UK Computer Misuse Act, or equivalent statutes in other jurisdictions. SecPortal solves this by requiring proof of ownership for every domain a workspace wants to scan, before a single packet leaves the platform.
The verification step is intentionally lightweight. You add the target, place a token using one of three accepted methods, and SecPortal checks it within seconds. Once verified, the domain is unlocked for external scanning, authenticated scanning, attack surface discovery, and continuous monitoring. Anything not verified is silently blocked.
How each verification method works
DNS TXT record
Add a TXT record at the apex of the domain with a workspace-scoped token. Best for organisations that already manage DNS through Cloudflare, Route 53, GoDaddy, or any standard registrar. Propagation usually completes in a few minutes.
HTML meta tag
Drop a single meta tag into the homepage <head>. SecPortal fetches the homepage, parses the markup, and confirms the token. Best when DNS access is restricted but the web team can ship a marketing-site change.
File upload (.well-known)
Upload a verification file under /.well-known/ on the target host. SecPortal fetches it over HTTPS and confirms the token contents. Useful when the asset is a standalone application without an existing CMS or marketing site.
Why ownership verification matters
Pentest delivery and consulting teams operate under signed statements of work and rules of engagement that name the in-scope assets. Domain verification is the technical control that enforces those documents inside the platform, so a scope drift on the scanner side is impossible without a corresponding ownership proof.
- Confirms the user owns or is authorised to test the target before any scan traffic is generated
- Prevents accidental scanning of third-party assets that share infrastructure or look-alike domains
- Creates a defensible audit trail tying every scan to a verified domain and the user who verified it
- Aligns with CREST, PTES, and rules-of-engagement guidance that require documented scope and authorisation
- Lets abuse handlers confirm scan provenance through the SecPortal-Verifier User-Agent and the scanner info page
The verification lifecycle
From added domain to first scan, the full path is four steps. Most users finish it in under two minutes when they hold DNS access for the target.
Add the domain
Open Settings, choose Verified Domains, and enter the bare hostname. SecPortal mints a workspace-scoped verification token and shows tailored instructions for each method.
Pick a method and place the token
Choose DNS TXT, meta tag, or file upload. Copy the exact value from the instructions panel and place it on the target. The token is unique to the domain and the workspace.
Run verification
Click Verify Now. SecPortal performs a DNS lookup, an HTTPS GET against the homepage, or a fetch against the .well-known file, depending on the method you picked, and reports a precise pass or fail reason.
Scan with confidence
Once verified, the domain is available as a target across external scans, authenticated scans, attack surface discovery, scheduled monitoring, and engagement workflows. Unverified targets are rejected at the API layer.
Built-in guardrails against abuse
Verification is one half of responsible scanning; the other half is making the gate impossible to slip past. SecPortal applies the same verified-domain check to every scanner type and exposes a public scanner info page that abuse handlers can use to identify and block traffic if needed.
- Verification tokens are workspace-scoped: a token verified in one workspace does not authorise scanning in another
- Re-verification is required if a domain is removed and re-added, so transferred ownership cannot inherit prior authorisation
- Domains are checked against a static blocklist that excludes critical infrastructure and reserved address space
- External, authenticated, code, and scheduled scans all read the same verified-domain table, so the gate cannot be bypassed by switching scanner type
- All scanner traffic carries a SecPortal-Scanner User-Agent that points back to the public scanner info page for abuse handlers
Where domain verification fits in your security workflow
Domain verification is the first thing a new SecPortal workspace does and the last thing scanner traffic checks before leaving the platform. If you run a programme of recurring vulnerability assessments or operate under a methodology like CREST penetration testing, verification is what lets you point at any in-scope asset and say with certainty: that target is authorised, by this workspace, on this date, by this user. For a deeper look at why this gate matters and how it compares to other authorisation patterns, see the long-form post on domain verification and responsible scanning.
Related use cases
Scan only what you own
Verify your first domain in under two minutes and unlock the full scanning toolkit.
No credit card required. Free plan available forever.