DNS setup

Two independent sets of records matter to a SithBit operator: the classic mail records that let the rest of the internet find and trust your server, and the SithBit-specific record that proves you control a domain before it is authorized on-chain.

Throughout, example.com is the mail domain (the part after @) and mail.example.com is the host running sithbitd.

Receiving mail: MX

example.com.        MX  10  mail.example.com.
mail.example.com.   A       203.0.113.25

The MX target must be an A/AAAA name, not a CNAME. Add example.com to [smtp] local_domains in sithbitd.toml so the MX listener accepts mail for it, and set [smtp] hostname (and [spooler] hostname) to mail.example.com so the EHLO greeting matches DNS — many receivers score a mismatch as spam.

One server may host several mail domains: point each domain’s MX at the same host and list them all — local_domains = ["example.com", "example.net"]. Each domain needs its own on-chain authorization (below) under the same authority key, its own DKIM record and [[spooler.dkim]] entry, and the daemon warns at startup about any listed domain whose on-chain authority doesn’t match (see the configuration reference).

Inbound sender checks (sender_auth = "spf", the default, or "dmarc-lite") need nothing from your DNS; they query the sender’s records.

Sending mail: SPF, DKIM, DMARC, PTR

Receivers judge your outbound mail by these records; without them, expect the spam folder.

SPF — authorize your relay host to send for the domain:

example.com.  TXT  "v=spf1 mx -all"

mx authorizes whatever your MX records point at; add ip4:/ip6: mechanisms if outbound mail leaves from other addresses, or include: your smarthost provider when [spooler.smarthost] routes mail through one.

DKIM — sithbitd signs authenticated submissions (rsa-sha256, RFC 6376) when [spooler.dkim] is configured. Generate a key and publish its public half at {selector}._domainkey.{domain}:

openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out dkim.pem
openssl rsa -in dkim.pem -pubout -outform DER | openssl base64 -A

[spooler.dkim]
domain = "example.com"
selector = "mail"
key_file = "dkim.pem"     # PEM, PKCS#8 or PKCS#1

mail._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=<the base64 output>"

Only authenticated submission is signed — mail arriving at the MX from other servers relays unsigned, which is correct: it isn’t yours.

DMARC — tell receivers what to do when SPF/DKIM fail, and where to send reports:

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

Start with p=none while you confirm SPF and DKIM pass, then tighten.

PTR — the reverse record for your outbound IP must resolve to your EHLO hostname (203.0.113.25 → mail.example.com). This is set with your hosting provider, not in your zone; several large receivers refuse mail from IPs without a matching PTR.

Authorizing a domain on-chain

Before wallets can register aliases and mailboxes under @example.com, the domain must exist as an on-chain Domain account — created by the postmaster for a claimed authority key. The domain-sithbit service automates the claim with a DNS proof:

1. The domain owner generates (or picks) an ed25519 keypair and publishes its public key, base58-encoded, as a TXT record:

   _solana.authority.example.com.  TXT  "<base58 ed25519 public key>"
   

2. POST /domain on the domain-sithbit service with the domain name as the body. The service resolves that TXT record, validates the key, and — signing with its configured postmaster key — submits CreateDomain naming the key as the domain’s authority.

3. GET on the same service answers what the TXT record currently claims, which is useful for checking propagation before posting.

Operational notes:

• Without a configured postmaster_key_file, POST /domain replies 503 — DNS lookups still work. See the configuration reference.
• The TXT lookup goes to a public resolver, so freshly published records may take a propagation delay to become visible.
• The authority key is a real signing key — the mail server submits SendMail with it — so store it like a wallet, not like a DNS token. The TXT record can be removed after authorization; the on-chain account is what matters from then on.
• The same authority key can claim any number of domains: publish the same public key in each domain’s TXT record and POST each claim. A multi-domain server authorizes every domain it serves under its one gateway key this way.

See Domains for what a domain account contains and the CLI flows the postmaster can drive by hand.