Do not ask clients to replace working mail-server settings until the branded names are ready. A webmail page that opens under your domain is a separate check. For a mail app, the hostname, certificate, port, encryption and sign-in details all have to fit together.
Decide when to stop the handover
Keep a simple checklist for the exact app and mailbox used in the pilot. If the branded host is not ready, the certificate does not match or a secure connection fails, keep the currently supplied working settings and investigate first. Do not tell users to ignore a certificate warning. Once ready, copy the full settings from Apps & devices in TrekMail, test receiving and replying, and only then distribute the same instructions to the intended group. Keep the support route available during the change.
What changes for the user?
IMAP lets an email app read messages and synchronize mailbox state. SMTP is used for sending. Email apps usually provide separate fields for these servers.
Branding changes the names people see in those settings. The mailbox, messages, and access rules continue to work in the same email system. Preparing a branded hostname doesn't create a new mailbox or separate infrastructure for each client.
A server address can use the agency's domain even when the user's email address belongs to their company. For example, maria@client.example might connect to imap.agency.example. That is a valid arrangement if those are the settings supplied for the mailbox.
Set up the brand domain
Branded mail-app hosts require an active White Label subscription. Saving a brand profile alone does not activate them.
Open the brand settings and enable your own domain for email apps. This is separate from branded dashboard and webmail pages. A working sign-in page doesn't mean IMAP and SMTP are ready to accept connections under the same brand.
The DNS section will show the required records. Copy them to the domain's active DNS zone and run the check. Use the names and destination values supplied by your current account configuration.
You also need a certificate for the server name. TLS, the technology used for a secure connection, lets an app verify the server and encrypt its communication. Simply pointing a name at another server does not solve the certificate requirement.
The branded mail hostname guide explains the Ready status and the move to new settings. Until the names are ready, the service shows working platform hostnames so users can connect without certificate errors.
Give clients all the connection settings
Once the names are ready, open Apps & devices for the mailbox. Copy the incoming and outgoing servers, ports, encryption modes, and password requirements. Send these details together. The name smtp.agency.example alone does not give an app everything it needs.
IMAP uses port 993 with SSL/TLS. SMTP supports 465 with SSL/TLS or 587 with STARTTLS. The username is the full email address. If the mailbox requires an app password, its ordinary webmail password will not be enough.
Set up one email client using your instructions. Test sign-in, receipt of a message, and sending a reply. Watch for certificate warnings and check the exact spelling of the hostnames. The email client settings reference can help you compare the values.
Write instructions that can be checked field by field
Prepare a connection sheet for one representative mailbox. Give the incoming server and its security settings their own row, and do the same for the outgoing server. Include the full-address username and the password type the mailbox requires. Keep the actual secret out of a widely shared document. An employee should be able to compare a field in their app with a field in the instructions without deciding what the agency meant by “use our mail server.”
State whether the instructions apply to a new account or to an existing configured account. For an existing account, identify the fields that change and the ones that remain as they are. Do not ask users to delete an established account with local messages as the first response to a server-name change. Review the app's settings and retained data before choosing a more disruptive step.
Use the exact advertised hostname in the pilot. A successful connection to a platform hostname is useful, but it does not verify the branded hostname. Likewise, a working incoming connection says nothing about the outgoing connection. Record both results against the host and port that were actually checked.
Treat a certificate warning as an unfinished step
A certificate warning can indicate that the name entered in the app does not match the name covered by the server's certificate. Compare spelling, check the intended hostname and return to the brand host's readiness status. Do not remove encryption or tell employees to accept an exception just to make the pilot appear successful.
If the branded configuration is still pending, retain the currently supplied working connection details. Explain that the brand hostname will be introduced after its checks pass. Clients can use a functioning mailbox while the branding work remains on the agency's task list; that is easier to support than distributing a name that works only when a warning is ignored.
Keep an external support contact in the handover. If the app cannot connect, the client needs a way to reach the agency without depending on the failing mailbox. Ask for the app name, server field, port and exact error text. They should not send their password in a support message.
Once the pilot succeeds, change a manageable group of devices and repeat the exchange from an outside mailbox. Review received sender details as well as the connection itself. This confirms the practical handover while keeping certificate readiness, mailbox authentication and outgoing delivery as separate recorded results.
Keep the hostname separate from the delivery route
The name smtp.agency.example does not, by itself, determine which provider delivers outgoing messages to recipients. That route depends on the domain's sending settings: built-in SMTP or a connected external service.
A branded hostname also does not mean you have a dedicated IP address or separate sender reputation. Do not promise better inbox placement just because the server name changes. Domain settings, authorized senders, and the condition of the selected sending route still matter.
If clients already have email apps configured, plan the transition in advance. Compare the old and new instructions, explain which fields change, and provide a way to ask for help. Roll out changes after testing one connection with the same settings users will receive.
