Point a domain at MailVault and every address on it becomes something your code can create, route and retire — from a terminal, a script, or an agent. No dashboard required, and nothing of yours is stored.
# point a domain at mailvault and route its mail
$ mailvault domain add example.com
Publish this DNS MX record so mail reaches the server:
name: example.com
priority: 10
value: mx.mailvault.sh
$ mailvault domain verify example.com
status: verified
$ mailvault addr add hi@example.com --to you@gmail.com
address: hi@example.com
forwards to: you@gmail.com
# and because it is scriptable, so is everything else
$ mailvault --output json addr list | jq -r '.[].local_part'Why another forwarder
Forwarding itself is a commodity. What is not is treating your mail as something we should be structurally unable to read — and building an interface your code drives rather than your mouse.
The rest is table stakes and we treat it that way: SPF, DKIM, DMARC, blocklists, MTA-STS and TLS reporting run on every message. One detail is worth naming, because it is the part most forwarders get wrong — mail is relayed byte for byte, so the sender’s original DKIM signature survives intact and still passes DMARC at the destination.
How it works
Install once with go install, or grab a binary. The CLI prints the exact DNS records to publish — including the MX — and tells you when they have taken effect.
MailVault issues a TXT record proving you own it, and the MX record that routes mail to us.
mailvault domain add
Checks DNS and reports a distinct exit code for “not propagated yet”, so a polling script knows to wait rather than fail.
mailvault domain verify
Aliases, or a catch-all written the way you would address it. Change destinations any time without touching DNS.
mailvault addr add
Availability
MailVault runs real mail today, for a small number of domains. We are widening access gradually rather than all at once, so that deliverability and support keep up with the load.
Request a seat and we will get in touch as the next wave opens. No card, and nobody is charged for joining the list.
Available now and not gated on anything. It is the same code the hosted service runs — one Go binary, a Postgres database, and a relay.
Roadmap
Every product below is the same idea pushed further: mail infrastructure that cannot read your mail. Forwarding keeps nothing. Everything after it keeps only ciphertext.
Domains, aliases and catch-alls, driven from the CLI or the API. Messages are authenticated on arrival and relayed onward without being queued, parsed or copied.
Mail as a webhook, but the payload is encrypted to your endpoint’s public key before it leaves us — so we deliver a message we cannot read, and neither can anything between. Every other inbound-parse service posts your mail as plaintext JSON. Signed-plaintext mode stays available for endpoints that cannot hold a key.
Keep mail instead of only passing it on — encrypted to a key derived on your machine, so the server stores ciphertext it has no way to open. The private key never leaves the client.
Give an assistant its own address and its own key. It can read and send on that address alone, and is cryptographically unable to touch any other — an inability, not a permission setting that can be misconfigured.
Sign forwarded mail with your domain’s own key, return bounces to the original sender, and send transactional mail from the addresses you already receive on — the same authentication posture in both directions.