The “Broken Chain of Custody” Audit: Tracing Asset Control When Clients Refuse to Transfer Registrars

A domain name is one of the most critical single points of failure in a client’s digital presence. It anchors DNS resolution, website traffic, email routing (MX records), domain-validated SSL/TLS certificate issuance, and the verification records that many SaaS and API integrations depend on.

Yet agencies, managed service providers (MSPs), and web development firms routinely meet the same awkward scenario: the client who expects full-service website management, uptime commitments, and renewal tracking, but refuses to move their domain into an account the agency can administer.

The domain usually sits in a personal or legacy registrar account. It may be registered under a personal Gmail address, protected by 2FA tied to a former employee’s phone, and billed to a card that expired a year ago.

That leaves the agency exposed. You are expected to keep the site fast, secure, and available, but you do not control the asset that makes it reachable. When a billing failure, account takeover, or lockout happens, clients rarely blame their own account hygiene. They blame the agency.

This article lays out a practical framework for a “Broken Chain of Custody” Audit. It helps you map administrative gaps, tighten security on accounts you don’t own, set contractual boundaries around domain-related outages, and turn a recurring headache into a billable, trust-building service.

A note on scope: this article offers operational guidance and sample contract language, not legal advice. Have a qualified attorney in your jurisdiction review any clause before you use it.

---

What Is a “Broken Chain of Custody” in Domain Asset Management?

In legal and forensic work, chain of custody is the documented trail showing who controlled a piece of evidence, when, and what happened to it. If the trail has gaps, the evidence’s integrity can be challenged.

The same idea applies to domains. A domain chain of custody is the documented, continuous line of ownership, administrative control, and technical access running from the registrant to the registrar account, the DNS, and the application serving traffic.

INTENDED CHAIN OF CUSTODY

[ Registrar account ] --> [ DNS hosting ] --> [ Web host / application ]
  Org-owned account,        Role-based access,    Deployed and monitored
  agency has scoped         change logging        by the agency
  access, shared contacts

BROKEN CHAIN OF CUSTODY

