Security work without approval is legally and ethically risky. Leaders also need a simple, checkable proof that the domain belongs to the client. DNS-TXT is the pragmatic gate before passive analysis.
DNS-TXT verification — authorisation before every security analysis.
Without verifiable domain authorisation, SHELL-AFFECT does not start CASP. DNS-TXT verification ensures only owned or written-approved domains are viewed outside-in — for trust, scope, and clear responsibility before any passive security analysis begins in a DACH context.
- Gate before work
- Technical proof
- Onboarding in minutes
Example kickoff (anonymised)
Client wants to “scan today”. We send the TXT token, IT sets `_shell-affect-verify` in 20 minutes, we verify, only then CASP starts. A parallel wish to “also do the partner domain” is declined — no approval, no scope. Kickoff stays clean, no grey zone. Figures and names are anonymised; the flow matches typical engagements. Decision criteria stay explicit. No ranking or lead guarantees apply.
DNS-TXT is deliberately simple and strict. Anyone wanting to start without the gate does not get CASP from us — that protects you and us.
This page’s job: Owns the DNS-TXT authorisation gate before CASP only. No report promise and no pentest RoE substitute.
DNS-TXT — typical steps
Simplified onboarding (details in the engagement):
- 01
1. Token
You receive a one-time proof value.
- 02
2. DNS
Set TXT on the primary domain (watch TTL).
- 03
3. Verify
We check resolution and value.
- 04
4. Start
CASP outside-in only after successful verification.
- 05
5. More domains
Full scope: proof per domain.
- 06
6. Remove
After kickoff/policy — defined in onboarding.
Unclear authorisation is a no-go
Anyone commissioning CASP or related outside-in work who wants authorisation documented cleanly.
Not for you if…
- You want third-party domains tested without relationship
- You refuse any authorisation proof
- You expect behind-login testing without a separate scope
DNS-TXT & authorisation: how we differ — and what to watch.
Authorisation is not paperwork friction — it is the difference between serious security and a grey zone. CASP starts only after DNS-TXT. No “later”, no workaround. Gate before work starts.
How we differ on the authorisation gate
Gate before work
Verification before outside-in — not in parallel and not optional.
Technical proof
DNS-TXT proves domain control better than an email from some mailbox.
Protects both sides
No work on third-party or unclear assets — ethically and contractually clean.
Onboarding in minutes, not weeks
Setting TXT is simple; we do not block kickoff with needless bureaucracy.
What to watch in security offers without a clear authorisation model
- Start “immediately” without domain proof or written approval
- Only a T&Cs clause instead of a concrete gate (TXT, token, owner confirmation)
- Willingness to “quickly check” third-party domains
- Unclear asset lists and scope creep from day one
- No documentation of who approved
- Mixing outside-in and active testing without separate approvals
Included vs. deliberately not (DNS-TXT / authorisation)
Typical boundaries at the kickoff gate:
- We do / include
DNS-TXT verification mandatory before CASP
- We do / include
Documented kickoff step linked to scope
- We do / include
Work stops if verification fails
- We do not / exclude
CASP start without successful verification
- We do not / exclude
Testing third-party domains without rightful approval
- We do not / exclude
“Informal” scans as a favour
If you want serious authorisation and then defensible CASP: scope meeting. If you want to start without a gate, we decline — by design.
What you decide, what is authorised, what is out of scope.
Method boundaries first — no mixed CASP/pentest theatre.
What you can decide
Provable authorisation before analysis.
What is authorised
Standard gate, documented, repeatable.
How fast you get clarity
TXT takes minutes — does not block for weeks.
What comes from you
One DNS record and an approval check.
Practical outcomes for you.
Legal clarity
Only authorised assets in scope.
Trust
Client and provider share the same gate.
Clean kickoff
CASP starts only when TXT is valid.
Core offer and clear options.
DNS-TXT gate
Required before CASP start.
CASP after
Passive outside-in profiling.
Documentation
Proof in project context.
More domains
Full scope with multiple TXT proofs.
What the gate provides
- Proof of domain control
- Start approval for CASP
- Clear scope linkage
- Documentable kickoff step
How verification works
- 01
Receive token
One-time proof value for your domain.
- 02
Set TXT
In the primary domain DNS.
- 03
Verify
We check before work starts.
- 04
Release CASP
Outside-in begins only after.
Objections, answered honestly.
Why DNS-TXT and not only email?
TXT proves technical control of the domain — not only mailbox access.
How long must the record stay?
At least through verification and kickoff; details in onboarding.
Does this apply to pentests too?
Pentests need written approval and RoE; CASP uses DNS-TXT as the outside-in gate.
How do I start?
Contact — we send the flow with scope.
Is a WHOIS email enough proof?
For CASP we use DNS-TXT as the technical gate. Additional written approvals may still be required per scope.
What if DNS is managed by an agency?
Then that party must be able to set TXT — or the scope does not start. That is intentional.
Start authorisation and CASP
Share domain and goal — we guide DNS-TXT and scope.