How do you secure your DNS provider account and API tokens?

Treat your DNS provider like a production system. Turn on strong MFA, give each person the least access they need, issue API tokens scoped to a single zone and a single job, store them in a secrets manager, rotate them, and log every change. Anyone who can edit your records can redirect traffic and intercept mail.

Why DNS access matters as much as the registrar

The registrar holds the domain. The DNS host holds the records. They are often the same company, but not always, and in many setups the DNS host is a separate cloud account used by a handful of engineers and several automation tools.

With edit rights an attacker can point your website at their server, change MX records to receive your mail, add a record to pass a verification check for a service that trusts your domain, or request a certificate through a DNS challenge. Several of these show up in our posts on DNS hijacking and the supply chain and ACME DNS challenge delegation.

The checklist

Human access

1. MFA on every account, preferring a hardware key or passkey over a code sent by text.
2. Named accounts for everyone. No shared logins, which hide who made a change.
3. Roles: most people read, few edit, fewer still manage billing and users.
4. Remove leavers the same day, and review the user list each quarter.
5. A break glass account with MFA held by two people, stored offline.

API tokens and automation

6. One token per tool and per purpose, so a leak can be revoked without breaking everything.
7. Scope each token to one zone, and where the provider allows it, to specific record types or names. A certificate renewal job needs the challenge record and nothing else.
8. Store tokens in a secrets manager, not in repository files, CI variables that everyone can read, or chat messages.
9. Set an expiry where supported, and rotate on a schedule you can keep.
10. Restrict by source address if your provider offers it.
11. Delete tokens for tools you no longer use. These are the DNS version of stale accounts.

Visibility

12. Turn on audit logs and send them somewhere that an attacker with DNS access cannot edit.
13. Alert on changes to NS, MX, SPF, DMARC and apex records. These are the high value ones.
14. Keep a recent export of the zone so you can restore it fast. Our DNS as code post goes further.

Steps to take this week

1. List every DNS provider account your company holds, including old ones.
2. For each, list users and tokens. Remove those without an owner.
3. Enable MFA for everyone and confirm it with the admin console, not by asking.
4. Replace any token with full account scope with a narrower one.
5. Move secrets out of source code and rotate any token that was ever stored there.
6. Set up change alerts and test one.

Common mistakes

• Using the registrar login for automation.
• A token created for a one off migration that is still alive three years later.
• DNS credentials in a CI system that runs untrusted pull request code.
• No second administrator, so recovery depends on one person's phone.

Pair these with a registry lock for the registration itself and the hygiene checklist for records.

Safeguard covers the software side with SBOM and dependency scanning, and its asset discovery helps you keep an inventory of what you run. The free scan is at gold.safeguard.sh/scan.

Quick check

Last reviewed: 19 October 2026.