Need email infrastructure? Try PostScale -- transactional email API built in the EU. PostScale

    Multi-User Accounts and Zone Access Control

    Learn how to invite team members to your DNScale account, assign roles, and control which DNS zones each user can access.

    What you'll learn

    • Set up multi-user access with appropriate roles for team members, clients, and external partners
    • Configure zone-level access controls to enforce least-privilege DNS management
    • Design RBAC strategies for common scenarios like agencies, dev/staging/prod environments, and IT departments
    • Manage API key permissions and understand how key access inherits from user roles

    DNScale supports multi-user accounts, allowing you to invite team members and control exactly which DNS zones each person can access. This is useful for agencies managing client domains, organisations with multiple departments, or any team where different people need access to different domains.

    How It Works

    Every DNScale account starts with a single admin user. From there, you can invite additional team members and control their access at the zone level. There are two key concepts to understand:

    • Roles determine what a user can do across the account
    • Zone access determines which DNS zones a user can see and modify

    This follows the principle of least privilege: users only get access to the zones and actions they need. An agency developer working on one client's domain shouldn't be able to see or modify another client's DNS, and a junior team member shouldn't be able to change production NS records or SOA records.

    User Roles

    DNScale has two main roles:

    Admin

    Admin users have full, unrestricted access to everything in the account. They can:

    There is always at least one admin on the account. Admin users are not affected by zone access restrictions.

    The first user on every account is automatically an admin. You cannot remove the last admin from an account ā€” at least one admin must exist at all times to prevent lockout.

    User

    Standard users have access only to the DNS zones they have been granted access to. They cannot manage billing, invite other users, or change account settings. Standard users see a filtered view of the dashboard showing only their assigned zones.

    Standard users can:

    • View zones they have been granted access to
    • Manage DNS records in zones with Read & Write access (including A, AAAA, CNAME, MX, TXT, and other record types)
    • Create API keys scoped to their own zone access
    • View their own profile and notification settings

    Standard users cannot:

    • See zones they haven't been granted access to
    • Invite or manage other users
    • Access billing, subscription, or payment settings
    • Delete zones or modify system records

    Zone Access Levels

    When granting a user access to a DNS zone, you choose one of two levels:

    Read Only

    The user can view the zone and its DNS records but cannot make any changes. This is ideal for:

    • Clients who need to verify their DNS configuration
    • Team members who need visibility but shouldn't make edits
    • Auditing and compliance purposes
    • External partners verifying integration DNS records (like TXT verification records)
    • Junior team members learning DNS management

    Read & Write

    The user can view the zone, create new records, update existing records, and delete records. This is suitable for:

    • Team members who actively manage DNS for specific domains
    • Developers who need to update A records or CNAME records for their services
    • Partners managing their own domain configuration
    • DevOps engineers managing email security records (SPF, DKIM, DMARC)
    • Infrastructure teams managing SRV records for service discovery

    Even with Read & Write access, standard users cannot modify system records like the SOA record or apex NS records. These records are protected and can only be modified by admins through zone settings.

    Inviting Team Members

    To invite a new user to your account:

    1. Go to the Users tab in your dashboard
    2. Click Invite User
    3. Enter the team member's email address
    4. Click Send Invitation

    The invited person will receive an email with a link to join your account. Once they accept, they'll appear in your team members list. By default, new users have no zone access until an admin grants it.

    Invitations expire after 7 days. If the invitation expires, you can resend it from the Users tab.

    Managing Zone Access

    After a user has joined your account, you can control which zones they can access:

    1. Go to the Users tab in your dashboard
    2. Find the user in the team members table
    3. Click Manage in the Zone Access column
    4. For each zone, select the access level: No Access, Read Only, or Read & Write
    5. Click Save Changes

    Changes take effect immediately. The user will only see zones they have been granted access to when they log in or use the API.

    Common Use Cases

    Agency Managing Client Domains

    An agency hosting DNS for multiple clients can create a single DNScale account and invite each client as a standard user. Each client gets Read & Write access only to their own domain, so they can manage their records without seeing other clients' zones.

    Example setup:

    This arrangement lets clients self-service their DNS changes ā€” updating A records for new servers, adding TXT records for domain verification, or configuring MX records for email ā€” without the agency needing to be involved in every change.

    Development Team with Staging and Production

    Grant developers Read & Write access to staging zones but Read Only access to production zones. Only senior engineers or ops staff get Read & Write access to production domains.

    Example setup:

    This prevents accidental production DNS changes while giving developers full control over staging. When a developer needs to test CNAME records or CAA records before applying them to production, they can experiment freely in staging.

    IT Department with Departmental Domains

    A company with separate domains for marketing, engineering, and support can grant each department access only to their relevant zones. The central IT team retains admin access to everything.

    Example setup:

    External Partner Access

    Give an external partner Read Only access to verify DNS configuration for an integration, without exposing any other zones or giving them the ability to make changes. This is common when partners need to verify:

    Multi-Provider DNS Setup

    If you're running a multi-provider DNS deployment, you might have different team members responsible for each provider. Grant the team managing DNScale Read & Write access to the relevant zones, while giving the team managing the secondary provider Read Only access for reference.

    API Key Access

    API keys inherit the permissions of the user who created them. If a standard user creates an API key, that key can only access the zones the user has been granted access to. Admin API keys have full access to all zones.

    This means you can safely distribute API keys to automation tools or third-party services, knowing they can only interact with the intended zones.

    API Key Best Practices

    • Create dedicated API keys per integration -- don't share one key across multiple services
    • Use standard user keys for automation -- create a user for each automation tool and grant only the needed zone access
    • Rotate keys regularly -- delete and recreate keys periodically
    • Use the API for infrastructure as code -- manage DNS records programmatically with Terraform or DNSControl
    # Example: API key scoped to a single zone
