Before selling email under your brand, follow the service as a new client would. Check the invitation, login, first message and route to support. A logo preview is useful, but it can't confirm a live domain or the permissions assigned to a real user.
Prepare a small client acceptance sheet
Use a test domain and record each step as pass, needs work or not applicable. Check the branded host is ready, the invitation names the right business, the client sees only assigned domains and replies reach the intended support contact. Check mailbox-password recovery separately from dashboard-password recovery. Record which messages remain TrekMail-branded rather than promising every message uses your brand. Leave billing and underlying platform references explicit. Only mark a step complete after checking it.
Define the service before adding your logo
First, decide what clients are buying. Is it just mailboxes, or also migration, phone setup, employee support, and domain management? Those jobs take different amounts of time, even when they are included in one monthly fee.
Write down the storage allowance, number of addresses, and process for adding users. Decide who handles lost access and delivery problems. If clients expect help with their email apps, include that in the agreed service too.
The TrekMail email plan determines account resources and features. White Label adds branding to the client experience. Price your own offer with both components and your support work in mind.
Set up what clients will see
White Label lets you set a brand name, logo, site icon, and colors. You can use your own addresses for webmail and the dashboard. Supported service messages, such as mailbox invitations, can also use the brand settings.
Check the path a new user takes: receiving the invitation, opening the link, signing in to webmail, and finding the support contact. An unfamiliar name or a link to a different dashboard can cause confusion at the first sign-in.
Every custom address needs the relevant domain setup and a ready secure connection. Saving a logo doesn't activate a new address. Follow the White Label setup guide.
Branded server names for Outlook and other email apps are configured separately. Do not include them in client instructions just because the branded webmail page already opens.
Give clients the access they need
Some clients only need working mailboxes. Others want to add employees and manage their addresses themselves. For the latter, provide a separate dashboard login and assign the domains they are allowed to manage.
Permissions should reflect the service agreement. If you support ten independent businesses, each administrator needs access to their own domains. Employees who only read and send email may not need an administrative dashboard at all.
The White Label user experience guide explains these different routes. Give each client a short guide with their links and support contacts. State what they can change themselves and which requests should come to you.
Keep the first acceptance exercise small
Use one client domain, one ordinary mailbox user and one person with a management role. Give each a different task. The mailbox user should open the invitation, find the right sign-in page, exchange a message and locate help. The client administrator should open the dashboard, identify the assigned domain and perform the action agreed in the service description. Avoid using the agency owner's active session to demonstrate client access.
Put the expected result beside each task. For an invitation, that could be a recognisable brand name and the correct destination. For a role check, it is the presence of the client's permitted resources and the absence of another client's resources. For recovery, identify whether you are checking mailbox access or dashboard access. These are separate checks even when the pages share your logo.
Use non-sensitive test correspondence. Keep a dated note of the configuration checked and any unresolved issue. If a step was only reviewed in the documentation, mark it as a documentation review rather than a successful live test. This makes the sheet useful when someone else needs to finish setup later.
Prepare for the support requests that branding creates
Employees may contact your agency when a phone stops sending, a password is forgotten or a mailbox fills up. Decide which requests your service includes and who can approve changes affecting other users. Publish a support contact that remains usable when the employee cannot open webmail. Do not make the mailbox being recovered the only place where recovery instructions can arrive.
Prepare a plain explanation for each entry point. The webmail address opens messages. The dashboard is for authorised administration. Mail apps use connection settings that must be supplied separately. Similar names do not mean these connections share the same setup or are ready at the same time.
Explain the boundary of your brand before a client discovers it during troubleshooting. Some platform names and infrastructure details remain visible. Supported branded messages do not imply that every billing message, technical header or diagnostic response is rewritten. Describe what the client will actually receive and keep the setup guide aligned with it.
Resolve exceptions before the second client arrives
A client may ask for a larger archive, an existing external sending provider or a separate commercial invoice. Review those as service requirements rather than cosmetic changes. Check the underlying account limits and supported configuration before including the request in your offer.
For anything still pending, write down who owns the next action and whether it blocks the client's normal work. A missing decorative asset and an unusable sign-in page have different effects. Finish the actions that affect access, permissions and message delivery before presenting the acceptance sheet as complete. The sheet should show what was verified, what is still open and who will help the first client after launch.
Agree on billing and responsibilities
TrekMail maintains one billing relationship with the account owner. Invoicing your clients, defining packages, and setting payment terms remain your responsibility. Branding does not automatically create separate subscriptions and invoices for every business you serve.
Your branding also does not hide every technical detail about the provider. Infrastructure information may still appear in DNS, message headers, and diagnostics. The guide to White Label's boundaries explains this. Tell clients what service you provide and what you are responsible for.
Start with one agreed client domain. That first setup will show which instructions employees need, what support requests arise, and how much time ongoing support takes. Use what you learn to define a repeatable offer for the next clients.