The “Broken Handover” Audit: What to Do When a Client Fires Another Agency and Leaves You With Unmanaged DNS

Winning a new client account often feels like a victory, until the onboarding kickoff exposes a looming infrastructure problem.

The client has recently parted ways with their former agency, sometimes on bad terms. The previous agency may have deleted the management portal, kept the domain registrar login, or left a web of custom DNS records scattered across third-party cloud accounts. Often there was no malice, only years of neglect. The client’s marketing leads don’t know where the domain is registered, who holds administrative access, or why transactional emails are landing in spam.

We’ll call this scenario a Broken Handover.

Inheriting unmanaged DNS is high-stakes for any agency or managed service provider (MSP). A single mistake during onboarding can mean website downtime, broken SaaS integrations, lost email, or lasting reputational damage.

This triage guide walks through an audit framework for securing, reconstructing and taking control of an unmanaged DNS setup while keeping the risk of disruption as low as possible. Where a step depends on a standard, a deadline or a vendor policy, the current rule is noted so you can verify it against your own environment.

Before You Touch Anything

• Get written authority. Registrars, DNS hosts and cloud vendors will want proof that you act for the legal domain owner. Get a signed letter of authority or an email from someone with signing power at the client.
• Snapshot the current state. Save timestamped output of dig queries for the apex and www, plus every MX, TXT and NS record. Screenshot whatever dashboards you can reach. This is your rollback reference and your evidence if anything is later disputed.
• Freeze change requests. Ask the client to pause new site launches, email platform changes and marketing-tool onboarding until the audit is done.

Phase 1: Triage & Emergency Stabilization (Hours 0–4)

Your priority is stabilization. Before changing any record, establish who controls what, and make sure a former vendor can’t sabotage the account.

┌─────────────────────────────────────────────────────────┐
│               DNS STABILIZATION TIMELINE                │
└─────────────────────────────────────────────────────────┘

  Hours 0–4      Establish Authority & Lock Registrars
  ┌──────────┐   • Get written client authority
  │ PHASE 1  │   • Identify registrar & authoritative NS
  └────┬─────┘   • Secure registrar login, MFA, locks
       │
  Hours 4–12     Reconstruct the Zone
  ┌────▼─────┐   • Build record inventory from multiple sources
  │ PHASE 2  │   • Audit mail records (SPF, DKIM, DMARC)
  └────┬─────┘   • Lower TTLs to 300s (if old DNS host reachable)
       │
  Hours 12–24    Eliminate Takeover Risks
  ┌────▼─────┐   • Find dangling CNAMEs, stale IPs, lame NS
  │ PHASE 3  │   • Reclaim or delete orphaned records
  └────┬─────┘   • Keep dead records out of the new zone
       │
  Day 2+         Stage, Cut Over, Verify
  ┌────▼─────┐   • Stage new zone & CAA records
  │ PHASE 4  │   • Handle DNSSEC DS records first
  └──────────┘   • Switch NS; keep old zone live 48–72h

1. Identify Ownership & Location

Don’t rely on the client’s memory. Establish ground truth from the public DNS and registration data:

# Registration data (registrar, dates, status codes, nameservers)
whois example.com

# Delegation as published by the parent zone
dig example.com NS +short
dig +trace example.com NS

# Does each listed nameserver actually answer for the zone?
dig @ns1.provider.com example.com SOA +norec

You can also use ICANN’s lookup tool. On 28 January 2025, gTLD registries and registrars stopped being required to offer WHOIS, except for .com, .name and .post, and RDAP is now the required protocol, according to ICANN’s RDAP FAQ. WHOIS may therefore be unavailable for some TLDs, and ccTLDs follow their own rules. Registrant details are often redacted. The registrar, creation date, nameservers and EPP status codes are generally still visible.

Two different things need answering:

• The domain registrar: where the name is registered (for example Namecheap, GoDaddy, Cloudflare Registrar or Amazon Route 53 registered domains).
• The authoritative nameservers: where the live DNS zone is actually hosted (for example Cloudflare, Route 53, DigitalOcean, or a server owned by the former agency).

These are often different companies. If the client controls the registrar but the former agency controls the DNS host, you can still re-delegate the domain to a new provider without the agency’s cooperation. You just need a complete, reconstructed zone ready first.

