DNS management gets harder in a way that is easy to miss. One domain is simple. Ten domains, each touched by a different vendor, agency or former employee over several years, become a problem nobody owns. Records point at services you cancelled. Some domains have DMARC and some do not. SPF records have drifted until no two match. Nobody can answer the question "what is in our DNS?" without opening each zone by hand.
We manage several domains of our own with a mix of Microsoft 365 and Google Workspace mailboxes, marketing senders and form senders, all on Cloudflare. Increasingly, we do the routine work by connecting Claude to the Cloudflare API and having it read, compare and propose changes across every zone at once, with a person approving each change before it is applied. This article explains how that works, what it is good for, and the guardrails that make it safe enough to use on production DNS.
How Claude connects to Cloudflare
Claude talks to business systems through MCP (Model Context Protocol), an open standard for connecting AI assistants to tools and data. An MCP server sits between Claude and a system's API and exposes actions Claude can call, such as listing zones or reading DNS records.
Cloudflare publishes an official MCP server for its API at mcp.cloudflare.com. According to Cloudflare's documentation, it covers the full Cloudflare API, including DNS, and supports two ways to authenticate: an interactive OAuth flow where you choose which permissions to grant, or a Cloudflare API token passed as a bearer token for automated use. Our article on what MCP servers are covers the broader idea.
Job 1: Inventory every zone
The first and safest use is a read-only inventory. Ask Claude to pull every record from every zone in the account and organize it into a table: domain, name, type, value, TTL, proxy status. With an MCP connection to Google Sheets or Excel, it can write that table directly to a workbook with one tab per domain and a summary tab.
From there, the questions that used to take an afternoon take a minute:
- Which domains have MX records, and which mail provider does each use?
- Which domains have no DMARC record at all?
- Which subdomains point at third-party services, and what are those services?
- Which records are proxied through Cloudflare, and should they be?
- Which records have unusually long or short TTLs?
This inventory also becomes your baseline. Save it, and the next time you ask, you can compare against it to see exactly what changed.
Job 2: Find stale and risky records
Old records are not just clutter. A CNAME that still points at a hosting or SaaS service you stopped paying for can, in some cases, let someone else claim that service name and serve content on your subdomain. Records pointing at old IP addresses can do the same if those addresses are reassigned.
Claude can work through the inventory and flag candidates:
- CNAMEs pointing at platforms commonly used for hosting, landing pages or help desks, so you can confirm whether each is still in use
- A records pointing at addresses that no longer respond or belong to a provider you have left
- Verification TXT records for services you no longer use
- Subdomains with names like old, test, dev, staging or a former vendor's name
- Duplicate records, such as two SPF records on the same name
Treat this as a list for review, not a list for deletion. Verification records in particular look stale but may still be checked by an active service. The value is that a person is reviewing a short, specific list instead of scrolling through every zone.
Job 3: Standardize SPF and DMARC
Email authentication is where DNS drift does the most damage, and it is where a consistent standard pays off fastest. With the inventory in hand, Claude can compare every domain's SPF, DKIM and DMARC records against the standard you define.
A typical standard for a multi-domain business looks like this:
- Domains that send mail: one SPF record that includes only the services that actually send for that domain, ending in -all or ~all depending on how confident you are in the list; DKIM enabled for each sender; and a DMARC record with an enforcing policy once reports confirm everything passes.
- Domains that never send mail: an SPF record that allows nothing and a DMARC record with a reject policy, so nobody can spoof them.
example-parked.com. TXT "v=spf1 -all"
_dmarc.example-parked.com. TXT "v=DMARC1; p=reject"
Claude can flag SPF records with two v=spf1 entries, includes for services you no longer use, or more than the ten DNS lookups the SPF standard allows. It can also cross-check DKIM by looking for the selector records each of your mail providers and senders uses.
One decision that is easier at scale: DMARC aggregate reports. While you are tightening policy, reports sent to the rua address are useful. Once domains are stable, the daily XML reports often become noise. On our own domains we removed the rua address once everything was passing consistently. Making that change across every zone in one reviewed batch is far easier than doing it by hand. Our guide to DMARC reports covers when to keep them and when to turn them off.
Job 4: Bulk changes with review, then apply
This is where the time savings are largest and where discipline matters most. The pattern we use has three steps, every time.
- Propose. Claude reads the current records and produces a change plan: for each zone, the exact record being added, edited or deleted, with the current value and the new value side by side. Nothing is changed at this stage.
- Review. A person reads the plan and approves it, edits it, or removes items. For large batches, we approve in groups, starting with low-risk zones.
- Apply and verify. Claude applies only the approved changes, one at a time, and after each change reads the record back from Cloudflare and checks it with a public DNS lookup to confirm it matches the plan.
Writing the plan to a spreadsheet makes review easy, and the same sheet becomes the change log. A typical row includes the zone, record name, type, old value, new value, reason, approver, time applied and verification result.
Guardrails that make this safe
Connecting an AI assistant to production DNS needs the same controls you would apply to a new employee with admin access. These are the ones we consider non-negotiable.
Scoped API tokens
Do not use a global API key. Create Cloudflare API tokens with only the permissions the task needs. Cloudflare lets you choose a permission such as Zone DNS Read or Zone DNS Edit and restrict it to specific zones.
- Use a read-only token (DNS Read) for inventory and audit work. Most sessions should never need more.
- Issue an edit token only for a planned change window, limited to the zones in that change.
- Set a token expiration date, and use client IP address filtering if the connection runs from a known location.
- Revoke edit tokens when the change is done.
A written change log
Every change should be recorded with the old value, new value, reason and approver. The log is what lets you reverse a change quickly, and it is what you show an auditor or a new IT lead. Cloudflare's own audit log records changes made through the API as well, which gives you a second record.
Verification after each change
Do not batch all the changes and then check. Apply one, read it back, confirm it resolves correctly from outside, then move to the next. If a change does not verify, stop the batch.
Extra care with mail and delegation
Treat MX, SPF, DKIM and DMARC changes as higher risk, and test mail after applying them. Keep nameserver changes, DNSSEC changes and zone deletions out of automated batches entirely. Those should always be done deliberately by a person.
Keep a snapshot
Before any batch of changes, export the current records for each affected zone. If something goes wrong, you can restore from a known good state rather than reconstructing it from memory.
Who this is for
This approach suits companies with several domains, a lean IT team, and a leader who wants to understand and control what is in DNS without learning every record type by heart. It also suits PE-backed groups consolidating acquired businesses, where each new company arrives with its own domains and its own history.
We set this up as part of our DNS management service: connecting Claude to Cloudflare with scoped tokens, building the initial inventory, agreeing a standard, and running the first cleanup with the review-then-apply process. If your domains are not on Cloudflare yet, start with our guide to DNS migration to Cloudflare.
Frequently asked questions
Is it safe to give an AI assistant access to DNS?
It can be, with the right controls. Use scoped API tokens limited to specific zones, keep most work read-only, require human approval of a written change plan before anything is applied, verify each change after it is made, and keep a change log. Never automate nameserver or DNSSEC changes.
Do I need to be technical to use Claude for DNS management?
No. The point is that you can ask questions in plain English and review proposed changes in a readable table. You do need someone who understands DNS to set the standard and approve higher-risk changes, at least at the start.
What Cloudflare API permissions does Claude need?
For inventory and audits, a token with DNS Read permission on the relevant zones is enough. For changes, a token with DNS Edit permission limited to the zones being changed, ideally with an expiration date. Avoid global API keys.
Can Claude manage DNS that is not on Cloudflare?
The approach is the same with any DNS provider that has an API and an MCP server or similar connector. Cloudflare is convenient because it has a well-documented API and an official MCP server, which is one reason we consolidate client domains there.
How often should we audit DNS across our domains?
We suggest a full inventory at least quarterly and after any acquisition, vendor change or mail platform change. Comparing each inventory to the last one makes changes you did not expect stand out quickly.