One TXT record at _atproto turns your handle into @example.com — it's identity verification you already own, no subscription involved.
The complete path from a default .bsky.social handle to your own domain as your identity. The crumbs below are the whole job.
In the Bluesky app or on bsky.app, open Settings, then Account, then Handle. Choose "I have my own domain". Type the domain you want as your handle — the apex (example.com) or any subdomain (ben.example.com) both work, and a subdomain is the practical choice if the root domain is a shared company identity.
Bluesky then shows you two verification options: a DNS TXT record or an HTTPS well-known file. DNS is the set-and-forget option; take it if you control the zone.
The dialog displays a value beginning did=did:plc: followed by a long identifier. This DID is your actual permanent identity on the AT Protocol — the handle is just a human-readable pointer to it, which is why you can change handles freely without losing followers or posts. Copy the whole value exactly.
Host: _atproto.example.com Type: TXT Value: did=did:plc:abc123xyz456exampleidentifier
In your DNS host add a TXT record with host _atproto (your panel expands it to _atproto.example.com — if you're claiming a subdomain handle, it's _atproto.ben.example.com). Paste the did= value as the record content. On Cloudflare this is Type TXT, Name _atproto; the proxy toggle doesn't apply to TXT records so there's nothing to get wrong there.
No DNS access, or a locked-down corporate zone? Use the alternative: serve the bare DID string (just the did:plc:... part, no did= prefix) as plain text at https://example.com/.well-known/atproto-did. A static file in your site's public folder does it.
Back in the Bluesky dialog click Verify DNS Record (or Verify Text File). Fresh TXT records usually confirm within a few minutes; if it fails on the first try, wait five minutes rather than editing anything. When verification passes, click Update to switch — your handle is now @example.com everywhere, and your old @name.bsky.social handle keeps working as an alias, so old mentions and links don't break.
The TXT record isn't a one-time challenge — it is the ongoing proof that the domain vouches for your DID. Delete it and your handle eventually shows as invalid until you re-verify or switch back. Add a note in whatever you use to track DNS records that _atproto is load-bearing.
This also means the handle is transferable evidence: if your organization runs its own domain, every employee handle at @name.company.com is verifiable identity that no platform subscription can imitate.
Verification keeps failing after 10+ minutes.
Check the host is exactly _atproto (with the leading underscore) and the value starts with did= including the prefix. A DNS lookup for TXT at _atproto.example.com should return the record before you retry.
You claimed a subdomain but put the record at the root.
The TXT record must sit under the exact handle: a ben.example.com handle needs _atproto.ben.example.com. Move the record and re-verify.
The well-known file method won't verify.
The file must return HTTP 200 over HTTPS with the bare DID as the entire body — no did= prefix, no JSON, no trailing HTML from a framework's 404 page. Check it with curl.
Handle shows as invalid weeks later.
The TXT record was cleaned up, often during a DNS migration. Re-add the same did= value — your DID never changes — and the handle recovers.
Old handle stopped resolving for someone.
The previous .bsky.social handle remains an alias only while your account stays on the same PDS and nobody else claims it. Update published links to the domain handle, which is the stable one.
Honesty note: articles are drafted with AI assistance, then a human checks each one against the vendor's current setup flow before it publishes — nothing goes live unreviewed. Vendor interfaces still change; if a step looks different, the underlying record is what matters.