How Bluesky Custom Domain Verification Works Under the AT Protocol
In traditional social networks (such as X/Twitter or Instagram), user identity is strictly tethered to a proprietary username managed in a centralized database. If a user changes their username or leaves the platform, their social graph is shattered.
The AT Protocol (ATProto), the decentralized networking standard powering Bluesky, revolutionizes identity by decoupling human-readable handles from cryptographic account identifiers.
Decentralized Identifiers (DIDs) vs Handles
Every Bluesky account is permanently anchored to a Decentralized Identifier (typically formatted as did:plc:abcdef123456...). This cryptographic string never changes, regardless of how many times you alter your display handle or migrate between Personal Data Servers (PDS).
Your handle (such as @nytimes.com or @alice.dev) is merely a pointer to your DID. When Bluesky displays a verified custom domain, it has verified bi-directional cryptographic proof between the domain's DNS and your DID.
The Bi-Directional Proof Protocol
Domain verification requires two complementary links:
1. Domain Points to DID (DNS TXT Record)
The domain owner publishes an _atproto DNS TXT record containing did=did:plc:your-did. This proves that whoever controls the domain's DNS zone intends to delegate authority to that specific ATProto account.
2. DID Points to Domain (PLC Directory / Account Metadata)
When you click "Verify" in Bluesky, your account's signed identity document in the PLC directory is updated with your new domain handle. The ATProto relay performs an automated DNS lookup on _atproto.yourdomain.com to verify the match.
Common DNS Registrar Gotchas
- Double Domain Bug: On registrars like Namecheap, entering
_atproto.domain.cominto the Host field creates_atproto.domain.com.domain.com. Always enter just_atproto. - Subdomain Syntax: For subdomains (e.g.
news.site.com), the record name must be_atproto.news. - TTL Caching: Keep TTL at 60 or 300 seconds so updates propagate rapidly.