2. Secure Registrar Access & Apply Locks

If the client still holds the registrar credentials, log in and lock things down immediately:

• Strengthen authentication. Enable the strongest MFA the registrar supports, preferably FIDO2/WebAuthn security keys or passkeys where offered, otherwise an authenticator app (TOTP). TOTP is not hardware-based. Remove SMS-based recovery wherever possible.
• Clean up contacts. Remove recovery and notification emails that belong to the former agency, and replace them with a client-owned role mailbox. Contact changes can trigger side effects (see the next section).
• Enable registrar locks. clientTransferProhibited blocks transfers to another registrar, and clientUpdateProhibited and clientDeleteProhibited add further protection. These are registrar-level locks that anyone with account access can toggle, so they’re only as strong as the account’s security. For high-value domains, ask whether the registrar offers registry lock, which requires out-of-band verification for changes.
• Verify new contact emails. After you change registrant contact data, the registrar typically sends a verification email. If it isn’t confirmed within the deadline (commonly 15 days), the domain can be suspended. Make sure someone monitors that inbox.
• Mind the change-of-registrant lock. Under the current ICANN Transfer Policy, a material change to registrant information can trigger a confirmation step and a 60-day inter-registrar transfer lock. Some registrars offer an opt-out before you make the change, but they aren’t required to. If you plan to move the domain to a different registrar, ask about the opt-out first. ICANN’s Board approved 47 Transfer Policy Review recommendations on 7 June 2026, but implementation was still pending as of September 2026. Check the policy in force when you act.

3. What to Do If You’re Locked Out Entirely

If the former agency registered the domain in its own name or won’t hand over credentials, escalate in this order:

1. Document your claim. Gather invoices and card statements showing the client paid for registration and renewals, the signed contract and any IP-ownership or asset-transfer clauses, business formation documents, and any trademark registrations.
2. Make a written demand. Send a formal request to the former agency citing the contract. Many handovers are resolved at this stage.
3. Go to the registrar. Ask the registrar about its account-recovery or ownership-verification process, and submit your documentation. Processes and evidentiary requirements vary, and some registrars will only act on a court order. ICANN itself does not resolve individual domain disputes, and ultimately courts decide ownership rights.
4. Consider a formal proceeding, with counsel. The UDRP lets a complainant seek transfer of a domain, but it requires showing that the domain is confusingly similar to a trademark the complainant has rights in, that the registrant lacks legitimate interests, and that the domain was registered and used in bad faith. ICANN’s own ombudsman describes this as a narrow category to approach with caution. A dispute that is really about a contract may fit poorly. In the U.S., the Anticybersquatting Consumer Protection Act offers a court route. Country-code registries run their own schemes. For example, Nominet’s Dispute Resolution Service for .uk domains has been used to recover domains from web developers who registered them on a client’s behalf.
5. Prepare the replacement setup in parallel. Build and test the new zone and email configuration now, so you can cut over quickly the moment control is restored.

Phase 2: Complete DNS Zone Reconstruction (Hours 4–12)

If the former agency won’t provide a clean zone export (a BIND-format file), reconstruct the zone from several sources. Start by asking politely for an export anyway. If the DNS host still lets you in, export from there.

Be skeptical of automatic importers. DNS providers’ onboarding scans query common hostnames and can miss records, including DKIM selectors and anything created by a wildcard. Cloudflare’s own guidance is to review scan results manually and add anything missing before changing nameservers. A BIND zone-file import followed by a record-by-record comparison is more reliable.

You can try a zone transfer against each authoritative server, though well-configured servers refuse it:

dig AXFR example.com @ns1.provider.com

Zone Reconstruction Matrix

Also look for _acme-challenge CNAMEs or TXT records. Certificate automation may depend on them, and with certificate lifetimes shrinking (see Phase 4) a missing validation record causes outages on a predictable schedule.

Deep-Dive: Auditing Email Authentication (SPF, DKIM, DMARC)

Email deliverability is often the first casualty of a bad handover. Mailbox providers have also raised the bar. Google and Yahoo began enforcing bulk-sender rules in February 2024, and Microsoft followed for Outlook.com consumer accounts from 5 May 2025. The rules cover senders of roughly 5,000 or more messages per day and require SPF, DKIM and at least a p=none DMARC policy.

