Client Domain Handover Checklist for Agencies, MSPs, and Web Teams

A client domain handover checklist helps agencies transfer or confirm domain responsibility without losing registrar access, DNS visibility, SSL renewal context, email DNS records, or renewal accountability. Use it when onboarding a new client, taking over from another agency, launching a website, moving a client into a care plan, or offboarding a client.

Run a free 10-domain agency audit when you need portfolio-level visibility, use Health Check for one domain, and review the methodology page when explaining the limits of public domain, DNS, RDAP, and certificate checks.

Quick answer: client domain handover checklist

A client domain handover checklist should collect:

• Domain name.
• Registrar and account owner.
• Registrar access owner and MFA owner.
• DNS provider and nameservers.
• Key DNS records.
• Website host.
• SSL certificate and renewal context.
• Email provider and email DNS records.
• Renewal date and billing responsibility.
• Emergency contact.
• Handover notes and unresolved risks.

The checklist does not transfer the domain by itself. It helps the agency know what exists, who controls it, and what still needs action.

When to use this checklist

Use this checklist during:

• New-client onboarding.
• Website launch.
• Migration from an old host.
• Handover from a previous agency.
• Care-plan transition.
• Client offboarding.
• Registrar transfer planning.
• Domain expiry incident follow-up.

The best time to complete the checklist is before changes begin. The second-best time is immediately after discovering that access is unclear.

New-client onboarding

During onboarding, ask the client to identify all domains connected to their website, brand, redirects, landing pages, email, and campaigns. Do not assume the primary website domain is the only relevant domain.

Document:

• Production root domain.
• Common redirects and alternate domains.
• Registrar.
• DNS provider.
• Website host.
• Email provider.
• Renewal owner.
• Technical contact.
• Billing owner.

Then compare what the client believes with visible signals from public checks.

Old agency handover

When another agency is handing over responsibility, request more than a website backup. Domain handover should include registrar, DNS, SSL, email, and renewal context.

Ask for:

• Registrar name.
• Whether the domain is client-owned or agency-managed.
• DNS provider.
• Nameserver status.
• Key DNS record inventory.
• SSL renewal path.
• Email DNS records.
• Known verification TXT records.
• Renewal date and billing owner.
• Pending issues.

If the old agency cannot provide registrar access, determine whether the client can access the account directly.

Website migration

Website migration often focuses on files, database, and hosting. Domain handover adds the operational layer: DNS, SSL, redirects, email, and rollback.

Before changing DNS, document:

• Current nameservers.
• Current A, AAAA, CNAME, MX, TXT, and relevant CAA records.
• TTL values where relevant.
• Existing SSL certificate issuer and expiry.
• Email provider and required DNS records.
• Rollback owner.
• Client approval path.

Use DNS migration QA checklist for agencies when the handover includes nameserver or DNS changes.

Care-plan transition

When a client moves into a care plan, the agency needs ongoing visibility. The handover should define what the agency monitors and what remains with the client.

Clarify:

• Who tracks domain expiry.
• Who receives renewal notices.
• Who confirms registrar billing.
• Who manages DNS changes.
• Who owns SSL renewal.
• What appears in monthly proof reports.

The renewal ledger for agencies is useful when domain renewal sits beside hosting, SaaS, plugin, and contract renewals.

Registrar and ownership details

| Handover area | What to collect | Why it matters | Next action | |---|---|---|---| | Registrar | Provider where domain is registered | Determines renewal and transfer path | Confirm account owner | | Ownership | Client, agency, founder, prior vendor, or unknown | Avoids disputed control | Get client confirmation | | Registrar access | Admin users and MFA owner | Enables urgent action | Confirm current access | | Renewal date | Best known date and source | Prevents missed renewal | Add to renewal calendar | | Billing owner | Person/team responsible for payment | Avoids failed renewals | Confirm payment review owner | | DNS provider | Active nameserver operator | Determines record-control path | Inventory records | | SSL context | Certificate issuer and renewal path | Prevents launch and expiry issues | Add SSL review owner | | Email records | MX, SPF, DKIM, DMARC, related TXT | Protects email during migration | Confirm email platform owner |

DNS records and nameservers

DNS handover should capture both provider and records. Nameservers tell you where records are served. Records tell you what the domain is doing.

At minimum, inventory:

• Nameservers.
• A and AAAA records.
• CNAME records.
• MX records.
• SPF, DKIM, and DMARC records.
• Verification TXT records.
• CAA records if SSL issuance is relevant.

