Your email address and your browser sign-in address do different jobs. An employee can keep anna@studio.example while opening webmail at mail.studio.example. Before handing out a new link, decide which URL is for reading mail and which is for administering the service.
Write a two-link handover note
Put the webmail link beside a plain explanation: use this to read and send email. If someone also manages users, list the dashboard link separately with that responsibility. Check each link in a fresh browser window after its branded host is ready. Include an alternative support contact for someone unable to sign in. Changing a browser URL does not automatically change an employee’s address, password or IMAP/SMTP settings; communicate only the changes you have actually configured.
Choose an easy sign-in address
Webmail often uses a subdomain such as mail or webmail. Choose something easy to say over the phone and include in employee instructions. Check that another system is not already using the name.
If mail.studio.example points to an older email service, changing the record affects people who still open it from a bookmark. Plan that transition first, or choose an unused name. The domain in people's email addresses can stay the same.
The administrative dashboard may use a different address, such as dashboard.studio.example. Label these links separately in staff instructions. Someone who needs to read a message usually only needs webmail; the management dashboard is for people who administer domains and users.
Add the address to your brand settings
In TrekMail, open the relevant domain's brand settings. Enter your company name, upload a logo, and set the webmail address. If several projects share a style, decide which settings they will inherit and where separate branding is needed.
White Label is activated separately from the email plan. Saving the design or seeing a preview doesn't mean the new address is serving webmail yet. Activation, domain setup, and the secure connection all need to be ready for sign-in to work.
Follow the White Label setup guide. Copy DNS values from your own account. Do not use a destination address from someone else's screenshot, because those records belong to their setup.
Wait for DNS and the certificate to be ready
DNS connects your chosen name to the service. The certificate lets a browser establish a secure connection for that exact name. Both must be ready before you send employees the new link.
After changing DNS, run the check in the dashboard. If the record is not found, compare its name, type, and value. Sometimes a record is added at the registrar even though another provider hosts the active DNS zone. The change will not work until it is made in the right place.
When the host is ready, open it in a browser and check the address bar. Do not bypass a certificate warning and consider the setup finished. Return to the host status and domain settings.
This setup covers webmail. Custom server names for Outlook or Apple Mail have separate settings. A working mail.studio.example page does not confirm that imap.studio.example is ready.
Explain the three names people may confuse
Start the announcement with the employee's existing email address and the new browser link on separate lines. For example, anna@studio.example is where customers write, while mail.studio.example is where Anna opens a browser. A third name may appear in an email app's incoming or outgoing server settings. Do not ask employees to replace all three simply because one has changed.
A useful handover says what the person should do next: open the webmail link, sign in with the mailbox credentials and update the bookmark after the check succeeds. If the mailbox address and password stay the same, say so in the announcement. If another change is required, describe that change separately and use the appropriate secure delivery process for credentials.
For administrators, add the dashboard link under a clear management label. Keep it out of the ordinary employee's instructions if they have no management responsibilities. Too many unexplained links can send people to the wrong screen and make a working mailbox look inaccessible.
Plan the change for existing bookmarks
Before reusing an old webmail hostname, find out who still opens it and which service currently answers there. A domain owner may remember the new link while a part-time employee still uses a saved bookmark from several years ago. Set a change window and make sure help is available when those employees next sign in.
Avoid printing the proposed URL in permanent employee materials while its setup is still pending. You can prepare the wording in advance, but distribute it after checking the live host and secure connection. A preview in an administration panel is evidence of a saved design, not evidence that a fresh browser can reach the chosen hostname.
If the address fails to open, check the exact host and its setup status before asking everyone to reset passwords. A DNS or certificate problem occurs before mailbox authentication. Record the browser's hostname and error without collecting the employee's password. This helps the responsible administrator distinguish an unavailable entry page from a sign-in problem.
Make support usable outside webmail
Put an alternative contact in the handover, such as a help page or another agreed channel. It should be possible to report an inaccessible mailbox without first signing in to that mailbox. State who handles the problem: your company's administrator or the agency providing the service.
Check the help instructions on a phone as well as a computer. The link should be easy to select, the organisation should be recognisable and the employee should know which address belongs in the username field. If a client uses more than one branded domain, verify that its instructions lead to the intended experience for that domain. Do not infer this from another client's successful login.
Keep one maintained copy of the instructions and record who updates it. When a future branding change happens, staff should be able to find the current entry point without searching through several contradictory welcome messages.
Try the sign-in process as an employee
Open the new address in a separate browser window and sign in to an existing mailbox. Check the logo, company name, small-screen layout, and support contact. Send a test message and confirm that you are using the expected mailbox.
If new users receive invitations, test that process too. They should understand who sent the message, which link to open, and where to get help with sign-in. The client interface guide describes the supported options.
Once you have checked everything, update the team's instructions and bookmarks. Give employees the new sign-in address and explain whether their usual steps have changed. There is no need to include passwords in that announcement. Provide a separate support contact for anyone who can't open email, so getting help does not depend on access to the mailbox itself.