# Current SPF record
dig example.com TXT +short | grep "v=spf1"

# DKIM selector records (selectors vary by sending platform)
dig google._domainkey.example.com TXT +short
dig selector1._domainkey.example.com CNAME +short
dig k1._domainkey.example.com CNAME +short

# DMARC policy
dig _dmarc.example.com TXT +short

• Audit SPF. A domain may publish only one SPF record. Under RFC 7208, evaluation is limited to 10 DNS-querying terms (include, a, mx, ptr, exists and redirect) and two “void” lookups. Exceeding either causes a permanent error, so legitimate mail can fail SPF. Remove includes for services the client no longer uses, such as old Mailchimp or ActiveCampaign setups, and stale IP ranges.
• Locate DKIM selectors. DNS cannot list selectors, so you can’t discover them by querying the zone. Find them in the s= tag of a DKIM-Signature header on real outgoing mail, or in each sending platform’s authentication settings. Common examples are google for Google Workspace, selector1 and selector2 for Microsoft 365, and k1 for Mailchimp. Mailbox-provider guidance sets 1024 bits as the minimum DKIM key length and recommends 2048 bits. Keys are generated by the sending service and you publish the record it gives you. A 2048-bit key exceeds the 255-character limit of a single DNS string, so it must be split into multiple quoted strings, which most DNS providers do automatically.
• Set up DMARC monitoring. If the previous agency left DMARC at p=none, or none exists, publish a record that collects aggregate reports and review them before tightening. Move to p=quarantine, then p=reject, once all legitimate senders pass.

# Example baseline DMARC record for the audit phase
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@youragency.com"

DMARC’s specification changed in May 2026, when the IETF published RFC 9989, RFC 9990 and RFC 9991, replacing the original RFC 7489. The record version tag stays v=DMARC1, so existing records keep working. The pct, rf and ri tags were removed and a t testing flag was added, which is why the example above omits pct. Failure (ruf) reports are optional, are not sent by many receivers, and can include message content, so they aren’t a reliable audit tool. If your reporting address is on a different domain than the one being protected, the reporting domain may need to publish an authorization record. Most DMARC reporting services handle this for you.

Phase 3: Securing “Dangling” Records & Subdomain Takeovers (Hours 12–24)

A critical risk in an unmanaged handover is the dangling CNAME. The previous agency may have cancelled cloud services (AWS S3, GitHub Pages, Heroku, Azure, Shopify and others) without deleting the DNS records pointing to them.

┌─────────────────────────────────────────────────────────┐
│              SUBDOMAIN TAKEOVER MECHANICS               │
└─────────────────────────────────────────────────────────┘

 1. DNS Record Active         2. Cloud Service Cancelled
┌─────────────────────┐      ┌───────────────────────────┐
│ promo.example.com   │─────►│ example.s3.amazonaws.com  │
│ (CNAME Record)      │      │ (Deleted by Old Agency)   │
└─────────────────────┘      └─────────────┬─────────────┘
                                           │
 3. Attacker Claims Endpoint               │
┌──────────────────────────────────────────┴─────────────┐
│ Attacker creates a resource with the same name         │
│ Result: Attacker serves content from                   │
│ promo.example.com                                      │
└────────────────────────────────────────────────────────┘

This is not theoretical. Infoblox’s research into a threat actor it tracks as Hazy Hawk describes hijacked subdomains of organizations including the US CDC, Deloitte and UNICEF. The actor claimed abandoned cloud resources (such as S3 buckets and Azure endpoints) behind dangling CNAMEs and used them to distribute scams and malicious content. Infoblox’s May 2025 report noted that finding vulnerable records takes effort, since every cloud provider handles dropped resources differently and some, such as Azure, have built-in protections. Its recommendation is to remove DNS records whenever a cloud resource is shut down. An agency inheriting a client’s DNS should treat every dangling record as a defect, whether or not the provider is currently exploitable.

How to Audit for Dangling Records

