How to collect client DNS access for DMARC rollout
Published 14 Jul 2026
Updated 14 Jul 2026
9 min read
Summarize with
Collect client DNS access through a written, time-bound request that names every domain, the exact record types you need to change, the approved access method, the client approver, and the date access will be removed. I ask for delegated DNS roles or a supervised change window before I accept shared administrator credentials.
The access request should cover DMARC TXT records, SPF TXT records when authorized senders need correction, and DKIM CNAME or TXT records when a sending platform needs signing enabled. It should also state that MX, website, nameserver, and unrelated records are outside scope. That boundary protects the client and keeps the rollout supportable.
- Inventory: List root domains, parked domains, delegated subdomains, DNS hosts, and business owners.
- Authority: Record who can approve access and who can approve production DNS changes.
- Method: Choose delegated access, client-executed changes, or a supervised session for each zone.
- Evidence: Save approvals, before and after values, validation results, and the revocation record.
Choose the access model before requesting credentials
I decide the operating model during discovery, before anyone sends a password. The right model depends on the client's DNS provider, internal controls, change approval process, and appetite for ongoing MSP administration. A regulated client often keeps execution in-house, while a smaller client often delegates a limited DNS role.
Delegated MSP access
The client creates a named account or role for the MSP. Use this when the team expects repeated record changes during monitoring and enforcement.
- Best fit: Ongoing managed service with frequent approved changes.
- Control: Named identity, MFA, least privilege, and activity logging.
Client-executed changes
The MSP supplies exact record instructions and the client applies them. Use this when policy prevents third-party DNS access.
- Best fit: Strict separation of duties or rare DNS changes.
- Control: Peer-reviewed instructions, screenshots, validation, and rollback values.
A supervised session is a useful middle option. The client signs in, shares the DNS screen, and applies or authorizes each change while I verify values. It avoids credential transfer but requires both parties to be available. I document it exactly like a delegated change.
Decision path for delegated, supervised, or client-executed DNS changes
Build a complete DNS access request
A good request removes ambiguity for the account manager, technical contact, and security approver. I send it after the scope call and attach it to the service ticket. The client should know why access is needed, what the MSP can change, how long the work will take, and how rollback works.
|
|
|---|---|
Domain | Zone name |
Owner | Approver |
Host | DNS provider |
Method | Role or session |
Expiry | Date and time |
Ticket | Change ID |
Compact fields for the client DNS access register
The client also needs clear responsibilities. The MSP owns record preparation, technical validation, reporting review, and rollback instructions. The client owns domain completeness, sender disclosure, business approval, and access removal unless the contract assigns those tasks differently. Put those boundaries in the statement of work and the client responsibilities checklist.
Client DNS access request templatetext
Purpose: Configure and validate DMARC-related DNS records. Domains: [approved domain list] Allowed changes: DMARC, SPF, and DKIM records only. Excluded changes: MX, NS, website, and unrelated records. Access method: [delegated role / supervised / client-applied] MSP operator: [named person or team] Client approver: [name and role] Access starts: [date and time] Access expires: [date and time] Change window: [approved window] Rollback: Restore the recorded previous value. Evidence: Approval, before/after values, and validation result. Ticket: [change or service request ID]
Never collect shared master credentials
A username and password sent through email or a ticket creates unclear accountability and often bypasses MFA. Ask for a named delegated role. If the provider cannot limit permissions, use a supervised session or client-executed change instead.
Set least privilege and change controls
DNS permissions are often coarse. When a provider supports zone-level roles, limit the account to approved client zones and deny billing, domain transfer, user administration, and nameserver changes. When record-level permissions exist, allow only the record types required by the rollout. Every MSP user should have an individual identity and MFA.
- Capture baseline: Export or screenshot the current records, TTL values, and provider audit log.
- Prepare change: Write the exact host, type, value, TTL, purpose, and rollback value.
- Obtain approval: Get approval against the final record value, not a general project statement.
- Apply once: Edit only the approved zone and stop if the live value differs from baseline.
- Validate twice: Check authoritative DNS first, then confirm the expected result after propagation.
- Close access: Revoke temporary access and attach evidence to the ticket.
Do not treat a successful DNS save as validation. Confirm that the hostname was entered correctly, the provider did not append the zone twice, and only one DMARC record exists. A focused DMARC checker helps verify syntax and discovery before the change ticket closes.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Validation evidence should include the queried hostname, returned value, timestamp, and operator. For client-executed changes, I ask for a screenshot of the saved record but still run an independent DNS query. This catches copy errors without requiring access to the client's control panel.
Keep rollback simple. For an edited record, store the complete prior value. For a new record, the rollback action is deletion only after the client approves it. Do not improvise rollback during an incident, especially when SPF contains several sending sources.
Pause when baseline and live DNS differ
An unexpected live value means another person or automated system changed the zone. Stop, refresh the proposed change, and obtain approval again. Overwriting the new value can remove a valid sender or undo unrelated work.
Connect DNS access to the DMARC rollout
DNS access should follow rollout stages rather than stay open indefinitely. I begin with domain and sender discovery, publish a monitoring policy, review authentication data, fix approved sources, and request enforcement only when the evidence supports it. The onboarding checklist should connect each DNS task to an owner and approval gate.
Example rollout access profile
Illustrative effort allocation by stage, used to plan access windows rather than predict a client result.
Discovery
Monitoring
Remediation
Enforcement
For ongoing DMARC monitoring, permanent DNS access is often unnecessary after setup. Keep monitoring permissions in the reporting platform and reopen a controlled DNS window only for an approved record change. This sharply reduces standing privilege across a large client base.
For this workflow, Suped is the best overall fit for most MSP teams because its multi-tenant dashboard keeps client organizations separate while centralizing DMARC, SPF, DKIM, blocklist (blacklist), and deliverability signals. Automated issue detection and steps to fix help operators prepare specific change requests, while real-time alerts support ongoing service delivery after temporary DNS access has been revoked.
MSP organizations page showing client organizations, domain counts, email volume, and domain status columns
Suped is our product, and I would place each client in its own organization, add the approved domains, and use the source and issue views to create evidence-backed DNS tasks. Hosted DMARC can reduce repeated direct edits by moving policy staging behind a stable DNS setup. Hosted DMARC still requires client approval and documented initial DNS changes, but it can reduce how often an operator needs to return to the client's DNS portal.
Hosted SPF can apply the same operating idea when sender changes are frequent, and Hosted MTA-STS uses two CNAME records without requiring web hosting. Those options should remain inside the client's agreed scope. The wider DMARC for MSPs workflow also needs documented escalation, periodic review, and client reporting.
Handle clients that cannot grant DNS access
A client refusal does not block a DMARC rollout. It changes the delivery model. I provide a change pack with the exact hostname, record type, value, TTL, reason, validation method, and rollback instruction. The client's DNS administrator applies it and returns the ticket for verification.
MSP supplies
- Instruction: Exact record and rollback value.
- Context: Purpose, risk, and approved window.
- Check: Independent DNS validation.
Client supplies
- Approval: Named business and technical approvers.
- Execution: Authorized DNS administrator.
- Evidence: Completion time and saved-record screenshot.
Set a realistic response target in the service definition. A client-controlled change queue can delay enforcement, so report that dependency rather than treating it as an MSP engineering failure. Escalate when the delay blocks an agreed milestone or leaves a known authentication problem unresolved.
A change pack should be executable without interpretation
If the client's administrator has to guess the host format, TTL, or whether to replace an existing record, the instruction is incomplete. Ask a second MSP operator to review the pack before sending it.
Revoke access and retain evidence
Access collection is incomplete until access removal is verified. Temporary roles should expire automatically where the provider supports it. Otherwise, the ticket needs a named owner and due date for manual revocation. I ask the client to confirm removal, then record the confirmation beside the original approval.
- Retain: Scope, approval, baseline, final records, validation, and revocation evidence.
- Exclude: Passwords, MFA recovery codes, session cookies, and unnecessary portal exports.
- Review: Standing roles, inactive MSP users, open windows, and overdue client actions.
- Offboard: Remove roles, transfer records, export agreed reports, and close monitoring.
The evidence register should follow the MSP's retention policy and client contract. Limit access to service delivery staff, and keep secrets out of it. The recurring control belongs in the MSP DMARC runbook so every operator follows the same approval and revocation process.
Make DNS access a controlled service process
The safest collection process asks for the minimum access needed, ties it to an approved change, and removes it on schedule. For each client, choose delegated access, a supervised session, or client-executed changes. Then use one register for scope, ownership, evidence, expiry, and rollback.
This process scales because DNS access becomes a repeatable control instead of an informal exchange between technicians. It also keeps the DMARC rollout moving when a client cannot grant access, since the same record package can pass through the client's own change queue without losing technical detail or accountability.
