How to self verify using a domain with Bluesky

Bluesky, a decentralised social network protocol project rooted in transparency and user autonomy, allows individuals and organisations to establish verified identities via custom domain names. This process—known as domain-based self-verification—enables users to associate their online presence with a trusted domain they control. As platforms increasingly decentralise, methods like these become critical for maintaining credibility and resisting impersonation. You can read more about the protocol and its technical principles on the official AT Protocol site.

By verifying a domain with Bluesky, you assert control over your digital identity without relying on centralised third parties. Whether you're representing a business, a brand, or yourself, the ability to prove ownership of a domain creates a verifiable link between your Bluesky profile and your real-world presence. In a time when misinformation is easily spread, technical verification provides a tangible layer of trust. For a broader look at decentralised identity concepts, the W3C DID Core specification offers useful technical context.

TL:DR – The article explains how to self-verify your identity on Bluesky using a domain you control. We cover how domain-based verification works, the technical requirements, step-by-step instructions for both DNS and web-based verification, and how to link and maintain your verified handle securely.

Overview of domain-based verification on Bluesky

Domain-based verification on Bluesky allows users to replace their standard username (typically in the form of @handle.bsky.social) with a custom domain they own, such as @yourdomain.com. This mechanism forms the backbone of identity in the AT Protocol. Instead of trusting a central provider to manage usernames, Bluesky users can prove identity independently using existing internet infrastructure.

The verification works by associating your domain with a Decentralised Identifier (DID), effectively linking the human-readable handle to the cryptographic identity. It ensures that only those with access to DNS settings or the ability to serve content on the domain can make this claim. This significantly reduces spoofing and adds a layer of trust and authority.

As decentralised systems rely more on verifiable claims rather than central databases, mechanisms like domain verification are set to become industry standard. For creators, developers, and businesses, this is a strategic method to retain branding consistency across federated platforms.

Why self-verification matters for identity and trust

In an open ecosystem like Bluesky, identity verification is decentralised by design. Self-verification using a domain ensures that your audience can trust that your profile genuinely belongs to you, rather than an imposter using a similar name. It is especially important for brands, public figures, or services where misrepresentation can lead to reputational or financial damage.

Traditional verification mechanisms rely on central authorities who decide who gets a verification badge. Bluesky inverts this by giving control back to users. If you own and control a domain, you can prove it cryptographically and attach it to your identity, without needing permission from any platform.

This approach aligns with broader movements in privacy and decentralisation, where control over identity and content is shifting away from large corporations towards individuals and communities.

What is Bluesky?

Bluesky is a decentralised social networking initiative that builds on the AT Protocol. It aims to create an open standard for public conversation, one that prioritises portability, algorithmic choice, and data sovereignty. Rather than a single app, Bluesky represents an ecosystem of interoperable services and clients.

The Bluesky app is one implementation of this protocol, acting as a Twitter-like social client where users can follow, post, and interact. Unlike traditional social networks, Bluesky doesn’t lock users into one platform—your identity and content are portable and not owned by any single company.

Bluesky is part of a broader effort to fix the web’s identity and content problems by decentralising control, in the same way email and the web itself are decentralised protocols.

How DIDs (decentralised identifiers) work in Bluesky

DIDs, or Decentralised Identifiers, are a core component of Bluesky's architecture. A DID is a string that uniquely identifies a person or entity and is backed by cryptographic material such as public keys. In Bluesky, every user has a DID, which is the actual identity anchor within the system.

The human-readable handle (like @username.bsky.social or @yourdomain.com) is just an alias that maps to your DID. This separation allows users to change handles without losing their identity, content, or followers—something not possible on traditional platforms.

By verifying a domain and linking it to your DID, you’re not just branding your profile—you’re anchoring it in a way that’s resistant to platform failure, hijacking, or deplatforming.

Explanation of the handle vs DID relationship

In Bluesky, a handle is what users see and remember. However, the system internally uses your DID, which is an unchanging identifier. This distinction is important. You can change your handle at any time, but your DID remains the same, serving as your core identity.

When you link a domain to your handle, you're effectively mapping that handle to your DID using one of two supported methods: DNS-based TXT records or web-based file verification. Once this mapping is in place, others can resolve your handle to your verified DID and confirm your identity.

This architecture allows for a level of identity abstraction not present in centralised platforms. It also makes it easier to migrate between services, as your content and identity are linked to the DID, not the service itself.

The role of domain ownership in identity verification

Ownership of a domain is proof of control. If you can alter DNS records or serve files at specific URLs, it’s assumed you have administrative rights over that domain. Bluesky uses this concept to confirm that a user who claims a domain as their handle genuinely controls it.

This creates a strong cryptographic and administrative binding between your handle and your DID. Users who visit your profile and see a verified domain can trust that it is officially associated with you, without needing to rely on a third-party verification authority.

This method benefits developers, businesses, and independent professionals alike, as it reinforces trust while preserving decentralisation principles.

Prerequisites for self-verification

Before you begin the domain verification process on Bluesky, there are a few prerequisites to meet. You must have full administrative access to your domain. This includes either the ability to edit DNS records via your domain registrar or the ability to serve files on the domain through a web host. Without one of these capabilities, verification won’t be possible.

