Documentation 9.6.24
Custom domain
Use the DNS target shown for your own website. Do not copy another customer’s hostname, IP address or verification value.
Set the DNS record#
Add your hostname in the available domain settings, then create the record shown by the panel at your DNS provider. Avoid conflicting records. DNS changes can take time; recheck the actual result rather than assuming a fixed propagation delay. Also add the mandatory ownership TXT record at _tosun-verify.YOUR_DOMAIN with the complete verification value shown in the panel. Routing DNS alone does not prove ownership.
Verify DNS and HTTPS#
Run the available verification action and check the displayed DNS and certificate status. A saved hostname is not confirmation that HTTPS is ready. Keep using the working site address until verification and certificate setup have completed.
Identify the website and DNS zone#
A custom domain opens your account’s primary active website. Confirm that this is the intended site and that its existing working address opens first. You must control the domain’s DNS zone or work with the person authorized to manage it.
For a safe example, use community.example.com and save your own hostname in the panel. The service managing DNS may differ from the company where the domain was purchased. Change records in the DNS service the domain actually uses; editing an unrelated zone cannot satisfy verification.
Routing and ownership are separate checks. A CNAME or A record identifies the traffic destination, while the mandatory TXT record proves control for your account. Copy the exact names and values displayed. Do not reuse another account’s verification token or an IP from an older installation.
Create records using the displayed values#
The panel’s target belongs to the current installation. Use its values instead of a fixed IP or guessed verification string. During initial verification, use direct DNS routing rather than a proxy.
- For a subdomain, add a CNAME pointing to the displayed target. If your provider requests only a short record name, enter the relevant hostname part without adding the domain twice.
- For an apex domain or a name where CNAME is unavailable, use the alternative A record shown in the panel. Check for conflicting routing records at that name.
- Add TXT at the full name _tosun-verify.YOUR_DOMAIN and paste the complete displayed value. Do not rewrite either the name or value.
- Save the changes, then use Verify DNS and prepare HTTPS. DNS propagation varies by provider; do not assume a fixed completion time.
Example hostname: community.example.com
Full TXT name: _tosun-verify.community.example.com
TXT value: the value displayed for this account in the panelWait for the separate HTTPS result#
After DNS and ownership verification succeed, certificate preparation is queued in the background. Saved or verified is not the same as HTTPS active. Check for Active · HTTPS on the page, and keep using the existing working site address during preparation.
For a missing TXT error, inspect the record name, complete value and actual DNS zone. For a routing error, check the CNAME/A target and conflicting records. A DNS-changed error warrants checking whether records changed during preparation. Observe any retry wait displayed on the page.
If an earlier hostname is still being cleaned up, follow that status instead of starting the operation repeatedly. If unresolved, send support the domain, site ID, error time and error text with the verification token removed. An AC license or MySQL password is not needed to describe a certificate problem.
Keep the records after activation#
Open the custom address in another browser session and verify the correct website and HTTPS connection. Keep the CNAME/A and TXT records after the first successful check; later verification still uses them.
- The custom address opens the intended primary active website.
- The panel reports HTTPS active and the browser uses the expected hostname.
- Routing and ownership TXT records remain in place.
- Changes to the domain or DNS provider are verified again with the current values.
Plan a domain transition while retaining a working address#
First confirm the default website address works and that the primary active site is the one your custom domain should open. Keep a private note of the current domain, routing target and TXT information shown by the panel. When moving DNS providers, transfer the ownership TXT record as well as A/CNAME records without removing records used by other services.
Changing to a different custom domain requires removal of the existing address and completion of background cleanup. Do not force a new request while cleanup is pending; use the working default address. Check the plan entitlement and subscription status. Acceptance means the new name opens the correct active website over HTTPS and the panel confirms it, rather than merely saving a form.
Identify which DNS check failed#
For a missing TXT record, compare its name with the complete domain. A DNS provider that adds the zone suffix automatically can accidentally produce the domain twice. Check for a truncated value, a token from another account or edits made in the wrong DNS zone. Repeatedly sending an old value after changing records does not solve verification.
For routing failures, use the CNAME/A target displayed in the panel. Inspect conflicting records at the same name and proxy settings that hide direct routing. Even when records look correct in one place, other queries can still return older answers. Allow propagation and observe the retry delay shown by the panel. Loading the page on your own computer does not prove ownership verification or certificate provisioning has completed.
Check certificate preparation and later renewal#
If DNS verification succeeds but HTTPS remains pending, retain routing and TXT records. Changing them during setup can invalidate the job. Read the panel explanation for setup failure or changed DNS and follow its retry delay. Cleanup of an old address and verification for a new certificate are separate operations.
After activation, check the expected browser address and correct site content; monitor the stored certificate expiry when displayed. Repeat these checks after changing DNS provider, proxy configuration or domain. For support, share the domain, site ID, error time and sanitized status message. Publishing a TXT token, AC license or database password is not a remedy for an HTTPS issue.
Check the scope of the root and www addresses#
example.com and www.example.com are different names: one is the root domain and the other a subdomain. Use the exact name saved in the panel. One working does not establish automatic routing or certificate coverage for the other. Decide which community address you will share. Example domains in documentation are not your DNS values; read the actual name and target from the panel.
Check whether your DNS provider expects the complete hostname or only a subdomain in its name field. A record prepared for www is not a root-domain record. The ownership TXT name also includes the selected address; copy the full _tosun-verify. name as shown. Moving values between similar names can place verification at the wrong location.
Open the saved HTTPS address and read the final browser address. Confirm the intended community appears. If another variant is needed, clarify its supported scope with support while keeping existing records. Do not assume one record covers every subdomain or that the panel automatically redirects www.
Keep a DNS maintenance record without disrupting services#
After verification, keep DNS changes traceable. Your maintenance note can include the hostname, routing type, target, ownership TXT name and change time. Exclude provider passwords and login codes. Before editing, distinguish website records from email and other services; moving a website does not require deleting the whole DNS zone.
When changing DNS providers, plan to preserve website routing and the required TXT record. Compare old and new values and avoid conflicting routing records at the same name. A save message in the provider account does not prove external verification is complete. Check panel verification and HTTPS status separately without promising a fixed waiting time.
For support, describe the changed record type, name, time and panel message. Account access and unrelated customer records are unnecessary. This history allows comparison with the last working address. Investigate the relevant routing or ownership stage instead of randomly replacing every record.