1. Build the CNAME list. Pull every CNAME from your reconstructed inventory, including passive DNS and certificate-transparency results.
2. Test where each one points. A non-resolving target (NXDOMAIN) is a strong warning sign:

   while read -r host; do
     target=$(dig +short CNAME "$host" | head -1)
     [ -n "$target" ] || continue
     dig +short "$target" | grep -q . || echo "NO ANSWER: $host -> $target"
   done < subdomains.txt

1. Check the HTTP response. Where the target still resolves, look for “unclaimed” fingerprints. The community-maintained can-i-take-over-xyz list tracks these. For example, an S3 target returning NoSuchBucket (message: “The specified bucket does not exist”) is listed as vulnerable. GitHub Pages (“There isn’t a GitHub Pages site here”) and Heroku (“No such app”) are listed as edge cases, so verify before assuming either way.
2. Check the delegation itself. If a domain’s NS records point to a DNS provider where the zone no longer exists, whoever creates the zone there may be able to answer for your domain. This is called a lame delegation, and Infoblox ties it to what it calls Sitting Ducks attacks. Query each nameserver for the zone’s SOA. A REFUSED or SERVFAIL response, or an answer without the aa flag, means that server isn’t properly serving the zone.

Immediate Remediation

• Delete any CNAME pointing to an unallocated third-party resource. Confirm in logs or with the client that nothing legitimate depends on it.
• If the service is still needed, re-create the backend resource first, then point the record to it.
• Remove stale A/AAAA records that point to decommissioned IP addresses, since reassigned IPs can serve someone else’s content.
• Don’t import dead records into the new zone.

Phase 4: Re-Hosting & Cutover (Day 2 Onward)

Once the inventory is verified, move authoritative DNS to a provider your agency can manage, with proper access controls and an audit trail. Treat the provider’s SLA as a procurement factor. Route 53 advertises a 100% availability SLA, and Cloudflare provides an SLA on its Business and Enterprise plans but not on Free or Pro. An SLA is a service-credit commitment, not a guarantee that outages won’t happen.

Step 1: Lower Time-To-Live (TTL) Values

If you can still reach the old DNS provider, reduce TTLs on key records to 300 seconds at least one full old-TTL period before cutover. A common recommendation is 24–48 hours ahead. Lower TTLs mean record changes take effect faster.

Lowering your record TTLs does not speed up the nameserver switch itself. The delegation is cached according to the parent zone’s TTL, which for .com and .net is 172800 seconds (48 hours). Some large resolvers cap NS caching at lower values, but plan for the full window. If the former agency controls the DNS host and you can’t edit TTLs, you can still re-delegate, so plan for the slower switch.

Step 2: Stage the New Zone

At your new provider (for example Cloudflare, which assigns each zone its own pair of nameservers):

1. Create the zone and import records from your reconstructed BIND file, or enter them manually.
2. Decide proxy/CDN settings deliberately. Proxied records return the provider’s addresses, so differences in comparisons are expected. Leave mail-related hosts DNS-only.
3. Compare old and new answers for every name in your inventory, not just the apex:

# Compare record types between old and new authoritative servers
for t in A AAAA CNAME MX TXT SRV CAA; do
  echo "== $t =="
  diff <(dig @ns1.oldagency.com example.com $t +short | sort) \
       <(dig @<assigned-ns>.ns.cloudflare.com example.com $t +short | sort)
done

Step 3: Prepare CAA Records and Handle DNSSEC

CAA (Certification Authority Authorization). CAA records tell certificate authorities which of them may issue certificates for the domain. They are checked by CAs at issuance and don’t stop anyone who still has control of your DNS from editing them, so publish them after you’ve secured DNS control. Inventory every service that issues certificates for the client (hosting, CDN, SaaS custom domains) before restricting issuance:

example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 issue "digicert.com"
example.com. IN CAA 0 iodef "mailto:security@clientdomain.com"

DNSSEC. If the domain currently has a DS record at the registry, changing nameservers without handling it can make validating resolvers return SERVFAIL for the domain. The safe sequence is:

1. Remove the DS record at the registrar.
2. Wait at least the DS TTL. Many guides recommend 24–48 hours.
3. Change the nameservers.
4. Once the new zone is serving correctly, enable DNSSEC at the new provider and publish its new DS record at the registrar.

