Hosted email infrastructure

Your mail, hosted properly — sealed shut when you ask it to be.

Vellumail is a fully hosted mail platform — we run the SMTP, IMAP, JMAP, and CardDAV servers for you, built from first principles, not stitched together from Postfix and Dovecot. Every mailbox we host is encrypted at rest by default; any mailbox can go further, into a mode where not even we can read it.

Get started See pricing

What's included

One hosted platform, every protocol a mailbox actually needs.

No bolt-on plugins. Each of these is implemented directly, and they all read and write the same encrypted store — a contact added over CardDAV shows up instantly in JMAP; a folder made in webmail shows up instantly over IMAP.

Full protocol stackSMTP · IMAP · JMAP · CardDAV: Inbound mail and authenticated submission, an IMAP server with CONDSTORE/QRESYNC and UIDPLUS for efficient client sync, JMAP for modern mail clients, and CardDAV/JMAP Contacts sharing one address book.
Encrypted at rest, alwaysAES-256-GCM envelope encryption: Every message body is ciphertext in the database by default. Each mailbox gets its own data key, wrapped by a master key we hold on our infrastructure — a stolen database dump is noise without it.
Zero-knowledge, on requestopt-in, per mailbox: A mailbox can go further: its private key is wrapped by its own password and a one-time recovery key instead of our master key. From that point on, only the account holder can unlock it - not an administrator, not a stolen key.
Mail that arrives verifiedDKIM · SPF · DMARC: Outbound mail is signed automatically. Inbound mail is checked against the sender's own SPF, DKIM, and DMARC records, with organizational-domain alignment and daily aggregate reports sent back to domains that ask for them.
Filtered before it landsheuristic spam scoring + ClamAV: A built-in scorer and antivirus scanning both run inline on every inbound message - no external daemon to babysit, no mail delivered unscanned without you knowing about it.
Webmail that feels consideredserver-rendered, no JS framework: Read, compose, reply, forward, and file mail from a fast, responsive client that respects light and dark system themes, shows unread counts and optional desktop notifications for new mail, and configures itself for other clients via Autoconfig, Autodiscover, and DNS SRV records.
Team inboxes, not shared passwordsshared mailboxes: Give people read-only or read/write access to a shared address like sales@ or support@ without a password anyone has to know or rotate - access is granted and revoked per person, any time.
Mail that sorts and forwards itselfrules, folders & forwarding: Rules file incoming mail into folders automatically by sender, subject, or body - in order, first match wins, and never overriding spam or authentication checks. Any mailbox can also forward a copy on to another address, with or without keeping a local copy.
Signatures, set once, everywhereper-mailbox + domain defaults: Every new mailbox gets a signature generated from the person's name and title alongside your domain's company name, phone, website, and logo - editable any time, never re-applied without asking.
Properly isolated infrastructuremulti-tenant hosting: Your domain runs on infrastructure kept separate from every other organization we host - sharing the platform, never a queue, a database, or a mistake belonging to someone else.

Security

Sealed, not just locked.

Every mailbox we host already keeps mail encrypted while it sits on disk. Zero-knowledge mode changes who holds the key - moving it from us to the account holder alone.

Standard mailbox

Encrypted at rest (AES-256-GCM)
Key held on our infrastructure, wrapped by a master key
Password reset by an administrator, any time
The default for every mailbox we host

Zero-knowledge mailbox

Encrypted at rest (AES-256-GCM), same as standard
Key held only by the account's password + recovery key
No administrator override - lose both, and the mail is gone
Opt in per mailbox, any time, one-way

That last line is deliberate, not a limitation we're hiding: a recovery path we could always use ourselves is a backdoor by another name. Vellumail doesn't keep one.

Acceptable use

Strict on spam, on purpose.

Vellumail is built for ordinary personal and business correspondence - not newsletters, marketing blasts, or any other bulk/one-to-many mail, even to recipients who agreed to receive it. That's not just a policy line: it's enforced technically on every message we send.

What we block outright

Mail carrying newsletter/mailing-list headers (List-Unsubscribe, List-Id, Precedence: bulk) - rejected at send time, no exceptions
A hard daily cap on distinct recipients per mailbox
Attempts to route around rate limits or spam/authentication checks

If our IP gets blacklisted anyway

We automatically trace it back to the exact mailbox and account responsible - no guesswork, no innocent accounts caught up in it
That one mailbox is banned from sending immediately (it can still receive mail; its owner can still log in)
A fixed remediation fee is charged, and the account's mail flow is held until it's paid - then everything resumes automatically

We host mail for every customer on shared infrastructure alongside each other - one account sending spam puts everyone else's deliverability at risk. Detecting and acting on it automatically, the moment it happens, is how we keep that from being anyone else's problem. Full detail in our Terms and Conditions.

Deliverability

Your mail leaves from the right IP, every time.

A surprisingly common cause of mail silently bouncing has nothing to do with reputation at all: a mail server with more than one network path lets the operating system pick whichever IP happens to suit its routing table for a given destination - not necessarily the IP your MX record, reverse DNS, and SPF record were actually built around. We don't leave that to chance.

Included for every account

Every outbound connection is explicitly bound to our intended sending IP - never left to routing-table guesswork
That IP is exactly the one your MX, reverse DNS (PTR), and SPF record already point to, so nothing about how mail authenticates is ever left ambiguous
We proactively monitor that IP against major DNS blocklists and act the moment anything changes - see "Strict on spam, on purpose" above

Dedicated outbound IP — add-on, £5.00/month

An outbound-sending IP address used only by your account - not shared with any other Vellumail customer
If another tenant's mail ever gets our shared IP blacklisted, your mail keeps flowing, completely unaffected
Add or cancel any time from your account - billed as a single line item on your existing subscription, and your SPF record updates itself automatically the moment you subscribe

Outbound only - your inbound mail, MX records, IMAP, JMAP, and CardDAV are completely unaffected either way. Most accounts never need the dedicated IP; it exists for the ones that want their deliverability entirely isolated from every other tenant we host.

Architecture

Built from the studs, not stitched together.

No Postfix, no Dovecot, no wrapping someone else's mail server and hoping the seams hold. Every protocol below is implemented directly against one encrypted store, and it's what we run for every mailbox we host.

SMTP :25 / :587 IMAP :143 / :993 JMAP (HTTPS) CardDAV (HTTPS) Webmail

One encrypted store MySQL/MariaDB · AES-256-GCM · per-mailbox keys

Standards it actually speaks

IMAP RFC 3501, 7162, 4315 CONDSTORE / QRESYNC / UIDPLUS JMAP RFC 8620, 8621 Core, Mail, EmailSubmission Contacts RFC 6352, 9553 CardDAV + JMAP Contacts, shared storage Mail auth RFC 7208, 6376, 7489 SPF, DKIM, DMARC (+ aggregate reports) Discovery RFC 6186 Autoconfig / Autodiscover / DNS SRV Transport RFC 8314 Implicit TLS (IMAPS :993, SMTPS :465)