Unstoppable Domain Not Resolving? A Troubleshooting Guide

If an Unstoppable domain is not resolving, identify which lookup is failing before changing records. A wallet receiving lookup, a displayed identity and a website request use different information. A name appearing in your account does not establish that all three work.

Define the expected result

These are editorial diagnostic steps informed by the provider’s record and resolution architecture. They do not certify a wallet, website or transaction. Start with one concrete mismatch rather than treating every missing name as the same problem.

Confirm the full identifier and product

Copy the complete name from your own account or a trusted record, then compare its spelling and suffix with the app input. A DNS name sold by Unstoppable and a Web3 name sold by the same company are different products. Their settings are not interchangeable.

Check that the intended asset exists in the expected holding arrangement and that any recent update has confirmed. An order confirmation and a pending record edit describe different stages. If the purchase itself is unresolved, use the purchase checklist first.

Inspect the relevant receiving record

Unstoppable’s reference distinguishes native currency addresses from token-version and network-specific records. Compare the intended destination against the actual relevant saved value. A token label such as USDT can require additional network context.

Record values are not validated by the registry contract. A successful write therefore does not establish that a destination is suitable. Follow the record setup guide and compare the entire address, rather than relying on a shortened wallet display.

If you control the name and find an incorrect record, use the supported management flow and review the correction. Wait for confirmed state before checking the receiving app again. Keep the before and after observations so you can identify what actually changed.

Check app support for the exact action

The provider’s resolution examples select records in the context of a currency and network. An app must implement the relevant lookup. Support for one naming service, suffix or display action does not establish support for every Web3 identifier.

For example, MetaMask’s official Snaps directory describes Unstoppable name lookup in the Extension’s sending flow through a specific Snap, with version requirements. That is narrower evidence than a claim that every MetaMask product automatically supports every name.

Check the app’s own current integration documentation and record its limits. A read-only lookup can show what address the app displays without requiring a payment. Our wallet compatibility guide explains how to record that evidence.

Separate reverse identity from forward resolution

Forward resolution starts with a name and returns a configured destination. Reverse resolution starts with an address and returns a selected name for an integrating app. If receiving works but an account still displays a hexadecimal address, investigate the identity-display route.

Unstoppable documents that reverse information is removed at contract level when ownership changes. A transfer can therefore explain a changed display even when another record is still present. Recheck the owner and the intended identity settings through the current interface.

Treat website access as its own investigation

The record reference lists website content and redirect fields separately from payment destinations. Check the actual configured record type, the target content and the browser’s access route. Editing an Ethereum receiving address does not repair an unavailable website release.

If the target is decentralized content, name resolution and content retrieval are separate dependencies. The ENS/IPFS hosting guide explains that general distinction, while its ENS editing steps apply specifically to ENS.

Build a useful support report

Save the complete public name, expected action, app/version, selected network, observation time and exact error. Include the relevant public record or transaction reference when appropriate. Keep recovery phrases and private keys out of support requests.

If one app differs from confirmed saved state, report that precise discrepancy. Repeated unrelated edits or reinstalls can obscure the original problem. After a handover, review the route-specific record checklist before assuming old data was cleared.