Use this guide when a custom domain does not become ready, opens the wrong website, redirects incorrectly, or shows an HTTPS/security error.

Find your issue first

Use the symptom table before changing DNS. Start with the section that matches what you see, make one targeted change, and then recheck the domain status and the hostname in a browser.

Where to check the domain

Quick reference: Terms you may see using this guide

You do not need to understand DNS internally to use the troubleshooting steps. These definitions are only here when a term is unfamiliar.

Before you change anything

• Record the exact Domain Status and any error message shown in Atoms.

• Change one DNS or routing setting at a time so you can tell which change affected the result.

• Record the previous value before editing a production DNS record.

• Do not delete records merely because you do not recognize them. MX records, mail-related TXT records, and unrelated subdomains may support email or other services.

• Do not change nameservers just to fix a single verification problem unless a separate DNS migration is intended and confirmed.

• If a troubleshooting change breaks a working website, email, or another service, restore only the last change that caused the regression.

Verification and DNS record problems

Use this section when Atoms cannot verify the domain, a required record appears missing or incorrect, or you edited DNS but the domain state did not change.

Check the source DNS first

• Open the domain in Atoms and compare every required record with what is publicly published for the same hostname.

• Check the domain’s authoritative nameservers and make sure you are editing DNS at the provider serving those nameservers. If the nameservers point to Cloudflare, changes made only in a registrar DNS panel may not be authoritative.

• For each required record, confirm the record type, hostname/name, target or value, and that the record actually exists at the authoritative provider.

• The verification value must exactly match the value currently shown by Atoms and must be visible in a public DNS lookup.

Fix only the mismatch, then recheck

• Create a missing record or correct only the field that does not match.

• If the record was added at the wrong DNS provider, add it at the authoritative provider instead.

• Do not replace a current Atoms value with an address or verification value from another project, another domain, an old screenshot, or an older Help Center article.

• After the change is public, return to Domains → Manage, recheck the Domain Status, and then test the hostname in a browser.

Routing, old content, conflicting records, and Cloudflare

Use this section when the hostname opens an old website, reaches the wrong destination, or has multiple routing records for the same hostname.

Check A, AAAA, and CNAME records for the exact hostname

• Look for records from a previous hosting provider, an old IPv6 AAAA destination, a CNAME plus another destination record for the same hostname, or duplicate records that send traffic to different services.

• Remove only a website-routing record that you have confirmed conflicts with the current Atoms setup. Do not delete unknown records as a cleanup step.

• If DNS already points to the intended destination but old content appears, test a private/incognito window, another browser or device, and another network before changing DNS again.

Cloudflare proxy status

• TXT verification records are DNS-only; they are not web-proxy records.

• For A or CNAME records, change Proxy Status only when the Atoms interface or Atoms Support specifically requires it. Do not switch records between Proxied and DNS only as a routine troubleshooting step.

• If Atoms or Support asks you to change the proxy status, change only the named routing record, wait for the new DNS response to become visible, and then retest the domain and HTTPS.

DNS propagation and local caching

If authoritative DNS is already correct but different networks or devices still show different results, the remaining issue is usually caching rather than a new configuration error.

• Compare the authoritative DNS result with one or more public DNS resolvers and, if useful, another network such as mobile data.

• If authoritative DNS is wrong, correct the source record. If authoritative DNS is correct but other resolvers still return the previous value, avoid repeatedly editing the record.

• DNS changes may take up to 48 hours to become visible globally, although they usually appear sooner.

• If only one browser or device shows the wrong result while DNS and Atoms are correct elsewhere, clear or bypass that local browser/network cache. Do not change DNS for a device-specific cache problem.

• Recheck later and look for public resolvers to converge on the same intended value.

SSL / HTTPS problems

Use this section when DNS looks correct but HTTPS cannot be issued, the browser shows a certificate warning, or HTTPS worked previously and now fails.

Check the configuration around the certificate

• Record the exact browser error and the exact hostname being opened.

• Confirm DNS routing, propagation, Cloudflare proxy status, and whether the certificate appears to belong to a different hostname.

• Check whether anything recently changed in DNS, nameservers, Cloudflare proxy settings, CAA records, or the project/domain association.

• Check CAA records on the affected hostname and parent domain if a restrictive certificate policy may be present.

Fix and verify

• Correct only a confirmed DNS, proxy, CAA, hostname, or project-association problem.

• Do not bypass browser certificate warnings as a normal solution.

• If public DNS is correct and no user-controlled configuration explains the failure, stop changing DNS and contact Atoms Support for certificate provisioning or renewal.

• Do not replace otherwise-correct DNS merely to force certificate renewal unless Atoms specifically instructs you to do so.

• Recheck by opening the exact hostname with https:// and confirming that the intended project loads without a certificate warning.

Root, www, redirects, and wrong-project behavior

These issues are worth checking here because they can look like DNS or SSL failures even when the basic connection is already working.

Root works but www does not — or the reverse

• Treat example.com and www.example.com as separate hostnames. Test both over HTTPS.

• Check the DNS result and Atoms Domain Status for the hostname that fails.

• Do not assume the root-domain values should simply be copied to www.

If a hostname still needs to be connected or reconfigured, follow the setup steps in Connect and Manage Domains rather than duplicating the configuration procedure here.

Redirects go to the wrong address or loop

• Confirm the address you expect visitors to end on and test the redirect in a fresh/private browser session.

• Check whether another system is also performing redirects, such as registrar forwarding, Cloudflare redirect rules, another proxy/CDN, or the previous hosting platform.

• Change only the confirmed conflicting redirect layer. Avoid changing several redirect systems at the same time.

• If a change creates a redirect loop or sends visitors to the wrong destination, restore the previous working redirect configuration before testing another layer.

To change which connected address is primary, use the procedure in Connect and Manage Domains.

The domain opens the wrong Atoms project

• If DNS already reaches Atoms correctly, treat the problem as a project/domain association issue rather than repeatedly changing DNS.

• Confirm which project or workspace currently shows the domain association.

• After the association is corrected, recheck that the hostname opens the intended project and that HTTPS still works.

For switching, disconnecting, reconnecting, or moving a domain between projects, follow Connect and Manage Domains. If the current association belongs to an inaccessible or deleted project/workspace/account, contact Atoms Support instead of making additional DNS changes.

When to stop changing DNS and contact Atoms Support

Escalate instead of continuing to edit DNS when the evidence points to an Atoms-side state, certificate, or association problem.

• DNS is confirmed correct but the Atoms domain state does not recover.

• Certificate provisioning or renewal fails even though public DNS and user-controlled settings are correct.

• The domain is associated with an inaccessible or deleted project/workspace/account, or the relevant domain-management action fails.

• Several unrelated Atoms domains fail at the same time and their DNS records have not recently changed.

• A troubleshooting change affects another service and you cannot safely identify the correct rollback.

Prepare this evidence before escalating

• The affected hostname and the intended Atoms project/workspace.

• The exact Domain Status or error message currently shown.

• The current authoritative DNS results and the values Atoms currently requires.

• The browser’s exact HTTPS/certificate error, if applicable.

• The last change made and whether restoring it returned the previous behavior.

Final recheck

After any fix, return to Domains → Manage and recheck the Domain Status. Then confirm the result in a browser.

• The intended hostname is connected and reaches the intended Atoms project.

• HTTPS works without a certificate warning.

• Root and www behave as intended.

• Redirects end at the intended address.

• Email and other unrelated services still work after the DNS changes.

FAQ