DNS Record Inventory for Agencies: What to Track Across Client Domains

A DNS record inventory for agencies is a structured list of important DNS records across client domains, including A, AAAA, MX, NS, TXT, and CAA records. The goal is simple: know what exists, who owns it, which provider serves it, and what could break if it changes.

Agencies often inherit DNS from clients, previous vendors, registrars, website hosts, CDNs, email platforms, and marketing tools. A website can look fine while DNS ownership is unclear. A client can approve a hosting migration without realizing that email, verification records, SSL issuance, and third-party services depend on records in the same zone.

Use the free 10-domain agency audit when you need portfolio-level visibility across SSL, DNS, and domain expiry. Use the single-domain health check when you need to inspect one client domain quickly. For how CertPilot handles public DNS checks and limitations, review the CertPilot methodology.

Quick answer: what a DNS record inventory is

A DNS record inventory is an operational register for client DNS. It should show:

• domain and hostname
• DNS provider and nameservers
• record type and value
• business purpose
• owner or vendor
• last confirmed date
• expected change window
• risk if changed

It is not just a raw DNS export. A raw export shows values. An agency inventory explains why those values exist and who should approve changes.

Why agencies need DNS record inventories

Client websites depend on DNS in ways that are easy to forget. A homepage may depend on A, AAAA, or CNAME records. Email depends on MX and TXT records. SSL issuance can depend on CAA records. Email authentication depends on TXT records for SPF, DMARC, DKIM selectors, MTA-STS, TLS-RPT, and BIMI-related signals. Verification records can keep Google, Microsoft, analytics, search, ecommerce, and marketing platforms connected.

Without an inventory, agencies usually discover DNS ownership during an incident:

• a website stops resolving after a nameserver change
• MX records disappear during a DNS migration
• a client cannot verify a platform because an old TXT record was removed
• an SSL certificate renewal fails because CAA is too restrictive
• email authentication breaks after an SPF cleanup

The inventory reduces guesswork. It gives the team a shared reference before changing DNS.

What DNS records agencies should track

At minimum, track the records that can affect website availability, email routing, certificate issuance, and account verification.

| Record type | What it controls | Why agencies should track it | Review frequency | |---|---|---|---| | A | IPv4 website or service destination | Website traffic, root domain routing, hosting migrations | Onboarding, migration, quarterly | | AAAA | IPv6 website or service destination | IPv6 visitors and CDN/hosting behavior | Onboarding, migration, quarterly | | CNAME | Alias to another hostname | Subdomains, CDNs, SaaS apps, verification flows | Onboarding, migration, quarterly | | MX | Mail routing | Client email delivery and mail provider migrations | Onboarding, email change, quarterly | | NS | Authoritative DNS provider | DNS ownership and zone location | Onboarding, registrar/DNS change | | TXT | SPF, DMARC, verification, vendor records | Email authentication and platform ownership | Onboarding, vendor change, quarterly | | CAA | Certificate authority authorization | SSL issuance and renewal readiness | Onboarding, SSL provider change |

CertPilot checks public A, AAAA, MX, NS, TXT, and CAA records. CNAME records should still be documented if present, especially for subdomains and SaaS tools, but CertPilot's current public DNS checks focus on A, AAAA, MX, NS, TXT, and CAA.

A and AAAA records

A records point hostnames to IPv4 addresses. AAAA records point hostnames to IPv6 addresses. Agencies should know which hostnames are expected to resolve directly to infrastructure and which are managed through another layer such as a CDN.

Inventory fields to capture:

• hostname, such as example.com or www.example.com
• IP address
• hosting provider or CDN
• expected owner
• whether the record is managed by the agency, host, registrar, or client
• whether IPv6 is intentional

Unexpected A or AAAA changes can indicate a hosting migration, CDN change, provider failover, or an accidental DNS edit.

CNAME records

CNAME records point one hostname at another hostname. They are common for:

• www aliases
• CDN-managed hostnames
• ecommerce storefronts
• helpdesk portals
• tracking domains
• marketing platform subdomains
• verification flows

Document CNAME records if present. They often explain why a subdomain works even though it does not have direct A or AAAA records. Also document who owns the destination hostname. If a CNAME points at a retired SaaS platform, it can create cleanup or takeover concerns that require review.

CertPilot currently focuses public checks on A, AAAA, MX, NS, TXT, and CAA. That means CNAME documentation remains a manual inventory item for now.

MX records

MX records control where inbound email is routed. They should be part of every client DNS inventory, even if the agency does not manage mailboxes.

Track:

• mail provider
• MX hostnames
• priority values
• client or vendor owner
• last confirmed migration date
• relationship to SPF, DKIM, DMARC, MTA-STS, and TLS-RPT

For deeper email-routing context, use the MX record monitoring guide and Inbox Pulse for public email-authentication configuration checks.

NS records

NS records show which nameservers are authoritative for the domain. This is one of the most important ownership signals in DNS.

If NS records change, the active DNS provider may have changed. That can affect every record type in the zone. Agencies should document:

• current nameservers
• DNS provider
• registrar
• who can edit DNS
• backup contact
• migration history

NS records connect directly to the broader DNS monitoring for agencies operating model.

TXT records

TXT records are flexible and often messy. They can represent:

• SPF
• DMARC
• DKIM selector records
• Google/Microsoft/platform verification
• MTA-STS and TLS-RPT-related records
• BIMI-related records
• SaaS vendor verification
• legacy records no one remembers

