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 holding as little of your mail as the job allows, for as short a time as possible — 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.
And one we would rather state than let you assume: authenticating a message means reading it. Mail reaches us over TLS and is decrypted in our process so SPF, DKIM and DMARC can check it — any provider that runs those checks does the same, whatever their marketing says. What we can promise is what happens next, and it is the whole design: nothing is written down, nothing is queued, nothing is copied, and where mail is handed onward it leaves encrypted to a key only you hold.
How it works
Early-access accounts get the CLI and an API key. 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 to your mailbox, or a catch-all delivered to your endpoint. Change destinations any time without touching DNS. Follow the quick-start.
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.
Arrives with the open-source release: the same code the hosted service runs — one Go binary, a Postgres database, and a relay. Until then, tell us about your setup and we will keep you posted.
Roadmap
Every product below is the same idea pushed further: hold as little as possible, for as little time as possible. Forwarding keeps nothing at all. Everything after it keeps only ciphertext.
Domains and aliases, driven from the CLI or the API. Messages are authenticated on arrival and relayed onward without being queued, parsed or copied. Read the forwarding quick-start.
Mail as a webhook, with the payload encrypted to your endpoint’s public key before it leaves our server and nothing kept afterwards. Every other inbound-parse service posts your mail as plaintext JSON. A catch-all delivers here and only here, so every address on a domain can reach one service without a single guess being relayed onward. An endpoint proves it wants mail before any is sent to it, every delivery is signed so you can tell it came from us, and a signed-plaintext mode stays available for receivers that cannot hold a key. Read the quick-start and receiver guide.
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.