Direct answer
Public TXT records can contain legitimate service verification and email-policy values. Review them against the owner's inventory for unintended secrets or personal information, but do not assume that every token-looking value is a credential or remove records without approval.
Define the review boundary
Start with domains the organization owns or is authorized to assess. Record the queried name, record type, answer and time in restricted evidence storage. DNS is public, but copying sensitive values into broad reports can increase exposure.
Reference: RFC 1034: Domain names: concepts and facilities.
Understand legitimate uses
TXT records may support domain verification, SPF and other services. Ask the responsible owner what each record is for and whether the provider expects it to remain published. A challenge value can be intentionally public and is not automatically an access secret.
Reference: RFC 7208: Sender Policy Framework.
Investigate a suspected secret
If a record appears to contain an actual password, API key or personal data, report it through the incident process without testing the value against a service. The owner can determine sensitivity, rotate or revoke a secret if appropriate, and plan a safe DNS change.
- Minimize the shared evidence and redact the value.
- Identify service dependencies before deletion.
- Record the owner, change reference and retest condition.
Verify after correction
Repeat the same query after an approved change, taking caching into account, and confirm dependent verification and mail functions still work. Record the tested resolver and time; a single clean response does not prove every cached copy has expired.
Assessment limits
A public record review cannot determine the validity of every apparent credential or find secrets outside the queried names. Changes require the DNS and service owners' approval.
Frequently asked questions
Is every public verification token a secret?
No. Many challenges are meant to be public. Check the provider's documentation and the owner's configuration.
Should a suspected key be used to see if it works?
Do not use it without explicit authorization. Report it securely so the owner can assess and rotate it as needed.
Primary sources and further reading
These guides combine published security guidance with practical assessment planning. Adapt checks to the owner's policy, environment, and authorized scope.
This guide was prepared with AI assistance using the linked sources and illustrative examples. Check current vendor guidance and your environment before making changes.