Mailboxes

What is a mailbox

A mailbox is an account on Solana that stores email settings for an address. An address must have an associated mailbox created before participating in the email system, and an address can only have one mailbox.

Every GUI client shows a mailbox’s settings in its Mailbox pane — see the webmail, Chrome, Thunderbird, or Outlook client pages.¹

Mailbox settings

A mailbox holds the following settings:

• Mail count. The total number of emails sent to the mailbox since it was created.
• Default Postage. The default price of a stamp in lamports to send an email to the mailbox. When you create a new frombox, this value is used initially for the stamp price for the frombox unless otherwise specified. The default price should be set very high to prevent SPAM from being sent to the mailbox.
• Domain. The program address that represents the internet domain associated with the mailbox. You can change the domain for your account at any time, but in order for email to be properly routed to your mailbox, the owner of the domain must have registered the domain with the email program. In addition, the domain must host MX servers that support the email program protocol.
• No IPFS. Whether the owner has opted out of public IPFS body storage — see IPFS storage: benefits to users. When enabled, delivered bodies are kept in the operator’s own store and the on-chain message carries a local-only marker instead of a fetchable CID. Defaults to disabled.²
• Funder. The wallet that paid the mailbox’s rent: yourself on a normal create, or the sponsoring domain authority on a sponsored create. When the mailbox is closed (every GUI client has a Close-mailbox action³), its rent refunds to the funder — and only ever the rent, because a mailbox never accumulates earnings (stamp value settles from the sender’s frombox through the message account to you on delete).

Creating a mailbox also claims an alias

Creating a mailbox does one more thing besides writing these settings: it automatically registers your wallet’s own address string as a self-alias pointing back at you. That claim is a spoof guard, not a convenience — address resolution checks the alias registry before treating a string as a raw wallet address, so an unclaimed address string could otherwise be registered as someone else’s alias, silently intercepting mail meant for your wallet. See Aliases for the full explanation from the alias side, including why most users never need to register an alias by hand.

Sponsored mailboxes: a domain provisions for its users

Normally the wallet that signs a mailbox create is the wallet the mailbox belongs to. A domain’s on-chain authority may additionally provision a mailbox for a different owner — an employer setting up receiving mailboxes for its staff’s wallets under the corporate domain before those wallets have ever transacted. Three guards keep this from becoming a spam or squatting vector:

• Only the named domain’s registered on-chain authority may pay for another owner’s mailbox; anyone else is refused.
• The new mailbox’s default postage is forced to the 1-SOL spam floor, whatever the sponsor asked for — a sponsor cannot open cheap send channels into a stranger’s mailbox. The owner lowers prices for known senders afterwards, exactly as with a self-created mailbox.
• No self-alias is bundled (the sponsor must not squat the owner’s address string); the owner claims their own alias when they first act.

The sponsor is recorded on-chain as the mailbox’s funder, and closing the mailbox refunds its rent to the sponsor rather than the owner. In every other way the mailbox belongs wholly to the owner from the moment it exists: the sponsor keeps no control over it.⁴

Opting out of IPFS storage

A mailbox’s no-IPFS setting (above) is off by default, meaning delivered bodies are pinned to public IPFS and the on-chain message carries a fetchable CID. Turning it on is a deliberate trade: your operator keeps the sealed body in its own store instead, and decentralized clients like the trustless viewer can no longer read it — availability then depends entirely on that one operator. See IPFS storage: benefits to users for the full trade-off, and Create a mailbox or Update a mailbox for how to set it.

Mail is sealed to your wallet by default

Mail bodies are encrypted before they are pinned to IPFS, so that only the mailbox owner can read them, and this needs no setup at all by default. A wallet address is an Ed25519 public key, and its X25519 twin is a valid encryption key: mail servers seal every message straight to the recipient’s wallet address as a libsodium sealed box — no published key, no key account, no rent. See Appendix: How sealed-box encryption works for a full walkthrough of the protocol, with diagrams. Decrypting is just a matter of having the wallet keypair file.

Hardware and browser wallets are the exception: they only sign, and never reveal the secret needed to derive the wallet’s decryption key. Such users instead generate a delegated X25519 keypair client-side and publish its public key on-chain as an optional mailbox setting; mail servers then seal to the published key instead of deriving one from the wallet address, and the delegated key file (not the wallet keypair) opens the mail. Every GUI client’s Encryption-key pane publishes, rotates, and clears the delegated key — see the Chrome or Outlook client pages.⁵

1. From the terminal: Looking up a mailbox. ↩

2. Set it at create or update time from the terminal: Create a mailbox or Update a mailbox. ↩

3. From the terminal: Close a mailbox. ↩

4. Sponsors are typically domain operators scripting provisioning — see Create a mailbox — sponsored creation for the command. ↩

5. From the terminal: Mailbox keys. ↩