[ Client's personal registrar account ] - -> [ Unmanaged DNS ] - -> [ Agency-run server ]
  Personal email login                       Edits by anyone with      Agency owns the
  Expiring card                              access, no change log     uptime promise but
  Departed employee's 2FA                                              not the domain

A broken chain of custody exists when an agency takes operational responsibility for a domain’s uptime, security, and DNS performance without direct administrative control over the registrar account behind it.

Common Symptoms of a Broken Chain

1. Shared personal credentials. The agency holds a password to a personal GoDaddy, Namecheap, or Network Solutions login instead of delegated, role-limited access.
2. Orphaned contacts. The account email, or the registrant contact on file, belongs to a former employee, a departed freelancer, or a defunct vendor.
3. Single-person 2FA. Verification codes go to one executive’s personal phone, and that person is often unreachable.
4. Unwatched billing. Auto-renewal depends on a card that expires, and the notices go to an inbox nobody monitors.
5. DNS drift. Third-party vendors, marketers, or internal staff add, change, or delete records without telling the agency.

---

The Operational and Legal Risks of the Unmanaged Registrar

When a client keeps the domain in an unmanaged account but expects the agency to keep everything running, four problems tend to appear.

Registrar-level failure          Downstream effect                Business impact
-----------------------          -----------------                ---------------
Expired domain                   DNS stops resolving              Site and checkout unreachable
Failed renewal payment           Mail (MX) lookups fail           Inbound email bounces
2FA / account lockout            Certificate renewals fail        Integrations and verifications break
Hijack or unauthorized change    Traffic rerouted                 Phishing, spoofing, brand damage
                                        |
                                        v
                               Agency exposure: SLA disputes, reputational damage, unpaid emergency work

1. The Auto-Renewal Trap

Domains do fail abruptly, but the sequence is more nuanced than “gone the moment it expires.” Under ICANN’s Expired Registration Recovery Policy (ERRP), registrars must disrupt DNS resolution after expiration. Any parking page the registrar puts up has to include renewal instructions. If the registrar doesn’t delete the domain right away, it may offer an Auto-Renew Grace Period of up to 45 days, and registrars must send at least one more expiration notice within five days after expiry. Generic TLD registries then provide a 30-day Redemption Grace Period after deletion, during which DNS stays disabled and the registered name holder can restore the domain, usually for an added fee. Policies for country-code TLDs vary.

For an agency, the practical result is that a lapsed card can take down a perfectly healthy site, and recovery may be possible but only by someone with access to the registrar account.

What typically breaks in the meantime:

• The web server keeps running, but visitors can’t reach it by name.
• Inbound email fails because MX lookups no longer resolve.
• Certificates already issued stay valid until their own expiry, but renewals that depend on domain validation (HTTP-01 or DNS-01 challenges) cannot complete while DNS is disrupted.

Validity windows are also shrinking. Under CA/Browser Forum Ballot SC-081v3, the maximum lifetime for publicly trusted TLS certificates dropped to 200 days on March 15, 2026. It falls to 100 days on March 15, 2027 and to 47 days on March 15, 2029. Domain-validation reuse periods shrink on the same schedule, to as little as 10 days by 2029. Certificates will be re-validated far more often, so a domain that can’t answer validation challenges becomes a certificate problem sooner.

The client sees an “agency hosting crash,” even though the fault sits in an account the agency never controlled.

2. DNS Record Drift and Email Authentication Breakdown

Domain management goes well beyond A and AAAA records. Email authentication lives in DNS too:

• SPF (Sender Policy Framework) lists the servers allowed to send mail for the domain.
• DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing messages, verified through a public key published in DNS.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance) tells receivers what to do when SPF/DKIM checks fail and where to send reports.
• BIMI (Brand Indicators for Message Identification) can display a brand logo in supporting inboxes. It requires DMARC enforcement (p=quarantine or p=reject), and Gmail additionally expects a Verified Mark Certificate (VMC) or Common Mark Certificate (CMC).

The stakes rose in recent years. Google and Yahoo began enforcing bulk-sender authentication requirements in February 2024, and Microsoft began enforcing similar requirements for high-volume senders (5,000+ messages a day) to Outlook.com, Hotmail.com, and Live.com on May 5, 2025. A client who marks a stray TXT record “unused” and deletes it, or a marketing vendor who overwrites the SPF record, can quietly push legitimate mail into spam folders.

Because the agency “manages the website,” the client often assumes the agency will fix the deliverability problem under the existing retainer, even though the agency may not have access to the DNS panel where the change was made.

3. Account Takeover and Registrar Hijacking

Registrar accounts protected only by a password, or by SMS-based codes, are attractive targets for credential stuffing, phishing, and social engineering. If an attacker gets in, they can repoint name servers, change contact emails, unlock the domain, and start a transfer.

A real example shows how thin the defenses can be. In July 2024, attackers hijacked the domains of several crypto and DeFi organizations, including Compound Finance, Celer Network, and Pendle, that were being migrated from Google Domains to Squarespace. Security researchers concluded that unclaimed migrated accounts could be taken over by registering with an email address tied to the domain, in some cases without a password or 2FA. Squarespace disputed parts of that analysis, but the lesson stands regardless of how the root cause is ultimately described. An unmonitored registrar account is a liability, and the people who own the domain are often the last to find out.

In that situation, an agency that lacks any administrative standing at the registrar has little leverage to get the registrar’s fraud team moving quickly.

4. Legal Exposure and Unfunded Liability

Without explicit contract language separating website maintenance from domain administration, a client may assume your maintenance agreement covers everything that keeps the site reachable. If a domain lapses during a campaign or product launch, the client may look to the agency to cover lost revenue and emergency costs. Whether such a claim succeeds depends on your contract, your jurisdiction, and the facts, which is exactly why the language should be explicit and reviewed by counsel.

---

Step-by-Step: Executing the “Broken Chain of Custody” Audit

