Map the exact authority granted
DNS integrations differ materially. A service may ask for a CNAME at one name, delegation of a subdomain through NS records, or API credentials able to edit a broader zone. Record the exact names, record types, permission scope and people who can revoke access. Do not describe all three arrangements as a harmless pointer. A scoped integration can still affect a critical authentication dependency.
Identify what the service controls and what remains with the domain owner. Ask how records are served during an outage, how changes are audited and how an operator can recover if the supplier is unavailable. These are requirements to verify with current documentation and authorized testing, not assumed features of any provider.
Use a response-code decision tree
Start with whether a response arrived. A timeout leaves the cause unresolved: investigate reachability, resolver behavior and transport before concluding that a record is absent. SERVFAIL can reflect resolution or validation problems; it does not mean no policy. NXDOMAIN means the queried name does not exist in that response context. NOERROR with no relevant answer is a different result and may require further interpretation of the authority data and query chain.
Use five written query outcomes for type TXT at reserved names. These are stipulated response premises, not captured packets or public queries.
- answer.example.test: NOERROR with a relevant TXT answer. Inspect the actual content and chain before any application-level verdict.
- absent.example.test: NXDOMAIN. The response asserts name nonexistence in its context; confirm authority and query chain.
- empty.example.test: NOERROR with no relevant answer. Inspect referrals, CNAME chains and authority information; empty answer alone is not automatically authoritative NODATA.
- failed.example.test: SERVFAIL. Resolve the server or validation problem; do not turn failure into no-policy.
- timeout.example.test: no response. Cause unknown; inspect reachability and resolver behavior rather than asserting nonexistence.
No UDP stub, query transcript, packet parser, DNSSEC validation or availability measurement was executed for this written decision tree.
Plan a reversible exit
Before purchase, document how to export the intended records, recreate equivalent owner-controlled answers, schedule the change and verify it from independent vantage points. Account for caching and observed TTLs without promising that every resolver refreshes at the same moment. Test a controlled sender after changing a DKIM dependency and verify reporting destinations after changing related records.
Do not revoke access before the replacement configuration is ready, and do not leave unwanted authority active indefinitely after migration. Separate changing a record from proving its effect on mail. Keep a dated approved baseline and an explicit rollback owner. RFC 1035 defines DNS response structure and codes; RFC 9989 describes DMARC interpretation. The written cases illustrate response classification only. It does not measure supplier uptime, prove global propagation or justify a real DNS change without the appropriate authorization.
Keep the vendor decision evidence-based
Ask for the exact export format, revocation path, outage behavior and dependency ownership. Name an exit owner and a continuity test covering affected signing and report routes. Supplier answers are assertions until supported by documentation and authorized observations. Compare those findings with business requirements; no local educational example establishes an SLA, global propagation result or current EmailAuth capability.