curl -X GET "https://api.dnscale.eu/v1/zones/{zone_id}/records" \
  -H "Authorization: Bearer USER_SCOPED_API_KEY"

    An API key created by a user with Read Only access to a zone will receive 403 Forbidden responses when trying to create, update, or delete records in that zone.

    Audit and Accountability

    Multi-user accounts provide built-in accountability. Every DNS change is associated with the user who made it, creating an audit trail. This is important for:

    • Compliance -- demonstrating who changed what and when
    • Troubleshooting -- tracing a DNS propagation issue back to a specific change
    • Security -- identifying unauthorized or accidental changes
    • Team coordination -- understanding which team member last modified a record

    Things to Keep in Mind

    • Admins always have full access. Zone access restrictions only apply to standard users.
    • New users start with no access. After accepting an invitation, an admin needs to grant zone access before the user can see any zones.
    • Removing access is immediate. If you revoke a user's access to a zone, they lose visibility and control right away.
    • Deleting a user is permanent. Removing a team member revokes all their access and invalidates their API keys. They would need a new invitation to rejoin.
    • Zone access applies to records too. If a user has Read Only access to a zone, they also cannot modify any DNS records within that zone, including A, AAAA, MX, TXT, CNAME, and all other record types.
    • API keys are tied to users. If you remove a user, their API keys stop working immediately.
    • Zone access is per-zone, not per-record. You cannot restrict a user to specific records within a zone ā€” access is all-or-nothing at the zone level.

    Getting Started

    If you're ready to set up multi-user access for your account:

    1. Navigate to the Users tab in your dashboard
    2. Invite your first team member
    3. Once they accept, configure their zone access
    4. Repeat for additional team members

    Review your plan to ensure it supports the number of users you need. For questions about user management or zone access, visit the Support page.

    Ready to manage your DNS with confidence?

    DNScale provides anycast DNS hosting with a global network, real-time analytics, and an easy-to-use API.

    Start free