Connect domain DNS records: TXT, CNAME and the wait
Every website host on earth asks you to do the same small, slightly mysterious ritual before your own domain works: log into wherever you registered the domain, find a screen called something like DNS management or advanced DNS, and paste in a couple of records nobody quite explained. Click save. Click verify. Get told it isn't ready yet. Wait. Try again.
The two records, and why each one exists
A domain name is really one entry in a zone file, and a DNS record is one line in it: a name, a type, a value. Connecting a domain to a new host normally means adding two.
The ownership record (TXT) — a short text value your host generates, published at your domain purely so the host can look it up and know you control the DNS. Visitors never see it, and it routes nothing.
The routing record (CNAME) — points the domain's traffic at the host's edge. Once it resolves, requests for your domain arrive at servers that know which site to serve for it.
Why it hasn't worked yet
"Verify" failing on the first click is normal. DNS answers are cached aggressively — that caching is what makes the rest of the web fast — so a resolver that answered for your domain five minutes ago may keep serving the old, empty answer for a few minutes or, with a long TTL, the better part of a day. Nothing is broken. There is nothing to fix except patience and a re-check.
The apex-domain wrinkle (a bare domain, no "www")
Connecting a bare domain —
yourbusiness.com, no www — hits a genuine DNS rule, not a quirk of any host: a CNAME cannot coexist with the SOA and NS records that must live at a domain's root, so many registrars refuse to create one there at all. The usual ways out are an ALIAS/ANAME record where the registrar offers one, or connecting a subdomain and redirecting the apex to it.Connecting a domain, in order
1
Find your DNS settings
Log into wherever you manage the domain's DNS — that's your registrar, unless you've pointed the domain's nameservers somewhere else, in which case it's whoever hosts those instead.
2
Add the ownership record
Paste the TXT record exactly as shown, value included. Save it before moving on — some panels need a separate, explicit step to actually publish a pending change.
3
Add the routing record
Add the CNAME record — or, at a bare apex that rejects one, an ALIAS/ANAME record, or a redirect to a subdomain you're connecting instead.
4
Verify, then wait if you have to
Click verify. A "not yet" result on the first try is normal — recheck after a few minutes, and again after longer if your previous DNS setup used a long TTL.
How Olmira handles this
Adding a domain in Olmira's site settings generates both records for you, literally — the TXT at a name starting _aether-verify (a holdover from the platform's internal codename; only the value matters) and the CNAME pointing at edge.olmira.app. Verify runs a real, live DNS check with a short timeout, so "not verified yet" almost always means propagation, not a mistake — wait a few minutes and check again, rather than opening a support ticket.
A bare apex whose routing doesn't resolve falls back automatically to redirecting to a verified subdomain of the same site — or, failing that, to your free address — rather than serving an error. Once verification passes, HTTPS follows on its own: no certificate to buy or install. What each plan includes: custom domains.
How long, in seconds, a DNS answer is allowed to be cached before anyone has to ask again. A low TTL (say, 300 seconds) means changes show up fast; a high one (86,400 seconds — a full day) means they take longer, because resolvers are still confidently serving the old answer.
Not if you only touch what you're asked to. Connecting a domain to a website host only ever needs a TXT and a CNAME (or an ALIAS/A record at a bare apex) — your MX records, which control where email goes, are separate and untouched unless you edit them yourself.
Yes, and it sidesteps the apex wrinkle entirely — shop.yourbusiness.com or www.yourbusiness.com can take a CNAME with no special handling.
Almost always a long TTL left over from whatever used to occupy that name — a parked-domain page from your registrar, or a previous host. The fix is only ever patience the first time; once the old TTL expires, future changes at that name resolve much faster.
No — DNS records don't expire on their own the way certificates do. Once they're published correctly, they stay correct until you or someone with access to the DNS panel changes them.