TXT records need purpose labels. A TXT inventory without business purpose becomes unreadable quickly. For SPF and DMARC, connect the inventory to the DMARC, SPF, and DKIM guide for agencies.

CAA records

CAA records tell certificate authorities which CAs are allowed to issue certificates for a domain. Agencies should track them because restrictive CAA records can affect SSL issuance.

Document:

• allowed CAs
• wildcard authorization with issuewild
• contact or reporting values if present
• certificate provider currently used
• whether Let's Encrypt, Google Trust Services, DigiCert, or another CA is expected

CertPilot checks and records CAA for certificate-authority context. Drift alerts currently focus on A, AAAA, MX, NS, and TXT records. For SSL renewal planning, use CAA records and 47-day SSL for agencies and 47-Day Pre-Flight.

Owner, provider, and access fields

The most useful inventory fields are often not DNS values. They are ownership fields.

Track:

• DNS provider
• registrar
• agency owner
• client owner
• vendor owner
• emergency contact
• who has edit access
• whether access is shared, agency-owned, or client-owned
• change approval rule

This prevents the common incident pattern: everyone sees a problem, but nobody knows who can change DNS.

How to review DNS inventory during onboarding

Use this onboarding workflow:

1. Confirm the registrar and nameservers.
2. Export current DNS records from the provider if access exists.
3. Run a public DNS check for A, AAAA, MX, NS, TXT, and CAA.
4. Identify website records and hosting owner.
5. Identify email provider, MX, SPF, DKIM, and DMARC status.
6. Identify verification records and vendor records.
7. Label unknown TXT and CNAME records for client review.
8. Document CAA and certificate provider expectations.
9. Record who approves future DNS changes.
10. Add unresolved ownership gaps to the client onboarding checklist.

Client DNS inventory checklist

• Domain and registrar recorded.
• Current nameservers recorded.
• DNS provider and admin access owner identified.
• A and AAAA records mapped to hosting or CDN.
• CNAME records documented where present.
• MX records mapped to mail provider.
• SPF, DKIM, and DMARC records labeled.
• Verification TXT records mapped to platforms.
• CAA records checked against certificate provider.
• Unknown records reviewed before cleanup.
• Change approval owner recorded.
• Last confirmed date added.

How to keep DNS inventory useful over time

Review the inventory whenever:

• a website launches
• hosting changes
• DNS providers change
• email providers change
• a marketing platform is added or removed
• SSL issuance fails
• a client joins or leaves a care plan
• a quarterly or monthly proof report is prepared

The inventory should be short enough to use. Do not turn it into a static archive nobody trusts. If a record is unknown, label it as unknown and assign follow-up.

What CertPilot can check automatically

CertPilot checks public DNS records including A, AAAA, MX, NS, TXT, and CAA. It helps agencies see public DNS state without requiring registrar access, DNS provider API keys, or website admin credentials.

CertPilot gives visibility. It does not manage DNS hosting, change DNS records, replace a DNS provider, or automatically repair configuration issues.

What still needs manual documentation

Manual documentation is still needed for:

• record purpose
• vendor owner
• client approval path
• private platform settings
• CNAME business context
• DNS provider access
• registrar ownership
• planned migration windows
• rollback notes

Automation can show what public DNS says. The agency still needs the operating context.

Related Resources

• DNS monitoring for agencies
• DNS drift agency guide
• Monitor DNS changes across client websites
• MX record monitoring for agencies
• DMARC, SPF, and DKIM for agency operations

Frequently Asked Questions

What is a DNS record inventory for agencies?

A DNS record inventory for agencies is a structured list of important DNS records across client domains. It includes record types, values, providers, owners, business purpose, and review dates. The value is not just seeing DNS data; it is knowing which records matter, who owns them, and what could break if they change.

Which DNS records should agencies track first?

Start with A, AAAA, MX, NS, TXT, and CAA records because they affect websites, email routing, DNS ownership, verification, and certificate issuance. Document CNAME records too when they appear, especially for www, CDN, SaaS, ecommerce, helpdesk, and marketing subdomains. Keep the first inventory practical before adding rare record types.

Should agencies document CNAME records if CertPilot does not focus drift checks on them?

Yes. CNAME records are operationally important even if CertPilot's current public DNS checks focus on A, AAAA, MX, NS, TXT, and CAA. CNAME records often explain subdomains, SaaS tools, CDNs, and verification workflows. Treat them as manual inventory items that should be reviewed during migrations and onboarding.

How often should a client DNS inventory be reviewed?

Review it during onboarding, before DNS migrations, after website launches, after email provider changes, and during recurring care-plan reviews. Quarterly is a practical baseline for many agencies. Review sooner if a client adds marketing platforms, ecommerce tools, support platforms, or changes hosting.

Can CertPilot replace manual DNS documentation?

No. CertPilot checks public DNS records and helps agencies spot important signals, but it does not know every internal vendor owner, approval process, or private platform setting. Use CertPilot for public visibility, then add manual context such as owner, purpose, provider access, and client decision history.

Why does CAA belong in a DNS inventory?

CAA can affect which certificate authorities are allowed to issue SSL certificates for a domain. If a domain uses restrictive CAA records, renewal or migration work can fail unless the expected CA is allowed. Agencies should track CAA alongside SSL provider context, especially as certificate renewal cycles become more frequent.