When you switch Bluesky accounts, your custom domain handle usually breaks. The domain verification record points to the old account’s DID. If you try to reuse the same domain on a new account without updating DNS, Bluesky will show a verification error. This article explains how to transfer your custom domain handle from an old Bluesky account to a new one without losing the handle or waiting for DNS propagation delays.
Key Takeaways: Preserve Your Custom Domain During Bluesky Account Migration
- Settings > Account > Handle > I have my own domain: Opens the DNS verification screen where you update the TXT record to point to the new account’s DID.
- DNS TXT record update: The single step that transfers the domain verification from the old Bluesky account to the new one.
- Domain provider’s DNS management panel: Where you change the TXT record value from the old DID to the new DID and save the change.
How Custom Domain Handles Work on Bluesky
A custom domain handle such as yourname.com is tied to a specific Bluesky account through a DNS TXT record. This record contains a value that starts with did= followed by the account’s unique DID string. When Bluesky checks the domain, it reads the TXT record and matches the DID to the account. If you create a new Bluesky account, the old DNS record still points to the old DID. The new account cannot claim the domain until the TXT record is updated to the new DID. DNS changes can take anywhere from a few minutes to 48 hours to propagate. You can speed up the process by lowering the TTL value before making the change.
Prerequisites for Migration
Before you start, you need the following items ready:
- Access to the DNS management panel for your custom domain. This is usually at your domain registrar such as Namecheap, GoDaddy, or Cloudflare.
- The new Bluesky account’s DID. You can find this in Settings > Account > Advanced > My DID.
- The old Bluesky account’s DID if you want to confirm which DID is currently in the DNS record.
- Write down the exact TXT record name and value from the old account before making changes. This acts as a backup.
Steps to Migrate the Custom Domain Handle to a New Bluesky Account
Follow these steps in order. Do not skip the DNS update step before attempting to verify the domain on the new account.
- Copy the new account’s DID
Open Bluesky on the web or desktop app. Go to Settings > Account > Advanced. Locate the My DID field. Select the full DID string and copy it to your clipboard. The DID looks likedid:plc:xxxxxxxxxxxx. - Log into your domain provider’s DNS panel
Open a new browser tab and sign in to your domain registrar or DNS hosting service. Navigate to the DNS settings for the domain you want to use. Look for the TXT record that containsdid=in its value. This is the verification record Bluesky uses. - Edit the existing TXT record
Click Edit or Modify on the TXT record. Replace the current value with the new DID from step 1. The full value must bedid=did:plc:xxxxxxxxxxxxwith no extra spaces or quotes. Save the record. - Reduce the TTL before saving if possible
If your DNS provider allows custom TTL, set it to 300 seconds or 5 minutes before saving. This forces DNS resolvers to check for the new record sooner. After the migration is confirmed, you can increase the TTL back to 3600 or higher. - Wait for DNS propagation
Use a DNS lookup tool such as whatsmydns.net to check if the new TXT record appears globally. Enter your domain name and select TXT as the record type. Wait until the new DID value shows in all locations. - Verify the domain on the new Bluesky account
Go back to the new Bluesky account. Navigate to Settings > Account > Handle. Select I have my own domain. Enter your domain name exactly as it appears in the DNS record. Click Update Handle. Bluesky checks the TXT record. If the DID matches, the handle changes to your custom domain. - Remove the domain from the old account
Log into the old Bluesky account. Go to Settings > Account > Handle. Change the handle to a standard bluesky.social handle. This step is not required for the migration to work, but it prevents confusion if you ever reactivate the old account.
What Can Go Wrong and How to Fix It
DNS record still shows the old DID after 24 hours
The most common cause is a high TTL value that was set before the change. DNS resolvers cache the old record until the TTL expires. If you cannot change the TTL, wait the full duration. Alternatively, use a different DNS provider that supports lower TTL values. Some registrars like Cloudflare allow instant propagation through their API.
Bluesky says the domain is already in use
This happens when the old Bluesky account still has the custom domain set as its handle. Even if the DNS record points to the new DID, Bluesky’s system checks both the DNS and the account database. Log into the old account and change its handle to a standard @username.bsky.social handle. Wait 10 minutes and try verifying on the new account again.
The TXT record value is rejected by the DNS provider
Some DNS providers require the value to be enclosed in double quotes. If the save fails, add quotes around the full value: "did=did:plc:xxxxxxxxxxxx". Other providers strip the quotes automatically. Check your provider’s documentation for TXT record formatting rules.
Domain verification succeeds but the handle does not update
This is usually a browser cache issue. Close the Bluesky tab completely, clear the browser cache, or use an incognito window. Log in again and check Settings > Account > Handle. The custom domain should appear as the current handle. If not, repeat the verification step.
| Item | Old Account | New Account |
|---|---|---|
| DID in DNS record | Old DID | New DID |
| Handle setting | Custom domain | Custom domain |
| DNS propagation status | Outdated | In progress |
| Bluesky verification | Fails | Succeeds after DNS update |
After the migration, your new Bluesky account shows your custom domain handle to all followers and visitors. The old account no longer displays the domain. If you plan to delete the old account, wait at least 48 hours after the handle change to ensure DNS propagation is complete across all servers. You can also set a custom TXT record with a _atproto subdomain for better isolation, but the main domain record is sufficient for a standard migration.