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

In the Solana blockchain, an “address” is the public key portion of a cryptographic key pair.1 The public key is typically represented as a case-sensitive string about 45 characters in length .2

For example: 85FZrun1Eb5bdkbFCDjaFSTLnBfnx6sUFHa5BiYH2Q03.

You can easily create key pairs (also known as “wallets”) with sithbit wallet create (see Getting Started).3

Once you create a keypair, the public key can serve duel purposes: it can be the source or target of cryptocurrency coin transfers, but can also act as an RFC822-compliant internet email address.

By default, a public key is not associated with an email domain until you create a mailbox for it, or update its existing mailbox. Once you associate the public key with a domain, it becomes the case-sensitive “local” portion of the RFC822-compliant email address (i.e., the part of the address before the ‘@’ symbol, which separates the domain portion of the address).

For example: 85FZrun1Eb5bdkbFCDjaFSTLnBfnx6sUFHa5BiYH2Q03@sithbit.com

A domain is only required when email is routed through SMTP, but without a domain, emails can only be sent directly through the program, where both the “from” and “to” addresses are public keys without a domain portion of the email.

Trusting a “from” address

The “to” side of an email is always an on-chain wallet address, but the “from” side doesn’t have to be — it’s an arbitrary off-chain RFC822-compliant string (e.g. jane_doe@sithbit.com), which raises the obvious question: what stops anyone from sending mail claiming to be 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 (mail_program’s send.rs, is_domain_authority). A signer that doesn’t match is rejected (IllegalAuthority). 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 postmaster 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 (SPF4/DKIM5) 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/DMARC6 do, off-chain, before that trusted operator ever submits SendMail. A misconfigured or sender_auth = "none" operator 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 (recipient wallet, from string), 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 the sender_auth setting in Configuration. 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 (mail_model::postoffice::domain) and every time one is looked up (send.rs’s authority check re-lowercases independently, as does domain creation/transfer/deactivation/closing) — SithBit.Com and sithbit.com are the same account, so there’s no shadow-domain trick via casing. The frombox “from” key is normalized the same way (Frombox::normalize_from_address lowercases the domain-qualified form), 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.

Since public key addresses usually appear as long random strings that are hard to remember, it is also possible to create one or more friendly aliases for an address via the alias program. Aliases are globally-unique identifiers for public key addresses. Once created, they represent public keys across all domains.

Instead of using 85FZrun1Eb5bdkbFCDjaFSTLnBfnx6sUFHa5BiYH2Q03@sithbit.com, you might create the alias myalias, and use myalias@sithbit.com as your public email address.

Unlike public key addresses, aliases are case-insensitive. So myalias@sithbit.com, MYALIAS@SITHBIT.COM, and MyAlias@Sithbit.com are all aliases for the same public key address.

  1. A keypair (or “wallet”) in the Solana blockchain is specifically a public key and its associated private key derived from the ED 25519 eliptical curve. ↩

  2. The 32 bytes of the key are base58 encoded to produce the string. ↩

  3. Since ED25519 key pairs are created by a publically well-known algorithm used by multiple blockchains, there are actually many tools that can create them — including the Solana CLI’s own solana-keygen, if you already have it installed. ↩

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

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

  6. For the formal specification, see RFC 7489 (Domain-based Message Authentication, Reporting, and Conformance); dmarc.org also has practical deployment guidance. ↩