Run this audit for every client whose domain remains in an external registrar account. It evaluates four areas: Administrative, Technical, Security, and Financial.

4-PILLAR AUDIT MATRIX

1. ADMINISTRATIVE          2. TECHNICAL            3. SECURITY             4. FINANCIAL
- Registrant of record     - Name server setup     - 2FA method            - Card expiry
- Account email            - DNSSEC status         - Access model          - Auto-renew status
- Contacts on file         - CAA records           - Transfer / registry   - Registration term
- Who can recover          - TTL values              lock                  - Backup payment
  the account              - Email auth records    - SSO (if offered)

Step 1: Administrative Control Verification

This step establishes who controls the account and which people or inboxes the registrar treats as authoritative, so you find access bottlenecks before an emergency does.

1. Check what the public record can and cannot tell you

Since January 28, 2025, RDAP (Registration Data Access Protocol) has been the required source of registration data for generic TLDs, and ICANN lifted the requirement for gTLD registrars and most registries to run WHOIS. Under ICANN’s Registration Data Policy, which took effect August 21, 2025, registrars publish only a limited subset of registration data. A public lookup now reliably shows technical facts such as the registrar, status codes, name servers, and key dates, but registrant name and contact details are typically redacted.

That changes what an agency can verify from the outside. To confirm that the registrant of record is the client’s legal entity and not a former employee or vendor, you generally need to look inside the registrar account (or have the client do it), not rely on a public lookup.

Use RDAP for what it does show:

# Registrar, status codes, and key dates via RDAP (rdap.org redirects to the right server)
curl -sL https://rdap.org/domain/exampleclient.com | jq '{status: .status, events: .events}'

2. Audit the account’s administrative email

• Check: Is the root login tied to an individual’s address (jsmith@gmail.com) or to a monitored role-based alias (domains@clientcompany.com)?
• Risk: If tied to a person, access can disappear when that person leaves, changes roles, or loses the mailbox.
• Requirement: Move the account to a monitored alias that several named people can read.

3. Know the transfer-lock rules before you recommend any changes

Changing registrant details can trigger a transfer lock. Under the current ICANN Transfer Policy, a change of registrant generally triggers a 60-day inter-registrar transfer lock unless the registrant opts out beforehand, and ICANN has approved recommendations to remove that lock in a future policy update. Check the registrar’s current rules before updating contacts, especially if a transfer to a managed account is planned.

---

Step 2: Technical Configuration and DNS Drift Assessment

This step reviews how the domain interacts with authoritative DNS and flags configuration choices that add single points of failure.

1. Evaluate name server delegation

Find out where authoritative DNS actually lives: on the registrar’s default name servers, at the web host, or on a dedicated DNS platform such as Cloudflare or Amazon Route 53.

# Show the delegation path and name servers
dig +trace exampleclient.com NS

2. Audit security-relevant DNS records

• CAA records. Certification Authority Authorization records restrict which certificate authorities may issue certificates for the domain.

  dig exampleclient.com CAA +short
  # Example output: 0 issue "letsencrypt.org"

• DNSSEC. Check whether it is enabled. If DNSSEC is active at the registrar but zone keys change at an external DNS provider without the registrar’s DS (Delegation Signer) record being updated, validating resolvers will fail to resolve the domain.

  dig exampleclient.com +dnssec +multi

• TTL values. Very high TTLs (for example 86400 seconds, 24 hours) slow down changes during an emergency IP move or failover. Moderate values such as 300 to 3600 seconds are common for critical records, with a short-term reduction ahead of planned migrations.
• Email authentication records. Capture the current SPF, DKIM, and DMARC records in your audit file so later changes can be compared against a known-good baseline.

---

Step 3: Security and Access Delegation Review

This step maps how the agency actually logs in to the registrar and whether that method follows least-privilege principles.

1. Map the access method

2. Review the 2FA method

