Use an invitation

Before access is granted

• Identify the exact site, hosting project, registrar, DNS zone and requested change. Confirm who can authorize each account.
• Use a dedicated FTS collaborator invitation where the provider supports it. Keep the owner login with the client, and grant only the project permissions needed for the work.
• Keep account recovery and ownership with the client. Enable multifactor authentication through the provider’s own secure interface.
• If a scoped invitation is unavailable, pause and agree a safer provider-supported route or a client-performed change. Do not default to emailing a password.

Keep credentials out of the brief

Do not send email passwords, hosting passwords, API secrets, recovery codes, card details or one-time verification codes through an FTS form or ordinary email. This site does not provide a general secret-transfer inbox.

Use invitations for normal access. If a narrowly scoped token is genuinely necessary later, agree a secure transfer and storage method, minimal permissions and revocation timing first. Public site files must not contain secrets.

The domain stays with you

Keep your domain registered in your own name and registrar account, including when FTS hosts the site. You keep renewal responsibility, recovery access and the ability to move the domain.

For optional managed care, the website project would live in FTS’s Cloudflare account. FTS controls that project and deployment, while you own the domain and transferable paid-for site files. Clients are not given the shared master account.

For client-owned hosting, invite FTS only to the supported project needed for the agreed build or change. Revoke that access after handover unless an ongoing agreement requires it.

Check email before changing DNS

1. Record the current setup. Inventory the domain, current nameservers and all relevant DNS records, including MX, SPF, DKIM, DMARC and verification or other service records.
2. Choose the narrowest change. Review whether a www record is enough or an apex setup requires moving the DNS zone to the managed Cloudflare account. Get approval before changing nameservers.
3. Prepare rollback. Save the prior configuration and agree how to restore it. Moving DNS does not create or move an email mailbox.
4. Check the result. Verify the website, HTTPS, redirects and mail routing; confirm relevant records and test sending and receiving with the owner after the change.

Do not delete unfamiliar records to tidy the zone. Identify the service and owner first. Cloudflare hosting or DNS does not include a mailbox.

When care ends

At offboarding, agree the destination, migration window and cutoff before disabling hosting. Export the transferable paid-for source, assets and relevant configuration, plus deployment and DNS notes. Do not include shared-account secrets or other clients’ data.

Confirm the replacement site and domain routing, then remove provider invitations and revoke or rotate temporary tokens. Record who now handles hosting, renewals and backups.

Notice mechanics, backup retention and any extra migration work remain subject to the written agreement. The care policy does not authorize immediate deletion after a failed payment.

Review the cancellation and export policy