What CNAME does Tistory want, and where do I point it?

Point your subdomain — usually www, but blog or any label works — at host.tistory.io as a CNAME record. That's the whole DNS side for a subdomain. Some DNS panels want a trailing dot (host.tistory.io.); most add it for you. Set this record in your DNS provider's panel first, then go into Tistory and connect the domain — not the other way around. If you connect in Tistory before the CNAME exists and propagates, Tistory can't verify it and the connection stalls.

Can I connect my root domain (example.com) instead of www?

Only if your DNS provider supports CNAME flattening — ALIAS or ANAME records. A root (apex) domain can't hold a plain CNAME: RFC 1034 forbids a CNAME coexisting with the SOA and NS records that every zone apex must carry. That's a DNS rule, not a Tistory limit. Providers like Cloudflare, Route 53 (Alias), and DNSEver (ANAME) fake a CNAME at the apex and let you point example.com at host.tistory.io. Without that feature, connect www.example.com and redirect the bare root to it.

I connected the domain but HTTPS shows a certificate error. Why?

Tistory issues a certificate for the exact hostname you entered — and only that one. If you connected www.example.com, then example.com has no valid certificate, and vice versa. Whichever form you didn't register throws a certificate warning. The fix isn't a second Tistory connection; it's a 301 redirect (at your DNS/CDN layer, e.g. Cloudflare) that funnels every visitor to the single form you did connect. Also give issuance time — Tistory provisions the certificate automatically after the domain verifies, and it isn't instant.

Tistory Custom Domain Setup: CNAME, apex & HTTPS

Problem

You pointed your domain at Tistory, and something’s off: the blog still shows its *.tistory.com address, the browser throws a certificate warning, or Tistory’s admin page keeps saying it can’t verify the domain. The DNS record looks right to you. It usually is — the trouble is almost always which name you connected and when you connected it, not a typo in the record itself.

Symptoms

Tistory’s 개인 도메인 설정 (personal domain) screen shows “cannot read domain settings” and won’t flip to verified.
The domain resolves, but the browser warns the certificate doesn’t match — often only on www or only on the bare root, not both.
Visitors landing on example.com get an error while www.example.com works (or the reverse).
Everything looked fine for weeks, then HTTPS suddenly broke on its own.

How Tistory’s Custom Domain Actually Works

Two moving parts, and people conflate them.

The DNS side is a single CNAME: your hostname → host.tistory.io. That record tells the world’s resolvers “traffic for this name goes to Tistory’s front door.” It lives in your DNS provider’s panel — the registrar or DNS host where your nameservers point — not inside Tistory.

The Tistory side is a connection you make in 관리 → 블로그 → 개인 도메인 설정 (Admin → Blog → Personal domain), where you type the exact domain and Tistory verifies that the CNAME already points to it. Once it verifies, Tistory provisions an HTTPS certificate for that hostname automatically. You never touch certificate files.

The ordering matters and trips up most people: DNS first, Tistory second. Tistory verifies against a record that has to already exist and have propagated. Connect in Tistory before the CNAME is live and it just can’t see anything to confirm.

And the certificate is issued for one exact hostname — the string you entered. That single fact is behind most of the “HTTPS is broken” reports below.

Top 3 Causes

You tried to put a CNAME on the root domain. example.com is a zone apex, and a zone apex already carries SOA and NS records. RFC 1034 §3.6.2 says a name with a CNAME can’t have any other records — so a plain CNAME at the apex is illegal, and most DNS panels either reject it or silently break your mail and everything else. The tell: www connects fine, but the bare root won’t. The fix is either a subdomain (www) or a provider that offers ALIAS/ANAME/CNAME-flattening at the apex.
www and root disagree, so one of them has no certificate. Tistory issued a cert for the single name you connected. The other form — the one you didn’t register — has no matching certificate and throws a warning the moment someone visits it. The tell: the padlock is fine on one form and broken on the other. The fix is a 301 redirect that sends every visitor to the connected form, not a second connection.
You didn’t wait, or you did it in the wrong order. DNS changes take time to propagate — commonly minutes, but up to 24–48 hours depending on the old TTL. If you connected in Tistory before the CNAME propagated, verification fails; if you’re testing HTTPS seconds after verifying, the certificate may not be provisioned yet. The tell: it “doesn’t work” but nothing is actually misconfigured — you’re just early.

Diagnose with DechoNet

DNS Lookup — confirm your hostname actually returns a CNAME to host.tistory.io, and check whether the apex is holding something it shouldn’t. This is the fastest way to see what resolvers see, not what your panel says you set.
DNS Propagation Check — query several resolvers worldwide at once, so you know whether a “not working” is really “not propagated yet” before you go re-editing records.
SSL Check — once HTTPS should be live, confirm the certificate covers the exact hostname visitors are hitting, and spot the www-vs-root mismatch directly.

Resolution Checklist

Pick one canonical form up front — www.example.com or the bare root — and commit to it.
In your DNS panel, add a CNAME on that hostname pointing to host.tistory.io. For a subdomain this just works.
If you insist on the bare root, use your provider’s ALIAS/ANAME/CNAME-flattening to point the apex at host.tistory.io; a plain CNAME there is invalid.
Run DNS Propagation Check and wait until the CNAME is visible from multiple resolvers before touching Tistory.
In Tistory, go to 관리 → 블로그 → 개인 도메인 설정, enter the exact hostname you configured, and let it verify (use the refresh button if it’s slow).
Add a 301 redirect from the other form (root→www or www→root) so every visitor lands on the one hostname that has a certificate.
Give HTTPS time to provision after verification, then run SSL Check against the canonical hostname.

When to Escalate

If the CNAME is verified, propagated, and pointed at host.tistory.io, but HTTPS still hasn’t come up after a reasonable wait, it’s Tistory’s certificate provisioning — not your DNS. Disconnecting and reconnecting the domain in the admin panel is the usual reset; beyond that it’s a Kakao/Tistory support question, not a record you can fix.
If your registrar won’t let you set a CNAME on www at all, check whether your nameservers actually point to the DNS provider whose panel you’re editing. Editing records at a host that isn’t authoritative for the zone changes nothing that resolvers can see.

Check your own domain now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.