White Label DNS troubleshooting

Most White Label Lite DNS issues come down to one of four things: the record is missing, the record has a different value from the Branding table, a proxy is enabled, or the certificate step needs attention.

Start with DNS for your brand on the domain's Branding tab. It shows records that need attention first and is the source of truth for the hostname and target. Select Show records already working if you need to review a completed record. Do not copy a CNAME target from an older article, another account, or a DNS checker.

Fast route

1. Open Branding and copy the host, type, and value for the affected address.
2. Create or correct that record at the DNS provider that hosts the live DNS zone.
3. Keep the record DNS-only if the provider offers a proxy switch.
4. Return to Branding and select Check now. Share the address only when its status is Active.

Why SMTP may not appear in Branding

The SMTP record is part of the domain's normal setup and is already shown on DNS & Health. Branding does not repeat it when it is correct. Turning on Mail apps on your domain does not mean you need a second SMTP record.

If you need to review or repair SMTP, open DNS & Health for the same domain and follow the value shown there. If a related record breaks later, Branding may also surface it as an item that needs attention.

How to check DNS without a terminal

Before troubleshooting anything else, compare the record at your DNS provider with the row in Branding:

• Host or Name
• Type, which is CNAME for a branded dashboard or webmail host
• Value or Target
• Proxy setting, which must be off for a Cloudflare-branded host

Use Check now on Branding after you save the record. It queues a fresh check and the page shows the resulting status. When everything is ready, the same button reads Check again.

If you want an independent check, use a public DNS lookup service or ask your DNS provider to look up the full hostname as a CNAME. The answer must match the current Value field in Branding exactly. A public checker can confirm what it sees, but it cannot replace the platform's Active status.

You do not need a terminal to finish this setup. If you use one, query the full hostname and compare the returned CNAME with the value shown in Branding.

Status says "Pending DNS"

Pending DNS means the platform has not yet found the expected record for that host. Select Check now after you correct a record, then return to the Branding tab after the status updates. Work through these checks in order:

You edited the wrong DNS provider. Confirm which provider is authoritative for your domain's DNS. It is possible to edit a registrar panel while the live DNS zone is hosted elsewhere.

The CNAME target is not the current one. Copy the Value or Target from the Branding table. Remove an old conflicting record for the same hostname only after you verify that it is not used by another service.

The record type is wrong. A dashboard or webmail host needs the CNAME record displayed in Branding. An A or AAAA record at the same hostname can prevent the expected result.

The host name is entered in the wrong form. Some providers want only the prefix, such as dashboard; others want the complete hostname. Follow the provider's field hint and compare its resulting record with the host shown in Branding.

If the record matches, leave it in place and use Check now again. Repeatedly changing a correct record can extend the time before every DNS resolver sees the same answer.

Cloudflare orange-cloud breaks SSL provisioning

If you use Cloudflare as your DNS provider, you will see a cloud icon beside each record. An orange cloud means Cloudflare is proxying the request. A branded dashboard or webmail CNAME must be DNS-only so the platform can verify it and issue its certificate.

Fix: select the cloud beside the CNAME for the affected branded host until it is grey, then save the record. Return to Branding and select Check now.

This applies to the branded host record, not automatically to every other record on the domain. If another provider has a proxy or CDN switch, disable it for that CNAME unless the Branding table gives different instructions.

Status says "SSL could not be issued" and mentions CAA

A CAA record tells certificate providers which organisations may issue a certificate for your domain. Change it only when the Branding status or support specifically identifies CAA as the blocker.

Keep the CNAME unchanged and check whether the domain already has a CAA record. Your DNS provider can show it, or an independent DNS lookup can query the apex domain.

If the record needs to permit the platform's certificate issuer, add the exact CAA value supplied by support or shown in the current product guidance. Do not delete unrelated CAA entries simply to make this step pass. Multiple CAA records can coexist.

For the current certificate flow, the required value is normally:

Type: CAA
Host: @
Value: 0 issue "letsencrypt.org"

If you do not have CAA records, do not add one just as a precaution. Return to Branding and select Check now after making a CAA change.

Status says "SSL could not be issued" with no reason

The CNAME may already be correct. Do not delete and recreate it repeatedly. Instead:

1. Confirm the record still matches the host and target in Branding and is not proxied.
2. Select Check now once.
3. If the status remains unchanged, contact support with the hostname, the displayed status, and a screenshot of the DNS record.

Certificate work is not a change you can fix by editing an otherwise correct CNAME. The support team can review the platform-side result without asking you to expose DNS-provider credentials.

Domain was active, now status changed

Once a host is Active, it is ready to serve. If its status later changes:

• Back to "Pending DNS": compare the current CNAME with the Branding table. The record may have been changed, removed, or started using a proxy.
• "SSL could not be issued": leave a matching CNAME in place, select Check now, and contact support if the status persists.
• Off: check whether Branding was turned off for that domain or whether the White Label subscription is inactive. If neither explains it, contact support.

Common scenarios

"I changed my CNAME and the status is still pending." Confirm that you edited the authoritative DNS provider and that the new CNAME matches Branding exactly. Then use Check now. Avoid switching values back and forth while the check is in progress.

"I deleted the old CNAME at my old provider but the new one is not being found." If you switched DNS providers, make sure the registrar delegates the domain to the new provider's nameservers. Otherwise, ask the provider that hosts the authoritative DNS zone to confirm the record.

"My main site uses a proxy. Can the branded host use it too?" Keep the branded CNAME DNS-only. The rest of the domain can use its own proxy settings as long as the specific host in Branding is not proxied.

"Can I use a wildcard CNAME?" Configure the specific hostname shown in Branding. It gives the platform an unambiguous address to verify and test. Do not substitute a wildcard record for the host listed in the table.

"I want to use a different subdomain." Change the label in the domain's Branding tab, saving one host at a time. Copy the new CNAME from the table, test the new host only after it becomes Active, and keep the old customer address available until you complete the handoff.

"One network cannot see the new record." Test from another network or ask the affected customer to retry later. If the Branding table reports Active and the host works elsewhere, the remaining delay is likely in that network's DNS cache.

What's next

• Set up White Label Lite: the original setup steps if you're partway through.
• White Label Lite pricing FAQ: billing-related questions.
• Canceling White Label Lite: what happens to your domain if you cancel.
• Recommended DNS records: the broader picture of DNS records TrekMail uses.

If you are still stuck, open a support ticket with the hostname, the exact status from Branding, the DNS provider, and a screenshot of the record. Do not send DNS-provider passwords or API tokens.