Ask what the second factor is and who holds it. SMS is the weakest common option. NIST’s current digital identity guidelines (SP 800-63-4, finalized in 2025) classify SMS one-time codes as a “restricted” authenticator and strongly recommend phishing-resistant options such as FIDO2 security keys or passkeys. Where the registrar supports it, prefer an authenticator app or security key registered to more than one named person at the client.

3. Check lock status, and understand its limits

whois exampleclient.com | grep "Domain Status"
# Desired: Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited

The clientTransferProhibited status is a registrar-level lock against transfers. It is useful, but whoever controls the registrar account can usually remove it, so it does not protect against account takeover on its own.

For high-value .com, .net, .cc, and .name domains, Verisign offers a Registry Lock through participating registrars. It adds an out-of-band verification step between the registrar and the registry before changes can be made, and it shows up as serverTransferProhibited, serverUpdateProhibited, and serverDeleteProhibited statuses. Availability and cost depend on the registrar.

---

Step 4: Financial and Billing Verification

Billing oversights are among the most preventable causes of domain lapses. This step confirms that payment is redundant and that someone is watching it.

# Check the expiration date (RDAP events or WHOIS)
whois exampleclient.com | grep -iE "expiry|expiration|expires"

• Auto-renewal. Confirm that auto-renew is turned on in the registrar portal.
• Payment instrument. Record the expiration date of the card on file. If it expires within 90 days, log an action item for the client.
• Backup payment method. Ask the client to add a second, independent payment method if the registrar supports one.
• Who gets the notices. Confirm the renewal-reminder emails go to a monitored shared inbox, not one person.
• Term length. Consider multi-year registrations for critical domains. They reduce how often a failed payment can cause a lapse, though they don’t replace monitoring.

---

The Chain of Custody Audit Checklist

Run this checklist at onboarding and during each annual account review.

# Domain Asset "Chain of Custody" Audit Checklist

**Client Name:** ___________________________
**Domain Name(s):** ________________________
**Primary Registrar:** _____________________
**Audit Date:** ____________________________
**Auditor Name/Role:** ____________________

---

### Phase 1: Administrative Integrity
- [ ] **Registrant of record:** Confirmed inside the registrar account (public lookups are usually redacted) as the client's legal entity.
- [ ] **Account email:** Root login uses a monitored role-based alias, not an individual's personal email.
- [ ] **Contacts on file:** Agency escalation contacts are listed where the registrar supports them.
- [ ] **Ownership records:** Client holds registration confirmations or invoices for the domain.
- [ ] **Recovery path:** At least two named client people can recover the account.

### Phase 2: Security and Access
- [ ] **Access model:** Agency access is via native delegation or role-based access, not a shared password.
- [ ] **2FA method:** Authenticator app or security key, registered to more than one named person (not SMS-only).
- [ ] **Transfer lock:** `clientTransferProhibited` is present. Registry Lock considered for high-value .com/.net domains.
- [ ] **SSO:** Used where the registrar supports it.

### Phase 3: Technical and DNS
- [ ] **Authoritative DNS identified:** Registrar, web host, or dedicated DNS platform.
- [ ] **CAA records:** Present and limited to approved certificate authorities.
- [ ] **DNSSEC:** Either fully operational with matching DS records, or deliberately disabled.
- [ ] **TTLs:** Critical records set to sensible operational values.
- [ ] **Email authentication baseline:** SPF, DKIM, and DMARC records captured and documented.

### Phase 4: Financial Resilience
- [ ] **Auto-renewal:** Enabled.
- [ ] **Registration term:** Multi-year term considered for critical domains.
- [ ] **Card expiry:** Primary card does not expire within 90 days of the audit date; expiry date recorded.
- [ ] **Backup payment method:** Secondary method configured where supported.
- [ ] **Renewal notices:** Routed to a monitored shared inbox.

---

### Audit Finding and Risk Escalation
- **Overall Status:** [ ] PASSED  |  [ ] PASSED WITH WARNINGS  |  [ ] CRITICAL FAILURE
- **Action Items Required:**
  1. ____________________________________________________________________
  2. ____________________________________________________________________
  3. ____________________________________________________________________

