No Credit Card Required
Printed from checkflow.io/templates/managed-services/white-label-reseller-account-setup-checklist
Reselling a platform under your own brand only works if every client account is set up completely, every time. The work is unglamorous: a DNS record on the right hostname, a certificate that renews itself, notification email that passes authentication, branding with no trace of the vendor, a template library, user roles, and a test from the client’s side before anyone is invited. Miss one and the client either sees the vendor’s name or sees something broken, and both cost you credibility in the first week. This free white-label reseller account setup checklist gives your platform team one repeatable way to provision each new client account, from the commercial setup in the reseller console to a signed-off go-live. It is written for resellers, MSPs and agencies running a white-label platform for several clients. A conditional phase handles clients who want the platform on their own domain, so it appears only when it is needed.
Resellers often run two processes as one, and the client pays for the confusion. Account setup is internal and technical: the tenant, the hostname, the certificate, the sending domain, the branding and the roles. Nobody at the client should see it happening, apart from the one person who has to add a DNS record. Client onboarding is what the client experiences: a kick-off, workshops, configured processes, training and an adoption review.
Keep them separate and finish setup first. If you invite users before the certificate has issued or before notification email passes authentication, their first impression is a browser warning or a missing email, and the onboarding lead spends the kick-off apologising. This checklist ends where the White-Label Client Onboarding Checklist begins, and its last task starts that checklist. If you are still choosing a platform to resell, the guide to choosing white-label software covers what to ask a vendor before you sign.
Covers: tenant, DNS, certificate, email authentication, branding, templates, roles.
Done when: a test user outside your network can use the account and sees only your brand.
Risk if missed: the vendor’s name, a certificate error or lost notifications.
Covers: kick-off, process configuration, sign-off, training, adoption.
Done when: the client’s people run their processes on the platform.
Risk if missed: a configured account nobody uses.
Seven phases take a new client account from signed order to approved go-live. Phase 3 appears only when the client wants the platform on its own domain.
Answer the domain question here. It decides whether Phase 3 runs and whose DNS you need.
The certificate must renew without anyone touching it. Publicly trusted TLS certificates are limited to 200 days from March 2026, falling to 47 days by March 2029.
Shown only when the client wants the platform on its own domain. Conditional logic removes it for clients on your subdomain.
Notifications that fail authentication land in spam or never arrive. Agree the sending domain before you touch DNS.
Most of the technical risk in white-label setup sits in a handful of DNS records. The vendor supplies the exact values. Your job is to put each one in the right zone, on the right name, and to check it worked. Lower the record’s TTL a day before any change you might need to reverse, and keep a copy of every record in the client’s documentation.
| Record | Where it lives | What it does | Common failure |
|---|---|---|---|
| CNAME for the hostname | Your zone, or the client’s for its own domain | Points the branded hostname at the vendor’s platform | Placed on the bare domain, or on a name that already has other records |
| TXT for verification | The zone that owns the hostname | Proves to the vendor that you control the domain | Left in place after a client leaves, or never added |
| CAA | The client’s zone, if it uses CAA | Limits which certificate authorities may issue for the domain | The vendor’s certificate authority is not listed, so issuance fails |
| SPF (TXT) | The sending domain | Lists the servers allowed to send its mail | A second SPF record, or more than 10 DNS lookups |
| DKIM (CNAME or TXT) | The sending domain | Publishes the key that verifies the mail signature | Mail signed with the vendor’s domain, so DMARC alignment fails |
| DMARC (TXT) | _dmarc on the sending domain | States the policy for mail that fails and where reports go | No reporting address, so nobody sees failures |
The account looks finished in the admin console long before it looks finished to the client. Check these from the client’s side before you approve go-live:
Email deserves a second look as the client grows. Google expects every sender to use SPF or DKIM, and senders of around 5,000 or more messages a day to personal Gmail accounts must also publish DMARC with alignment. Messages from the same primary domain count towards that total, so platform notifications sent from a client’s domain add to its own mail.
Build the setup once and launch it for each new client with the tenant, hostname and go-live date filled in. Conditional logic adds the own-domain phase only when the client asks for one, so the platform team never works from the wrong version.
Share the DNS tasks with the client’s technical contact through a link that opens without an account or a login, showing your logo, your company name and your own subdomain. Add a password and an expiry date, and watch the task close when the record goes in.
The go-live task is an approval. Until the service manager marks it approved, the handover to onboarding stays locked, and the record shows who approved which account, when, and what the end-to-end test found.
Resellers usually standardise account setup alongside the rest of their client delivery. See how CheckFlow’s white-label features put your logo and subdomain on every checklist you share, and how branded shared checklists let clients complete their steps without an account.
Notification email is the step most likely to fail quietly. The Email Authentication (SPF, DKIM, DMARC) Setup Checklist covers the records in depth, and the White-Label Client Onboarding Checklist takes over once the account is approved.
White-Label Client Onboarding Checklist
Email Authentication (SPF, DKIM, DMARC) Setup Checklist
MSP Client Onboarding Checklist
Customer Onboarding for SaaS Companies
New Software Implementation Checklist
Describe the process in a sentence and the AI checklist generator drafts the phases and tasks for you.
Creating the client’s tenant in your reseller console, putting it on a branded hostname with a working certificate, authenticating the notification email, applying your branding, loading your template library, creating users and roles, and testing it from the client’s side. It is internal work. The client should notice only the DNS request, if they use their own domain, and an account that works the first time they open it.
A subdomain of yours, such as clientname.yourbrand.com, is quicker and keeps the DNS in your hands, so setup needs nothing from the client. The client’s own domain looks more native to their users, but it needs their DNS contact, adds a certificate dependency on their CAA records and makes offboarding a joint task. Many resellers default to their own subdomain and offer the client’s domain on higher plans.
The usual causes are a DNS record that has not propagated or was added to the wrong name, a CNAME placed on the bare domain or on a name that already has other records, and CAA records that do not list the certificate authority the vendor uses. A certificate authority must check CAA before it issues, so ask the client’s contact for their CAA records before you send the DNS request.
Yes, in practice. Google expects every sender to use SPF or DKIM, and larger senders must also publish DMARC with the From domain aligned. Mail that fails is likely to be marked as spam or rejected, and a client who never receives task notifications will assume the platform does not work. A dedicated sending subdomain keeps platform mail separate from the domain’s other email.
On your own subdomain, often less than a day of work, most of it testing. On the client’s own domain, allow several working days, because you are waiting on their DNS contact and on propagation. Agree a go-live date that leaves time for the end-to-end test, and don’t book the client’s kick-off until the account has been approved.
CheckFlow’s Business plan lets you share checklists under your own brand: your logo, company name, website link and favicon, on your own subdomain such as yourcompany.checkflow.io. Clients open shared checklists without an account or login, and each link can carry a password and an expiry date. See the white-label features for the details.
14-day free trial, no card required. The Business plan is $10 per user per month after the trial. Full details at checkflow.io/pricing.
14-day free trial, no credit cardFull refund in your first 30 daysUS hosting, EU on request
