Domains

What is a domain

A domain is a claimed, protocol-authorized mail suffix — like sithbit.com — that a mailbox references so that MX servers know how to route mail to it over SMTP. Domains are registered and administered on-chain: someone must claim a domain and have the postoffice’s delegate authorize it before mailboxes on that domain can send or receive mail through the normal MX/SMTP path. The whole domain registry — the domain accounts, their lifecycle, and the marketplace — lives in its own dedicated on-chain domain program.

The marketplace web page shows the domains listed for sale, and each client’s Domains pane shows the ones your wallet holds.¹

Active and inactive domains

Every registered domain is either active or inactive. An active domain is fully usable: mailboxes may register against it, and mail may be sent to or deleted from mailboxes that reference it. An inactive domain — one whose deactivation has been finalized — blocks both: it refuses new or updated mailbox registrations, and it blocks sending and deleting mail for the mailboxes that already reference it. A mailbox’s domain must be a registered, active domain (or no domain at all), so deactivating a domain locks it down from new registrations too, not just mail flow.

Who can create a domain

Claiming a domain involves up to three distinct roles, and signing authority over each is separate from the others:

• Authority — the mail server’s signing key for the domain. SendMail into a mailbox is only accepted when the transaction signer is the recipient domain’s recorded authority, and that authority collects the operator share of DeleteMail settlement (see Economics). Transferring, deactivating, and closing a domain are delegate operations, not authority ones — holding a domain’s authority key lets you operate mail for it, not dispose of it.
• Delegate — must always sign a domain’s creation; only the postoffice’s standing delegate can authorize a new domain. A signer that isn’t the delegate is refused outright.
• Payer — funds the new account’s rent; defaults to the delegate when no separate payer is given.

Domain identity is scarce and protocol-wide in a way a mailbox or alias isn’t: claiming sithbit.com grants standing to receive mail for an entire suffix, so the postoffice — not any individual key holder — decides who gets to claim it, which is why the delegate’s signature is mandatory even though the authority and payer roles are flexible. Because domain accounts are keyed by the domain name alone rather than by who created them, one authority key can still hold any number of domains: a mail-server deployment serving several domains registers each of them with the same authority key.

Asking the delegate holder to sign by hand isn’t the only route to authorization, though — see DNS setup for a self-service alternative that proves domain ownership instead.

Deactivating a domain isn’t instant

Deactivating a domain blocks sending and deleting mail for every mailbox that references it, and it also blocks new mailbox registrations against that domain — a network-wide halt for everyone whose address lives on it. Because that’s such a disruptive action, the protocol never lets it happen with a single signature. Instead it runs on a deactivation timelock: a waiting period between the moment deactivation is requested and the moment it actually takes effect. The domain stays fully active — mail keeps flowing normally — for the entire window.

The point of the wait is to give everyone with a stake in the domain a chance to notice and object before the cutoff lands. The delegate is a single hot admin key (see the threat model), so a compromised or coerced delegate that could deactivate a domain instantly could take its relayed mail down without warning. Splitting the action into a request that only starts a clock, followed by a separate step that finalizes it, turns that into a notice-and-veto window: the domain’s authority, or anyone else monitoring delegate activity, sees that deactivation is pending and has time to intervene — including cancelling the request outright — before it ever affects mail flow. Reversing course in the safe direction, reactivating a domain, is never subject to this delay; only the destructive direction is.

While a domain is in this state it is described as having a pending deactivation: the request has been made and the clock is running, but the domain itself is still active in every respect until the waiting period elapses and the deactivation is carried through. A pending deactivation can still be called off before that happens, which simply cancels the clock and leaves the domain untouched, as if nothing had been requested. Because deactivation reaches every mailbox on the domain at once, requesting, finalizing, and cancelling it are all delegate-only actions, the same standing authority that must approve a domain’s creation in the first place.

Requesting, finalizing, cancelling, and reversing a deactivation are delegate operations run from the terminal.²

Transferring a domain

A domain’s authority is the key that mail-serving control belongs to: it’s the only signer SendMail into a mailbox on that domain will accept, and it’s the key that earns the operator’s share of settlement when mail is deleted (see Economics). Transferring a domain reassigns that one role to a different wallet — nothing else about the domain moves. The domain’s name, its active/inactive status, and every mailbox that already references it are all untouched by a transfer: mail keeps flowing under the new authority exactly as it did under the old one, without interruption and without any mailbox needing to re-register.

Because a domain’s authority is a role over a shared, protocol-scarce resource rather than personal property, the current authority holder cannot simply hand it off unilaterally — the same standing that must approve a domain’s creation is required to reassign it. See Who can create a domain for why that authority is concentrated in the postoffice’s delegate rather than left to individual key holders: transferring a domain is a delegate-only operation for exactly the same reason creating one is.

Reassigning a domain’s authority is likewise a delegate operation run from the terminal.³

What buying a domain does — and does not — buy

A domain can also change hands on the open marketplace rather than by delegate-signed transfer. For how that sale is priced, timed, and settled — listings, the binding window, the 90/10 split — see Trading names: aliases & domains; this section covers only what a purchase conveys, not how the sale itself works.

A marketplace domain sale conveys protocol authority, nothing more. Concretely, the buyer’s wallet becomes:

• The domain’s mail-injection key. SendMail into a mailbox on the domain is only accepted when the transaction signer is the domain’s recorded authority — buying puts that signing right, the on-chain half of running the domain’s inbound relay, in the buyer’s hands.
• The domain’s settlement collector. The buyer earns the operator share of every DeleteMail settlement (see Economics) for mailboxes on the domain from that moment on.

It does not convey anything off-chain:

• Not DNS. The DNS name is owned at the registrar, entirely outside the protocol; a sale never moves it. Whoever holds the registration keeps the zone — the MX records, the _solana.authority.<domain> TXT record, all of it.
• Not hosting. No MX server, sithbitd deployment, or IPFS infrastructure changes hands.
• Not DKIM. Signing keys live in the operator’s DNS zone and filesystem, never on-chain.

A buyer who wants to operate the domain — actually receive its mail, not just collect its settlement share — must separately obtain the DNS name (or the cooperation of whoever holds it) and stand up their own MX. Do that diligence before paying: the on-chain state is easy to check,¹ but only the DNS zone shows who controls the name itself. For what can go wrong when on-chain authority and DNS ownership sit in different hands — lockouts, proof replay, and authority drift — see The marketplace sells protocol authority; DNS remains separately owned in the threat model.

Buy a listed domain from the marketplace web page’s For-sale tab, and list your own from its listing form or your client’s Domains pane.⁴

1. From the terminal: Looking up a domain inspects any domain’s registration and status. ↩ ↩2

2. See Deactivating a domain for the commands. ↩

3. See Transferring a domain for the command. ↩

4. From the terminal: List a domain for sale covers sithbit domain sell/buy. ↩