This matters more than it used to. Since 15 March 2026, certificate authorities must validate DNSSEC when it is present for CAA and domain-control lookups (CA/Browser Forum Ballot SC-085v2). A broken chain of trust can therefore block certificate issuance and renewal, not just resolution.

Certificate lifetimes are also shrinking. Under CA/Browser Forum Ballot SC-081v3, the maximum validity for publicly trusted TLS certificates fell to 200 days on 15 March 2026, drops to 100 days on 15 March 2027, and reaches 47 days on 15 March 2029. Domain-validation reuse shrinks on the same schedule. Any certificate renewed by hand is a future outage, so move to automated renewal as part of the handover.

Step 4: Cut Over Nameservers at the Registrar

1. Log in to the registrar portal and open the nameserver settings.
2. Replace all old nameservers with your new provider’s assigned set. Don’t mix old and new.
3. Query the TLD’s servers and public resolvers to confirm the new delegation is visible.
4. Test web, email (send and receive, then check SPF/DKIM/DMARC results in message headers), and certificate renewal.
5. Keep the old zone live and unchanged for at least 48–72 hours so resolvers still holding the old delegation get consistent answers. Then decommission it.

Phase 5: Client Communication & the “Handover Report”

Non-technical stakeholders often don’t see why an infrastructure audit takes time or costs money. A structured DNS Health & Audit Report turns the triage into a clear business outcome.

Executive Summary Template

Client: [Client Name]

Date: [Date]

Prepared By: [Your Agency Name]

Audit Status: [e.g., DNS control re-established and migrated]

1. Critical Risks Identified & Resolved (edit to match your findings)

- Security Risk: [e.g., CNAME records pointed to abandoned cloud resources, exposing the brand to subdomain hijacking.]

- Deliverability Risk: [e.g., SPF exceeded the 10-lookup limit; DKIM keys were missing or 1024-bit; no DMARC record was published.]

- Access Risk: [e.g., Registrar administrative rights were tied to former agency staff accounts.]

2. Actions Taken

- Reconstructed the zone configuration, comprising [X] records.

- Migrated authoritative DNS to [provider], which offers [SLA terms, if any].

- Enabled [MFA method] and registrar locks on the domain account.

- Published CAA records and aligned SPF/DKIM/DMARC email authentication.

3. Outstanding Items & Recommendations

- [e.g., Move DMARC from monitoring to enforcement after reviewing 30 days of reports.]

Master Checklist: Unmanaged DNS Rescue Audit

Use this checklist internally whenever you onboard a client with an abandoned or unmanaged DNS setup.

• Access & Authority
• Obtain written authority from the client
• Identify the registrar and authoritative nameservers (RDAP/WHOIS, dig)
• Confirm each listed nameserver answers authoritatively for the zone
• Reset administrative and recovery contacts to client-owned addresses
• Enable the strongest available MFA; remove SMS recovery
• Enable registrar locks (clientTransferProhibited and related)
• Confirm registrant-email verification is completed
• Zone File Reconstruction
• Request a zone export; attempt AXFR; import any BIND file
• Query active A, AAAA, CNAME, MX, TXT, SRV and CAA records
• Search certificate transparency logs (crt.sh) for hidden subdomains
• Pull historical records from passive DNS databases
• Check for delegated child zones and ACME validation records
• Email & Deliverability Hardening
• One SPF record, within the 10-lookup and 2-void-lookup limits
• Locate DKIM selectors from message headers and sending platforms; use 2048-bit keys
• Publish DMARC with aggregate (rua) reporting; plan the move to enforcement
• Vulnerability Remediation
• Scan for dangling CNAMEs pointing to unclaimed cloud hosts
• Check for lame delegations
• Remove stale A/AAAA records pointing to decommissioned IPs
• Leave dead records out of the new zone
• Migration
• Lower TTLs on the old zone to 300 seconds 24–48 hours ahead (if accessible)
• Stage the new zone and compare every name against the old servers
• Remove the DS record, wait out its TTL, then change nameservers
• Verify web, email and certificate renewal after cutover
• Re-enable DNSSEC with the new provider’s DS record
• Publish CAA records after DNS control is secured
• Keep the legacy zone live for 48–72 hours after cutover