You’ll also need a working Bluesky account, which includes an existing DID and handle. Ensure that your domain is live and resolves correctly, whether it’s the root domain (like example.com) or a subdomain (such as social.example.com). Both are supported, but it’s critical that DNS and hosting are functional.

Finally, consider SSL. If you're using the web method, HTTPS hosting is recommended to prevent MITM attacks. While Bluesky does not require HTTPS at this stage, it’s a security best practice and a sign of a well-maintained domain.

Choosing between DNS and web-based verification

Bluesky supports two domain verification methods: DNS-based and web-based. The DNS method involves creating a TXT record in your domain’s DNS settings that contains your DID. The web-based method requires you to serve a specific file—.well-known/atproto-did—from your domain containing your DID.

The DNS method is ideal if you already manage your domain through a registrar or DNS provider. It’s more ‘set and forget’, with minimal ongoing maintenance. However, DNS changes may take time to propagate and require comfort with DNS editing.

The web-based method is often easier for those with control over their web server. You can update the verification file quickly and test it instantly. But it does require your site to be live and capable of serving files reliably from the /.well-known/ path.

Using the DNS method to verify a domain

To verify your domain using DNS, log in to your DNS provider’s control panel and add a TXT record to the root or subdomain you’re using. The content of the record should be in the format did=did:plc:yourdidvalue. This line links the domain to your decentralised identifier.

Once the record is saved, DNS propagation may take several minutes to several hours. During this period, Bluesky might not immediately recognise the change. You can check if the TXT record is visible using tools like DNSChecker or command-line utilities such as dig or nslookup.

If verification fails, double-check the formatting of the TXT record and confirm that it’s applied to the correct domain. Avoid adding extra quotation marks or typos. Misplaced DNS entries are one of the most common reasons for failed verifications.

Heres an example:

Using the web-based method to verify a domain

To use the web method, create a file named atproto-did and place it in the /.well-known/ directory at the root of your domain. The file should contain only your DID, such as did:plc:yourdidvalue, with no additional formatting or markup.

This file must be accessible via a browser or curl request at the exact URL https://yourdomain.com/.well-known/atproto-did. Ensure your server is correctly configured to serve plain text and doesn’t redirect or rewrite requests to this endpoint.

You can test it by running: curl https://yourdomain.com/.well-known/atproto-did. If the response is your correct DID with a 200 status, your setup is valid. Bluesky will periodically attempt to verify this file, so ensure it remains online.

Linking the domain to your Bluesky account

Once your domain is correctly configured for DNS or web-based verification, open the Bluesky app or web interface and navigate to Settings → Advanced → Change Handle. Enter your custom domain in the handle field, e.g. @yourdomain.com.

Bluesky will attempt to verify ownership by checking the DNS or web record. If successful, your handle will update within seconds or minutes. If verification fails, you’ll see an error—usually due to propagation delay or a formatting issue with the verification method.

Your new handle will replace the default @username.bsky.social. Don’t worry—your DID remains the same, and followers will not be lost during the change. The change is purely cosmetic and branding-focused, anchored by the underlying DID.

Maintaining and renewing verification

Once verification is complete, it's crucial to maintain control of the domain and keep the verification mechanism active. If you delete the TXT record or the verification file becomes inaccessible, your custom handle may stop working, and Bluesky will revert to the default handle.

If your domain is transferred to a new registrar or host, you must reapply the verification configuration. This ensures continued association between your domain and DID. Without it, verification breaks, and your identity may appear unverified.

It’s good practice to periodically confirm that verification is still valid. Check the TXT record or file response and monitor domain health. This ongoing diligence is especially important for organisational or brand identities.

Security considerations and best practices

Securing your domain is foundational to maintaining a verified Bluesky handle. Always use strong, unique credentials for your registrar and enable two-factor authentication. A compromised domain could be used to impersonate your Bluesky identity.

For web-based verification, serve the .well-known file over HTTPS. Although not mandatory, encrypted transport protects against tampering and interception. Additionally, use content security policies to prevent injection attacks.

Avoid using third-party services to manage verification unless absolutely necessary. If you do use them, ensure they are reputable and provide access logs or activity history. Retain full control whenever possible to reduce risks.

Use cases and benefits of self-verification

Self-verification via a domain is a powerful way to maintain brand consistency across platforms. A business using @brand.com as its Bluesky handle is instantly recognisable, and the verification confirms legitimacy to users.

For individuals, domain verification separates your profile from platform-specific usernames. Your identity becomes portable and platform-agnostic. Whether you move between Bluesky clients or mirror your profile on other AT Protocol-compatible apps, your handle remains intact.

Finally, in a decentralised ecosystem, self-verification is a foundational tool. It empowers users to build trusted reputations independently of corporations, algorithms, or platform moderators.

Conclusion

Verifying your identity on Bluesky using your own domain is a powerful way to establish trust and independence in a decentralised ecosystem. From setting up DNS records to hosting verification files, the process is straightforward for anyone with domain access. By understanding the relationship between DIDs and handles, and maintaining your domain responsibly, you ensure your identity remains resilient and verifiable.

As the digital landscape continues to move towards decentralised and federated systems, domain-based verification provides a future-proof mechanism for authenticating identity. To dive deeper into decentralised identifiers and emerging standards, the Decentralized Identity Foundation is an excellent resource.