Decide what the connection is supposed to accomplish
A DNS integration should start with a narrow service outcome, not a request for the customer's broadest credential. Reading selected records for an assessment, proposing a correction, and applying an approved change are different jobs. Write down which job is required, which customer authorizes it, and which records are relevant. A convenience claim such as “automatic setup” does not explain the authority being delegated.
This is a proposed evaluation process, not a demonstration of an EmailAuth integration. No account, token, API endpoint or customer domain was accessed. Public provider documentation was reviewed on 8 November 2026; actual endpoint compatibility, tenant controls and implementation remain unverified. Keep integration approval separate from credential creation and any subsequent DNS change approval.
Locate the actual authority and data boundary
Identify the domain, the authoritative DNS provider, the specific zone and any delegated child zones. The registrar's account is not necessarily where the active records live. A provider account may also contain a similarly named inactive zone or a private zone serving a different audience. Establish the intended authority before deciding what the integration needs to read. RFC 1034 supplies the underlying distinction between authoritative zones and cached resolution.
Describe the information leaving that boundary. A record-list response may include administrative comments or tags that public DNS does not expose. Customer identifiers, zone inventories and timestamps can also reveal business relationships when combined. Review the destination, retention, support access and deletion process. Permission to inspect public records does not automatically authorize copying an entire provider account into another service.
Translate capabilities into an explicit permission matrix
For each required operation, record the documented endpoint, permission, resource selector and expected output. Add a column for prohibited operations. A read-only assessment should have no create, update or delete capability, and should not require access to unrelated zones merely because a template selects them by default. Reject unexplained permissions rather than assuming the integration will avoid using them.
Cloudflare's current permission reference distinguishes DNS Read from DNS Write. Its token guide describes zone-specific resource scope, optional expiry and client-IP restrictions. The DNS-list endpoint accepts DNS Read or DNS Write, so the fact that a write-enabled token can list records is not a reason to grant write access. These are Cloudflare examples, not claims about every provider's granularity. Permissions and token scope should be evaluated alongside the exact endpoint.
Amazon Route 53 offers conditions for permitted record names, record types and change actions. Those controls are useful to evaluate if a later write workflow is justified; they must not be assumed to constrain every read endpoint in the same way. Check the action and resource semantics rather than translating another vendor's permission label literally. Route 53 condition guidance is the product-specific reference.
Inspect enforcement rather than marketing labels
Ask how the integration binds a customer to a zone identifier and prevents one customer's request from selecting another customer's resource. Check that authorization is enforced at the service boundary, not merely by hiding a dashboard option. Review what happens when access expires, a resource disappears, or a permission is denied. The correct response is an incomplete or blocked assessment, not silent privilege expansion.
OWASP's authorization guidance recommends least privilege, default denial and checking permissions on each request. Apply those principles to an integration-specific review: document which control enforces each restriction and what independent evidence would show it works. A settings screenshot is useful context but does not establish that a forbidden operation cannot execute. OWASP Authorization Cheat Sheet.
Plan credential ownership and withdrawal
Name the person accountable for approving persistent access, the service responsible for holding a secret, and the operator who can withdraw it. Record a nonsecret credential reference, not the credential value, in the review packet. Require a supported secure handoff and explicit approval before provisioning or configuring access. Avoid secret-bearing screenshots, command histories, issue attachments and copied HTTP headers.
Evaluate expiry, rotation, revocation and incident handling without performing them during this review. A disconnected dashboard does not necessarily mean the provider credential has been revoked. Conversely, revoking a shared credential could interrupt unrelated work. Inventory dependencies before selecting a withdrawal method and define how the owner will verify that access has ended. This lifecycle is an approval condition, not an instruction to change account security now.
Separate connection health from DNS truth
A successful authorization check establishes only what that check actually tested. Listing a record is also not proof that public authoritative servers are serving it. Route 53 explicitly documents that its list operation can return pending records not yet present on all of its DNS servers. Even after authoritative publication, recursive observations can differ because of caching. Route 53 list behavior.
In a fictional review, an integration requests write access to every customer zone for a daily TXT inventory. The reviewer asks for the documented read operation and a single-zone scope, then leaves approval pending until the vendor explains the mismatch. Nothing is connected, and the absence of a connection is not a failed customer service. It is a useful decision made before unnecessary authority is granted.
Close with an evidence-backed decision
Record approve, reject or return-for-clarification, including unresolved data handling, permission and ownership questions. Approval should name the precise access scope and review trigger, such as a new endpoint or expanded resource selection. It should not become a standing permission for arbitrary DNS changes.
The catalogue's original-evidence requirement remains open: Timestamped authoritative and recursive answers with the exact owner name and record type. This documentary permission review cannot supply those observations. Technical SME review, security and privacy acceptance, tenant verification, operational evidence and publication approval are still required.