---

Documenting Responsibility: The Contract Framework

If a client reviews the audit findings and still refuses to transfer the domain or upgrade the account setup, document the boundaries in writing. A clear contract lets both sides know who is responsible for what before something breaks.

A well-drafted clause can set expectations, allocate responsibility, and define how emergency work is billed. It cannot guarantee that a court will enforce every limitation. Enforceability of liability limits and indemnities varies by jurisdiction, so treat the sample below as a starting point for your attorney.

Sample Clauses for Your MSA, SOW, or SLA

# Sample MSA Amendment: Client-Controlled Domain Accounts

### Section X.X: Domains Held in Third-Party Registrar Accounts

1. **Definition.** If the Client elects to keep the registration or authoritative DNS of a domain in an account the Agency does not administer, that domain is a "Client-Controlled Domain."

2. **Scope.** For Client-Controlled Domains, the Agency's services are limited to application-layer maintenance and server-side configuration. Unless separately agreed in writing, the Agency is not responsible for:
   a. Monitoring expiration dates, payment methods, or billing at the third-party registrar.
   b. Outages caused by domain expiration, registrar suspension, redemption status, or payment failure.
   c. Account-level access controls, including 2FA devices, user permissions, and credential recovery.
   d. Problems resulting from DNS changes made by the Client or third parties not under the Agency's direction.

3. **SLA Exclusion.** Downtime, certificate renewal failures, or email failures caused by the events above are excluded from uptime calculations and service-credit eligibility.

4. **Emergency Work.** If the Client requests emergency assistance related to a Client-Controlled Domain, the work will be billed outside the standard retainer at the Agency's emergency rate of $____/hour, with a minimum engagement of $____, after the Client signs the Emergency Authorization Form.

5. **Indemnification.** [Counsel to draft or review. Scope, caps, and enforceability vary by jurisdiction.]

6. **Client Duties.** The Client will keep the registrar account's contact details, payment method, and auto-renewal settings current, and will give the Agency the access agreed in the Audit Report.

---

Operating Procedures: Handling an Outage on an Unmanaged Domain

When a client-controlled domain fails, follow a fixed sequence. The goal is to help quickly while keeping responsibility clearly documented.

1. TRIAGE       Confirm the server is healthy and isolate the fault to the domain layer.
2. EVIDENCE     Send the client proof of server health plus the DNS/registry evidence.
3. AUTHORIZE    Get written approval for out-of-scope emergency work before starting.
4. POST-MORTEM  Review the incident and re-present the migration or delegated-access options.

Step 1: Rapid Diagnostic Triage

# 1. Does the server respond directly, bypassing DNS?
curl -Iv http://[SERVER_IP_ADDRESS] -H "Host: exampleclient.com"

# 2. What do public DNS servers currently say?
dig +short NS exampleclient.com

# 3. What status flags does the registry show (clientHold, redemptionPeriod, etc.)?
whois exampleclient.com | grep -iE "status|expiry"

If the server answers by IP address but public DNS fails or points to a registrar holding page, the fault is at the domain layer, not the hosting layer.

Step 2: The “Proof of Server Health” Client Message

Subject: URGENT: Action Required - Domain Resolution Failure for [Client Domain]

Dear [Client Contact],

At [time, timezone], our monitoring detected a disruption affecting [exampleclient.com].

**Diagnostic summary:**
Our checks show your web application and hosting environment are operating normally. The disruption is occurring at the domain registration layer, in an account we do not administer.

**Likely cause:** [Domain expiration / Payment failure / DNS change / Name server change]
**Current domain status:** [EPP status, e.g., clientHold / redemptionPeriod]
**Impact:** Public DNS is no longer directing visitors to your site, and inbound email may be failing.

**What we need from you:**
1. Log in to your [Registrar Name] account.
2. Confirm the payment card on file is valid and pay any pending renewal or redemption invoice.
3. Confirm the name servers are set to: [ns1.example.net / ns2.example.net]

