Domain-scoped aliases

An alias normally lives in one global namespace: whoever registers alice first owns it everywhere, and alice@anything resolves to that one wallet. A domain-scoped alias is a second, separate namespace layered on top of it — it maps local-part @ verified-domain to a wallet, and only that domain’s authority may create entries in it. This lets an organization that controls acme.com on-chain assign [email protected], [email protected], … to its people’s wallets, in a namespace nobody else can write to.

The two namespaces never collide: [email protected], [email protected], and the global alice are three different on-chain accounts — the domain-scoped account is hashed on both the domain and the local part under a seed distinct from the global alias seed, so registering one never touches or shadows the other.

Who can register a domain-scoped address

Only the wallet recorded as the domain’s authority may write into that domain’s namespace. There is no anti-squatting fee the way there is for a global alias — the namespace is scoped to a domain the authority already owns, so squatting isn’t possible in the first place, and the authority pays only the new mapping account’s rent.

Trust note. The domain authority chooses which wallet each user@domain maps to, and can repoint or remove it at any time. This is not a new trust relationship — that same authority already operates the domain’s mail relay and is fully trusted for relayed mail. A domain-scoped address is only ever as trustworthy as the domain that issues it.

Resolution precedence: domain-scoped wins, global is the fallback

Because both namespaces can define an address like [email protected] at once — a domain-scoped mapping and a same-named global alias are unrelated accounts — something has to decide which one wins. The rule is simple and applied consistently everywhere an address is resolved: the domain-scoped mapping is checked first, and only when no domain-scoped entry exists does resolution fall back to the global alias namespace (the historical, domain-blind behavior).

That single precedence rule does triple duty:

• Native resolution — a client turning [email protected] into a wallet address checks the domain-scoped namespace first, then falls back to the global alias alice.
• Inbound mail delivery — a SithBit MX server receiving mail addressed to [email protected] over SMTP applies the identical precedence to decide which wallet’s mailbox receives it, so a domain that has never registered any domain-scoped addresses keeps delivering through the plain global-alias path, unchanged.
• Encryption-key discovery — looking up the public key to seal mail to an address composes the same domain-then-global lookup before returning a key.

The practical effect: existing global aliases keep resolving exactly as before even after a domain starts registering its own scoped names, and a domain only ever affects addresses under its own suffix — it can never shadow or hijack a global alias belonging to someone else’s domain (or none at all).

A domain’s authority creates, repoints, and removes these mappings from the terminal — see Register a domain-scoped alias, which also covers the mechanics of inbound delivery and key discovery.