Use DNS record inventory for agencies for a deeper workflow.

SSL certificate and renewal context

SSL handover should answer:

• What certificate is currently served?
• When does it expire?
• Who renews it?
• Is renewal automated by host, CDN, or ACME client?
• Does DNS or CAA affect renewal?
• Who owns the fallback path?

If the handover includes SSL monitoring, use SSL monitoring Watchtower guide for agencies alongside the domain checklist.

Email DNS records

Email records can be damaged during domain handover. Record the current email provider and key records before changing nameservers.

Review:

• MX records.
• SPF TXT record.
• DKIM selectors.
• DMARC record.
• Verification records for Google, Microsoft, or other mail platforms.
• Any known sending services.

Do not promise deliverability outcomes from DNS records alone. The handover goal is to preserve configuration context.

Renewal date and billing responsibility

The handover should state who pays and who acts. A domain can be client-owned while the agency tracks the date. A domain can be agency-managed while the client pays. Ambiguity is the risk.

Add the date to a domain renewal calendar and record confidence level if public expiry data is limited.

Access, MFA, and emergency contact

Before accepting responsibility, confirm the emergency path:

• Client approver.
• Registrar admin.
• MFA owner.
• DNS admin.
• Agency technical owner.
• Account manager.
• Registrar support path.

If any role is unknown, mark it as a handover blocker or tracked risk.

Handover notes for the client

Give the client a plain-English summary:

• What domain was reviewed.
• Who owns the registrar account.
• Where DNS is hosted.
• Who receives renewal notices.
• What the agency monitors.
• What remains the client’s responsibility.
• What is unresolved.

Avoid blame. Handover notes should clarify responsibility, not assign fault.

Client domain handover checklist

• Confirm domain list.
• Confirm registrar.
• Confirm ownership position.
• Confirm registrar admin access.
• Confirm MFA and recovery owner.
• Confirm renewal date.
• Confirm billing responsibility.
• Confirm renewal notice recipients.
• Confirm DNS provider and nameservers.
• Export or document DNS records.
• Confirm website host.
• Confirm SSL renewal context.
• Confirm email provider and DNS records.
• Confirm emergency contact.
• Record unresolved risks.
• Confirm client-facing handover summary.

How CertPilot fits

CertPilot helps agencies track visible domain, DNS, SSL, and renewal-risk signals and produce client-ready proof reports. It does not transfer domains, change DNS records, manage registrar accounts, or replace handover documentation. Use Audit and Health Check to establish visible context, then complete private access and ownership steps manually.

Related Resources

• Domain Ownership Audit for Agencies
• Registrar Access Checklist for Agencies
• Domain Renewal Calendar for Agencies
• DNS Migration QA Checklist for Agencies
• Client Website Health Report Template

Frequently Asked Questions

What is a client domain handover checklist?

A client domain handover checklist is a structured list of ownership, registrar, DNS, SSL, email, renewal, and emergency-access details that should be confirmed when responsibility changes. It helps agencies avoid losing control of critical domain dependencies during onboarding, migration, care-plan transition, or offboarding.

Is domain handover the same as domain transfer?

No. Domain handover is an operational documentation and access process. Domain transfer is a registrar-level move from one registrar or account to another. A handover may include a transfer, but many handovers only clarify who owns the domain, who controls DNS, and who handles renewal.

What should agencies check before changing nameservers?

Agencies should inventory current DNS records, identify email provider records, confirm SSL dependencies, document TTLs where relevant, define rollback ownership, and confirm client approval. Nameserver changes can affect website routing, email, verification records, SSL validation, and third-party services.

Should email DNS records be part of the handover?

Yes. MX, SPF, DKIM, DMARC, and verification TXT records should be documented before migration or nameserver changes. Losing those records can affect email routing and authentication. The handover should preserve context even if the agency does not manage the mail platform.

Can CertPilot complete a domain handover automatically?

No. CertPilot can help with visible public checks and client-ready reporting, but it does not transfer domains, change DNS, log in to registrars, or manage registrar accounts. Agencies still need client approval, registrar access review, and internal handover notes.

What if the previous agency controls the domain?

Document the risk, ask the client to confirm ownership expectations, and request a formal handover path. Do not assume access will be available during an emergency. If transfer is needed, the client and registrar may need to be involved, depending on account ownership and registrar rules.