If you would like our team to work directly with the registrar or rebuild DNS records, please sign the attached Emergency Out-of-Scope Authorization Form.

Sincerely,
[Name / Agency]

Step 3: Emergency Out-of-Scope Authorization

Resolving a lapsed domain at a consumer registrar can take hours of support calls. Get written sign-off before you start.

# Emergency Technical Assistance Authorization

**Date:** ______________  **Client:** ______________________________
**Domain:** [exampleclient.com]  **Incident type:** Client-controlled domain / external DNS

**Requested work:** The Client authorizes [Agency] to perform emergency technical work, contact third-party vendors, and attempt remediation on the domain above.

**Billing:**
1. This work is outside the Agency's standard services and is billed as out-of-scope.
2. Rate: $[Rate]/hour, billed in 30-minute increments; minimum diagnostic charge $[Minimum].
3. The Client acknowledges that resolution depends on the registrar's own response times and policies, and no timeline is guaranteed.

**Authorized signature:** ____________________  **Name/Title:** ____________________

---

Turning Risk into Revenue: Upgrade and Migration Paths

Frame the audit as a risk-reduction service, not a legal maneuver. When clients see a completed matrix showing an expired card, SMS-only 2FA, and a departed employee as the account owner, many are open to a safer arrangement.

Offer two clear options.

Path A: Agency-Managed Domain Portfolio

The domain moves to an account the agency controls, with the client named as registrant of record and ownership documented in writing.

• What the agency can offer: consolidated renewals, multi-year registrations, centralized DNS with change history, and periodic reviews of SPF, DKIM, DMARC, and CAA records.
• Where it can live: a registrar with strong account controls. Amazon Route 53, for example, supports IAM permissions and records management actions in AWS CloudTrail, and its DNS service carries a 100% availability SLA (remedied through service credits). Cloudflare Registrar sells domains at cost, but it requires Cloudflare to be the authoritative DNS provider. Corporate registrars such as MarkMonitor (now owned by Com Laude) and CSC target large brands and may be more than most clients need.
• Pricing: set it based on your costs, your service scope, and the registrar fees you pass through. Be explicit about who is the registrant and what happens if the engagement ends.

Path B: Client-Owned, Agency-Governed Delegation

If the client must keep the registration (for compliance reasons, or simply by preference), move them to a registrar that supports proper access controls and set up scoped delegation:

1. Choose a registrar with multi-user access. Look for individual logins, role-based permissions, and security-key or authenticator-app 2FA. SSO availability varies by registrar and plan.
2. Grant scoped access. Give the agency the permissions it needs for DNS and renewals without shared passwords or access to billing credentials.
3. Capture logs where the platform allows. Some platforms, such as AWS via CloudTrail, can export administrative activity to a monitoring or SIEM tool. Check what your chosen registrar offers.
4. Keep the client as the billing owner. Pair this with a monitored renewals inbox and a backup payment method.

Tracking Who Owns What

Whichever path you choose, the audit only helps if the findings stay current. Keep a record of each domain’s registrar, account owner, billing owner, expiration date, notice contact, and agreed access level, and review it on a schedule. A dedicated tracker, or a shared sheet in a small portfolio, keeps the renewal dates and the ownership-versus-payment mapping visible so that a lapse never comes as a surprise.

---

Summary: The Chain of Custody Strategy

1. AUDIT     Run the four-pillar audit at onboarding and annually.
2. CONTRACT  Put domain responsibility, SLA exclusions, and emergency billing in writing (with counsel).
3. ISOLATE   During outages, prove server health with diagnostic evidence.
4. AUTHORIZE Get written approval before starting out-of-scope emergency work.
5. CONVERT   Offer managed or delegated-governance options after every incident.

You can’t fully protect an asset you don’t control, but you can make the gap visible, documented, and priced. A consistent Chain of Custody Audit shows clients where their risk lives, and it protects your agency from carrying that risk on its own.