Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Addresses

A SithBit address begins with the public key of a Solana cryptographic keypair, commonly called a wallet.1 The public key is encoded as a case-sensitive base58 string, typically 43 or 44 characters long.2

For example:

85FZrun1Eb5bdkbFCDjaFSTLnBfnx6sUFHa5BiYH2Q03

This public address can receive SOL and identify your mailbox; the private key stays secret and proves that the wallet is yours. The getting-started wizard can create a new keypair or import one you already hold, and every GUI client includes that wizard.3

Bare addresses and domain addresses

The bare public key is a valid SithBit email address once it has a mailbox. It works for direct, on-chain mail between wallets and does not depend on a DNS domain.

To route mail through standard SMTP, associate the mailbox with an authorized domain. The wallet address then becomes the local part — the text before @ — of a conventional domain-qualified address:4

85FZrun1Eb5bdkbFCDjaFSTLnBfnx6sUFHa5BiYH2Q03@sithbit.com

The domain tells mail servers where to route the message. It does not replace the wallet as your underlying identity, and you can move your mailbox to a different authorized domain.

Friendly aliases

Long wallet addresses are hard to remember, so SithBit also supports short aliases. The getting-started wizard can claim an optional handle, such as myalias, which you can use as myalias@sithbit.com.5

Aliases are globally unique and case-insensitive. myalias@sithbit.com, MYALIAS@SITHBIT.COM, and MyAlias@Sithbit.com all resolve to the same wallet. Wallet addresses remain case-sensitive because case is part of their base58 value.

Trusting a “from” address

The “to” side of an email always resolves to an on-chain wallet address. The stored “from” side does not have to: it is an off-chain string such as jane_doe@sithbit.com. That raises the obvious question: what stops someone from claiming any “from” address they like?

  • Only a recipient’s own domain authority can deliver into their mailbox. Every SendMail instruction requires the transaction signer to be the active, registered authority for the recipient’s (“to”) domain — the same wallet named in that domain’s on-chain MailDomain account. The comparison is part of the instruction itself, not an operator policy anyone can relax: a signer that doesn’t match is rejected (IllegalAuthority) and the whole transaction fails. This is not a check on the “from” domain — it’s what stops a stranger from injecting mail directly into someone else’s mailbox at all, regardless of what “from” address they claim.
  • Domain authority is DNS-gated, not self-asserted. A domain’s authority is set either by the postoffice’s delegate directly, or (self-service) by the domain-sithbit service after it verifies a _solana.authority.<domain> DNS TXT record matches the claimed key — see Create a domain. Controlling a domain on-chain requires controlling that domain’s DNS, the same trust root traditional email anti-spoofing and anti-phishing defenses (SPF6/DKIM7) relies on.
  • A domain-less from address must match the signer’s own wallet. If the recipient address has no @domain at all (a direct, unrouted on-chain send), the program instead requires the signer to be the exact address named in the “from” field — so a bare public-key “from” can only ever be sent by its own keypair. There is no relaying at all in this case.
  • One MX relay signs as one set of domains. The gRPC gateway that submits SendMail on behalf of an MX server signs every transaction with a single configured keypair, so a given mail server deployment can only deliver into mailboxes on the domain(s) it actually holds the authority key for — it can’t inject mail into a domain’s mailboxes that it doesn’t operate.
  • The “from” domain itself is not independently re-checked on-chain. Once a signer clears the checks above, the “from” string it submits is otherwise free-form (format-validated for length only). The chain trusts that the recipient’s own domain operator already verified the claim — which is exactly what SPF/DKIM/DMARC8 do, off-chain, before that trusted operator ever submits SendMail. An operator who has misconfigured that off-chain authentication — or turned it off entirely — is the actual point of failure for “from”-domain spoofing, not the on-chain program.
  • Postage adds economic friction on top. Every send burns a stamp from a frombox keyed on (from string, recipient wallet), priced by the recipient — see Economics. This doesn’t block spoofing by itself, but it means even a fabricated “from” string costs the actual sender lamports, at a price the recipient controls.
  • Inbound SMTP mail is checked with SPF/DKIM/DMARC before it ever reaches the chain pipeline — see Configuration for the operator settings that govern how strictly it is applied. This is the layer that actually authenticates a “from” domain’s claim; the chain only enforces who may deliver to a given recipient.
  • Casing can’t be used to dodge any of the above. Domain names are lowercased both when a MailDomain account is created and every time one is looked up. Each operation that touches a domain — the delivery authority check, plus creating, transferring, deactivating and closing a domain — lowercases the name independently, so there is no path that skips the normalization and no caller who can opt out of it. SithBit.Com and sithbit.com are therefore the same account, and there’s no shadow-domain trick via casing. A frombox’s “from” key is normalized the same way — the domain half of a domain-qualified address is lowercased — so pricing set for jane@sithbit.com also applies to Jane@SithBit.Com. Bare wallet addresses are deliberately left case-sensitive, since a base58 pubkey’s case is part of its identity, not a stylistic variation.

What’s not enforced on-chain is the authenticity of the “from” domain itself, and the local part under any authorized recipient domain: a domain’s authority can write any “from” string it likes for mail delivered to its own mailboxes, the same trust a real domain’s mail server holds for traditional email — the protocol’s guarantee is that only a recipient’s own trusted operator can deliver to them, not that every “from” claim has been independently re-verified.

  1. A Solana wallet contains an Ed25519 public key and its associated private key. See Curve25519 for the underlying elliptic curve. ↩

  2. The 32-byte public key is base58-encoded to produce the address string. ↩

  3. Power users can create a keypair from the terminal with the SithBit CLI; see Creating a wallet. Compatible tools such as the Solana CLI’s solana-keygen can create one too. ↩

  4. From the terminal: Create a mailbox and Update a mailbox. ↩

  5. Registering additional aliases (and transferring them) is CLI territory today — see Create an alias. ↩

  6. For the formal specification, see RFC 7208 (Sender Policy Framework); dmarc.org’s overview explains how SPF, DKIM, and DMARC work together in practice. ↩

  7. For the formal specification, see RFC 6376 (DomainKeys Identified Mail). ↩

  8. For the formal specification, see RFC 9989 (Domain-based Message Authentication, Reporting, and Conformance), which obsoletes the earlier RFC 7489; its reporting halves are specified separately, in RFC 9990 (aggregate, rua) and RFC 9991 (failure, ruf). dmarc.org also has practical deployment guidance. ↩