Stalwart | Stalwart Blog

DKIM2 and DMARCbis have landed, and Stalwart speaks them first

Mon, 06 Jul 2026 00:00:00 GMT

Email authentication has quietly held the internet’s mail together for two decades, and it has just taken its biggest step forward yet. Two efforts arrived at once. DKIM2 (currently at draft -04) reworks DKIM so that a signature is no longer a lonely statement about content but one link in a verifiable chain of custody that follows a message from author to final recipient: forwarding stops breaking signatures, replayed mail no longer verifies, and a bounce can prove it is genuine. DMARCbis (published in May 2026 as RFC 9989, RFC 9990, and RFC 9991) is the long-awaited successor to DMARC: it replaces the static Public Suffix List with a live DNS tree walk, retires the tags that never worked, and folds a decade of hard-won operational lessons back into the standard.

Both matter because email authentication is what keeps a phisher from putting your bank’s domain in the From: line, and until now the machinery that does it has been showing its age. This post walks through what each protocol changes and why it matters.

It is also an announcement. As of Stalwart v0.16.12, both DKIM2 and DMARCbis are fully implemented, and Stalwart is the first mail server to support them. Anyone curious can sign and verify DKIM2 messages, and run DMARCbis checks, directly from the browser at the mail-auth playground, no install required. More on that at the end; first, the protocols.

Meet DKIM2

DKIM (DomainKeys Identified Mail, RFC 6376) does one deceptively simple thing: it lets a domain take responsibility for a message. The sending server hashes a chosen set of header fields and the body, signs the result with a private key, and staples the outcome to the message in a DKIM-Signature header. The matching public key lives in DNS at selector._domainkey.domain, so any receiver can fetch it, recompute the hashes, and confirm two things: the message really was authorised by that domain, and nothing covered by the signature changed along the way.

That is the whole promise. A valid signature means “this domain vouches for this content.” It says nothing about who the message was for, where it has been, or where it is going next. For nearly twenty years that was enough, and DKIM quietly became one of the load-bearing walls of email authentication.

On its own, a DKIM pass is just a true statement about some domain. DMARC is what turns it into a decision. DMARC ties authentication to the domain a human actually sees, the one in the From: header, through a rule called identifier alignment: a DKIM result only counts toward DMARC if the signing domain (d=) lines up with the From: domain. Pass alignment on either DKIM or SPF and the message clears DMARC; fail both and it meets the domain’s published policy, which can mean quarantine or outright rejection.

This is exactly why a broken DKIM signature is not a cosmetic problem. When DKIM breaks on a message from a domain publishing p=reject, and SPF cannot save it either, that message is gone. Which brings us to the reason DKIM2 exists: over two decades of real-world routing, DKIM1 signatures break far more often than anyone would like, and in a few cases they hold when we wish they wouldn’t.

Issues with DKIM1

None of what follows is a knock on the original design. These are the seams that two decades of deployment pulled apart, and they are the exact list DKIM2 sets out to close.

Anyone could be the recipient. A DKIM1 signature is bound to the content, not to a destination. Capture one legitimately signed message and you can replay it to millions of other addresses, unchanged, and every copy still verifies. The replay rides on the original signer’s good reputation, which is precisely what makes it valuable to abusers.
Forwarding breaks the signature, silently and ambiguously. The moment a mailing list tags a subject, a gateway rewrites a link, or a forwarder appends a footer, the signed hashes no longer match and the signature fails. Worse, a verifier cannot tell an innocent [list] prefix from wholesale replacement by an attacker. Both look identical: broken.
There was no record of the road travelled. DKIM1 leaves no trustworthy trace of the path a message took. The Received and Return-Path headers are unauthenticated and trivial to forge, so there is no chain of custody to reason about.
ARC was a patch that receivers struggle to trust. ARC tried to preserve authentication across intermediaries by having each hop attest to what it saw, but it sits alongside DKIM as a separate overlay, and in practice most receivers report that they cannot confidently trust ARC seals.
Header signing was inconsistent. DKIM1 lets the signer choose which headers to cover and offers multiple canonicalization modes, which leaves gaps an attacker can slip unsigned headers through and makes signatures needlessly fragile.
Bounces could not be trusted, and hurt bystanders. Because the return path can name a domain that never handled the message, a Delivery Status Notification (DSN) can land on a forged, innocent third party. This is backscatter, and the fear of it is why deferred bounces, the kind a provider would send after deciding a message is spam an hour later, are largely impractical today.
Feedback was ad hoc. Intermediaries and senders exchange informal signals about how mail is performing, but there is no standard for requesting or routing that feedback, so it is inconsistent and often unhelpful.

DKIM2, in a nutshell

DKIM2 keeps everything that worked and changes the thing that did not. The cryptography is familiar: hash the message, sign it, publish the public key in DNS at the same _domainkey location DKIM1 already uses. What changes is that a signature stops being a lonely statement about content and becomes one link in a verifiable chain of custody that follows the message from originator to final recipient.

To do that, DKIM2 splits the old single header into two, each with its own job.

The Message-Instance header describes the message at a point in time. It carries a revision number, a set of cryptographic fingerprints over the headers and body at that revision, and, when a hop has changed something, a compact “recipe” that spells out how to undo the change (the mechanism covered later that makes forwarding survivable).

The DKIM2-Signature header records the envelope the message actually travelled with, then signs over it. Alongside the familiar DKIM pieces, the signing domain, the selector, the signature itself and a timestamp, it captures the SMTP MAIL FROM and RCPT TO of that hop, a sequence number so the signatures form an ordered chain, and a small set of flags that a sender or intermediary can raise to forbid fan-out, mark legitimate fan-out, or request feedback. Putting the envelope inside the signature is what lets consecutive hops be checked for consistency; recording who signed and in what order is what turns a pile of signatures into a chain.

Two counters drive everything. One counts signatures, one per hop. The other counts message revisions, incremented only when a hop actually changes the content. A purely transparent forwarder that touches nothing does not even need to be DKIM2-aware.

One mechanism per broken promise

The elegance of DKIM2 is that a handful of mechanisms retire the whole list above at once.

Replay is answered by putting the envelope inside the signature. Each DKIM2-Signature records the MAIL FROM (mf=) and RCPT TO (rt=) it was sent with, and consecutive hops must line up: the sending domain of one hop has to match a recipient domain of the previous one. A message replayed to a different recipient no longer forms a valid chain. A sender can add donotexplode to forbid fan-out, and a mailing list marks legitimate fan-out with exploded.
Forwarding breakage is answered by recipes. A hop that modifies the message records a reversible recipe, so downstream verifiers can undo the change and re-check every earlier signature instead of throwing the whole thing out.
The missing chain of custody is the chain itself: each hop appends its own signature over the current snapshot and all prior signatures, forming a tamper-evident sequence from author to recipient.
ARC’s role is absorbed natively. The chain does what ARC attempted, without a parallel set of headers, and DKIM2 explicitly ignores both legacy DKIM-Signature and ARC-* headers so the two schemes can coexist during migration.
Inconsistent header signing is answered by a single fixed canonicalization and a defined hashing scheme, removing the per-signer guesswork.
Backscatter is answered by routing bounces along the recorded chain, covered next.
Feedback gets a standard channel through the feedback and feedhere flags.

One caveat, contrary to a common claim: DKIM2 can require more signature checks, not fewer. A modified message adds a signature at every hop, and a verifier may need to check the whole chain. What the draft does allow is checking the most recently applied signature first and stopping at the first failure, so an unmodified message can often be cleared with a single verification.

Recipes: putting a message back the way it was

This is the mechanism that makes forwarding survivable, so it is worth seeing in full.

A recipe is a small JSON object, base64-encoded into the r= tag, that tells a verifier how to turn the current message back into the previous one. It has two optional parts, "h" for header fields and "b" for the body, and each is a list of steps:

{"c": [start, end]} copies a range of lines or header instances from the current message, inclusive.
{"d": ["value", ...]} inserts literal values that used to be there.

Two numbering rules matter. Header instances are counted bottom-up (the last Subject: is number 1, the one above it is 2), and body lines are counted top-down (the first line is 1). An empty step list [] for a header means “remove every instance.” A body recipe of null is a special case: it means the previous body genuinely cannot be reconstructed, which a verifier may accept from an entity it trusts, for example a contractually arranged redaction service.

A message through two hops

Alice sends a note to a mailing list.

Hop 1, the originator signs. The message leaves example.com:

From: alice@example.com
To: list@lists.example.org
Subject: Trip report

Had a great time.
See you soon.

She stamps it with the first revision and the first signature (hashes abbreviated):

Message-Instance: m=1; h=sha256:Hh1...:Bh1...
DKIM2-Signature: i=1; m=1; t=1782394336; d=example.com;
  s=ed25519:ed25519-sha256:rDU9v...;
  mf=PGFsaWNlQGV4YW1wbGUuY29tPg==;
  rt=PGxpc3RAbGlzdHMuZXhhbXBsZS5vcmc+

The mf= value decodes to <alice@example.com> and rt= to <list@lists.example.org>.

Hop 2, the list revises. The list software tags the subject and appends an unsubscribe footer, so the message is now:

From: alice@example.com
To: list@lists.example.org
Subject: [list] Trip report

Had a great time.
See you soon.
--
Unsubscribe: https://lists.example.org/u

Two things changed: the subject gained a [list] prefix, and two lines were appended. The list computes the recipe that reverses both. The subject (one instance, so number 1) is replaced with its old literal value, and the body copies the two original lines while dropping the footer:

{"h":{"subject":[{"d":["Trip report"]}]},"b":[{"c":[1,2]}]}

Read the body step as “to rebuild the previous body, copy current lines 1 through 2, and stop.” The footer at current lines 3 and 4 simply is not copied, so it disappears on reversal. The list base64-encodes that JSON into r=, records a fresh fingerprint, and adds its own signature:

Message-Instance: m=2; h=sha256:Hh2...:Bh2...;
  r=eyJoIjp7InN1YmplY3QiOlt7ImQiOlsiVHJpcCByZXBvcnQiXX1dfSwiYiI6W3siYyI6WzEsMl19XX0=
DKIM2-Signature: i=2; m=2; t=1782394500; d=lists.example.org;
  s=ed25519:ed25519-sha256:9aBc...;
  mf=PGJvdW5jZXNAbGlzdHMuZXhhbXBsZS5vcmc+;
  rt=PGJvYkBleGFtcGxlLm5ldD4=

The chain of custody holds because hop 2’s mf= domain (lists.example.org) matches hop 1’s rt= domain (lists.example.org), and d=lists.example.org matches the rightmost labels of that mf=.

Final recipient, Bob, verifies. His server works backwards:

Check the chain lines up: hop 2’s sending domain matches hop 1’s recipient domain. Good, no replay.
Verify each signature’s cryptography over its reconstructed input.
Recompute the m=2 fingerprint against the message as received. It matches.
Apply the r= recipe to rebuild the m=1 message: restore the subject to Trip report and drop the footer.
Recompute the m=1 fingerprint against that reconstruction. It matches Alice’s original signature.

Alice’s signature validates even though the list rewrote her subject and appended a footer. And because every change is spelled out, Bob can see exactly what the list did. A footer tweak and a malicious body swap no longer look the same.

Bottom-up header numbering is not decoration; it is what keeps duplicated headers unambiguous. A recipe that deletes the middle of three Subject: headers, for instance, reads as copy the bottom one, insert the deleted literal, copy the top one:

{"h":{"subject":[{"c":[1,1]},{"d":["four"]},{"c":[2,2]}]}}

And a hop that redacts content under an arrangement the verifier trusts marks the body as unreconstructable rather than pretending it can be undone:

{"b":null}

The chain still verifies up to that point; the body just cannot be rewound past it.

Bounces carry their own proof

The same chain that stops replay also fixes bounces, and this is where DKIM2 quietly closes the backscatter problem for good.

First, DKIM2 stops trusting the headers that lie. Received and Return-Path are ignored outright. The authoritative return address is reconstructed from the signed mf= tags in the chain instead. The rule is blunt: a DSN must be addressed to the mf= of the highest-numbered DKIM2-Signature, that is, the hop that actually handed the message over, never the visible envelope sender. And if that mf= is the null reverse path (mf=<>), no DSN is sent at all. Backscatter has nowhere to land.

Better still, a DKIM2 bounce can prove it is genuine. A DSN is itself an ordinary DKIM2 message: a multipart/report sent with MAIL FROM <>, carrying its own Message-Instance and DKIM2-Signature, that embeds the original signed message (as a full message/rfc822 copy or just its text/rfc822-headers). Because the original’s signature chain travels back inside the bounce, the receiver should re-verify the whole thing:

The DSN’s own signing domain should align with the recipient recorded in the returned message’s last rt= tag.
That returned message’s last signature should be one this system actually produced, checked against its d= and mf=.
The embedded message’s headers, and its body if present, verify against the Message-Instance fingerprints.

Pass all three and the bounce is provably about a message you really sent to a recipient you really handed it to. Fail, and it must not be propagated further. That is what finally makes deferred bounces safe: a provider can accept a message, decide an hour later that it is spam, and send a signed bounce back along the recorded path, with no risk of mailbombing an innocent bystander. As the DSN travels back, each hop peels off the signature it added and forwards the bounce one step further toward the origin, so every party learns only about its own leg of the journey.

A signature that used to vouch only for content now vouches for the entire journey: who sent it, who it was for, what each hop changed, and where a failure is allowed to go.

ARC steps aside

DKIM2 is not the first attempt to keep authentication alive across forwarders. ARC (RFC 8617) got there first, and it is worth a moment because it explains a lot about the shape of DKIM2. When an intermediary changed a message and broke DKIM, ARC let that intermediary record what it had seen just before the change and add its own signature. Each hop stamps an ARC set of three headers: ARC-Authentication-Results captures the authentication verdict the hop saw on input, ARC-Message-Signature signs the message as the hop passed it on, and ARC-Seal signs the chain so far. A downstream receiver could confirm the chain was cryptographically intact and read the upstream verdicts.

The catch is that ARC records observations, not changes. A valid chain proves a message was handled, not that the handling was correct, and it never says what was actually modified. To act on an ARC chain a receiver has to decide whether it trusts every signer in it, which in practice means running a reputation system for thousands of forwarders across the open internet. That trust fabric never materialized. A decade on, there is no working internet-scale ARC reputation deployment and no plan for one, so early adopters fell back to hand-maintained allow lists of known intermediaries: useful inside a data center or a consortium, not on the wider internet. Receivers were also left to invent their own policy for how many hops to honor and how to treat partial or broken chains, so behaviour never converged. The IETF’s DMARC working group is now moving to reclassify RFC 8617 as Historic and discourage new deployments (draft-ietf-dmarc-arc-to-historic).

DKIM2 removes the very thing that made ARC unworkable: the separate trust fabric. Rather than ask a receiver to trust an intermediary’s account of what it saw, DKIM2 has each hop record exactly what it changed as a reversible recipe. The verifier undoes those changes and re-checks the originator’s own signature, so trust flows back to the domain that actually authored the message rather than to every forwarder along the way. And because the recipe spells out each modification, a receiver can tell an innocent subject tag from something worth worrying about, the “what changed” question ARC left open. The handling assertions ARC was genuinely good at fold into the same chain, with no parallel reputation system holding them up.

Meet DMARCbis

After more than a decade of RFC 7489 doing quiet, load-bearing work behind the world’s inboxes, DMARC has a proper successor. In May 2026 the IETF published three new Standards Track documents, RFC 9989, RFC 9990, and RFC 9991, collectively known as DMARCbis. They obsolete the original 2015 specification (and fold in the experimental Public Suffix Domain work from RFC 9091).

Nothing about the day-to-day promise of DMARC has changed. What changed is the plumbing underneath it, and a few of those changes are the kind that quietly fix problems operators have lived with for years.

TL;DR

For anyone who wants the gist before the details:

The Public Suffix List is gone. Finding the boundary of an organization now happens with a live DNS lookup called the tree walk.
The pct sampling tag is retired. A simpler t testing flag takes its place.
Two tags graduate from the experimental PSD extension into the core spec: np for non-existent subdomains and psd for public suffix operators.
Reporting moved into its own two documents, gained a new XML schema, and picked up an extensibility slot so future additions no longer require reopening the whole standard.
p=reject is no longer treated as an unconditional instruction to bounce mail.

Existing DMARC records keep working. The retired tags are simply ignored, so there is no flag day and no forced migration.

A quick refresher on DMARC

SPF and DKIM both authenticate a domain, but not the one that matters most to a human reading their mail. SPF checks the envelope sender used during the SMTP conversation, and DKIM checks whatever domain signed the message. Neither is required to match the From: address the recipient actually sees, which is exactly the address a phisher wants to forge.

DMARC closes that gap. It anchors authentication to the visible From: domain, the Author Domain, through a property called alignment: a message passes only when SPF or DKIM authenticates a domain that lines up with the Author Domain. The domain owner publishes a policy in DNS stating what receivers should do with mail that fails (none, quarantine, or reject) and where to send reports. That combination, authentication tied to the visible sender plus a published preference plus feedback, is what made DMARC the backbone of email anti-spoofing.

Issues with DMARC

RFC 7489 aged well, but a handful of design decisions turned into recurring headaches:

The Public Suffix List was a soft spot. To tell where one organization ends and a registrar’s namespace begins (so that mail.example.com and example.com are understood to share an owner, while example.com and example.co.uk do not), receivers leaned on Mozilla’s Public Suffix List. The spec never mandated a specific copy of it, said nothing about how often to refresh it, and openly acknowledged the interoperability risk. A single static file, maintained by volunteers, sat on the critical path of global mail authentication.
The pct tag promised more than it delivered. It was meant to let a domain roll out a policy to a percentage of mail. In practice only two values behaved consistently across receivers: 0 and 100. Worse, pct=0 had quietly acquired a special meaning of its own, so the tag was really a two-state switch wearing a percentage costume.
Subdomains that did not exist were a spoofing gap. A domain could set a strict policy for itself, yet an attacker could still forge a plausible looking subdomain that had never been registered. The experimental PSD DMARC work started to address this, but it lived outside the core standard.
Everything was crammed into one document. Core protocol, aggregate reporting, and failure reporting all shared a single RFC, which meant none of them could evolve without dragging the others along.

DMARCbis, one specification becomes three

DMARCbis splits the old monolith along its natural seams so each piece can advance on its own schedule:

RFC 9989 is the core protocol: alignment, policy, record syntax, and the new discovery mechanism. It obsoletes both RFC 7489 and RFC 9091.
RFC 9990 covers aggregate reporting, the daily domain-level XML summaries that most operators actually rely on.
RFC 9991 covers failure reporting, the detailed per-message reports, and updates the older RFC 6591 reporting format along the way.

The move from a single Informational RFC to three Standards Track documents is not just bookkeeping. It reflects DMARC growing up into a first-class internet standard with the process discipline that implies.

Climbing the tree instead of trusting a list

The headline change is how a receiver figures out where an organization’s authority begins. Instead of consulting a static list, DMARCbis defines the DNS tree walk: a live, ordered series of DNS queries that climb from the Author Domain toward the root until they find the records that apply.

The receiver always queries the full Author Domain first, at _dmarc.<author-domain>. If nothing definitive turns up there, the walk begins: it drops labels from the left and queries the parent, then that parent’s parent, and so on toward the root. To keep a pathologically long domain from turning into a flood of lookups, the algorithm is capped at eight queries. For names of eight labels or fewer it strips one label at a time, but for anything longer it removes several labels at once so that only seven remain, then continues one label at a time from there. Eight was not arbitrary: names of up to seven labels were observed in real use, so the cap clears actual traffic while still bounding the work.

The canonical illustration from the spec makes the cap concrete. For a.b.c.d.e.f.g.h.i.j.mail.example.com, a receiver issues exactly eight queries and skips the deep intermediate labels entirely:

_dmarc.a.b.c.d.e.f.g.h.i.j.mail.example.com
_dmarc.g.h.i.j.mail.example.com
_dmarc.h.i.j.mail.example.com
_dmarc.i.j.mail.example.com
_dmarc.j.mail.example.com
_dmarc.mail.example.com
_dmarc.example.com
_dmarc.com

For the domains almost everyone actually runs, this is cheap. A name like mail.marketing.example.com resolves in a couple of lookups, and DNS caching absorbs most of the cost because the same parent records are queried over and over across many messages.

Once the walk has collected the records that exist along the path, the receiver selects the Organizational Domain with a short, deterministic set of rules, working from the longest name to the shortest:

A record that declares psd=n marks its own domain as the Organizational Domain. Stop there.
A record that declares psd=y (and is not where the walk began) means the Organizational Domain sits one label below it.
Failing both of those, the record with the fewest labels wins.

To make rule 3 concrete: for a.mail.example.com, absent any psd signals along the way, the walk settles on example.com as the Organizational Domain, exactly the answer the Public Suffix List used to hand back, now derived from live DNS instead.

The payoff is that the Organizational Domain is now defined by DNS records that the domain owner controls, rather than inferred from a file the owner has no say over. It refreshes as fast as DNS does, and it removes an entire class of “why is the PSL wrong for my domain” problems.

Tuning the record: what arrived, what retired

The record itself picked up three new tags and lost three old ones. The valid set in DMARCbis is now v, p, sp, np, adkim, aspf, fo, rua, ruf, psd, and t.

Tag	Status in DMARCbis	What it does
`np`	New	Policy for non-existent subdomains of the Organizational Domain
`psd`	New	Declares whether the domain is a public suffix (`y` / `n` / `u`)
`t`	New	Testing flag that softens enforcement without turning it off
`pct`	Removed	Percentage sampling; only 0 and 100 ever worked reliably
`rf`	Removed	Failure report format; only one format was ever deployed
`ri`	Removed	Aggregate report interval; effectively fixed at roughly one day
`v`, `p`, `sp`, `adkim`, `aspf`, `fo`, `rua`, `ruf`	Unchanged	Version, policy, subdomain policy, alignment modes, failure options, report destinations

A closer look at the newcomers:

t replaces pct with something clear. Rather than pretending to be a dial, the testing flag is a plain switch. The default t=n applies the published policy as written. Setting t=y signals that the domain is still testing, so compliant receivers step the effective policy down one level: reject behaves like quarantine, and quarantine behaves like none, with intermediaries free to apply special handling such as rewriting the From: header. Crucially, t leaves report generation untouched, so a domain can watch the reports roll in while enforcement stays gentle. It is best understood as analogous to the old pct=0 and pct=100 behavior rather than an exact reimplementation of it.

np closes the phantom-subdomain gap. It sets the policy for subdomains that do not exist at all, identified by an NXDOMAIN response as described in RFC 8020. If a name has never been registered, an attacker should not be able to send convincing mail from it, and np lets a domain say exactly that. When np is absent the receiver falls back to sp, and then to p. The mechanism leans on RFC 8020’s rule that an NXDOMAIN answer means the name and everything beneath it truly does not exist, so it is only as reliable as the DNS returning that answer as the standard requires.

psd brings public suffix operators into the fold. Registry-style domains such as a country’s gov namespace can now declare psd=y, which both anchors the tree walk and lets the operator publish a protective default for every registered name underneath. psd=n states the opposite, that the domain is its own Organizational Domain, and the default psd=u leaves the decision to the tree walk. This is the RFC 9091 experiment, now standardized and freed from its separate registry.

The sp tag, meanwhile, keeps its meaning but is redefined in terms of the tree walk: it governs existing subdomains of the Organizational Domain, and it is read only from the record discovered at that Organizational Domain, not from a record sitting on the subdomain itself.

The p=reject reality check

One change is less about syntax and more about attitude. p=reject is no longer treated as an unconditional order to bounce.

The tension is real and was debated at length. Strict rejection is what protects the largest consumer mail platforms and the billions of inboxes behind them, and nobody wanted to weaken that. At the same time, blunt rejection breaks legitimate indirect mail flows, mailing lists and forwarders being the classic casualties, and the damage lands on innocent third parties who never chose the policy.

DMARCbis threads the needle with sharper guidance rather than a weaker mechanism. Three distinct rules do the work:

Party	Guidance
Sending domain (general-purpose)	SHOULD NOT publish `p=reject` if users might post to mailing lists; ramp through `none` and `quarantine` first
Sending domain (any `p=reject`)	MUST NOT rely on SPF alone, and MUST apply valid DKIM signatures, since DKIM is what survives forwarding
Receiver	MUST NOT reject solely because a policy says `reject`; weigh other evidence before acting

The policy became a strong signal to weigh rather than a trigger to pull blindly.

Reporting grows up

Splitting reporting into its own documents came with real upgrades, not just a new table of contents.

Aggregate reports (RFC 9990) move to a new XML namespace, urn:ietf:params:xml:ns:dmarc-2.0, and gain an extensibility slot so future data can be added without breaking existing parsers: consumers simply ignore extensions they do not understand. The schema now records how policy was discovered through a discovery_method field that distinguishes the old psl from the new treewalk, reflects the t testing flag, and carries the np policy. Reporting a DKIM result now requires naming the selector, which makes the reports genuinely more useful for debugging. These reports stay privacy-safe by design: they aggregate domain-level authentication counts and carry no message content and no end-user identifying data such as recipient addresses or the IP addresses of individuals. Transport remains email, with the XML gzipped and delivered as an attachment, and external report destinations still have to prove they consented through a _report._dmarc record.

Failure reports (RFC 9991) get an honest treatment of why they are used so sparingly. Because they can carry entire messages, headers and body included, they raise real privacy and regulatory concerns, and many large providers disable them outright in favor of aggregate data. The format, updated from RFC 6591, adds a dedicated dmarc failure type and a required Identity-Alignment field that spells out which mechanisms failed to produce an aligned identifier. Generators must rate-limit what they send, and for public suffix domains they must not act on a ruf request at all unless the parties have a specific agreement in place, so a registry operator does not receive a stream of other people’s message content by default.

What stayed exactly the same

For all the moving parts, the fundamentals are untouched, which is worth stating plainly so nobody over-rotates on the release:

Alignment still works the way it always has, in relaxed and strict flavors selected with adkim and aspf.
The three policies, none, quarantine, and reject, mean what they always meant.
DMARC still evaluates only the From: header and still builds on SPF and DKIM rather than replacing them.
Records written for RFC 7489 remain valid. The retired tags are ignored, not rejected, so there is no urgent rewrite waiting on anyone’s to-do list.

DMARCbis is less a reinvention than a long-overdue tidy-up: the same protocol, with its most useful experiments promoted to the core and a decade of operational lessons written back into the spec. The tree walk alone, trading a static list for live DNS, is the kind of change whose absence will not be missed at all.

Both protocols live in Stalwart today

As of Stalwart v0.16.12, DKIM2 (draft -04) and DMARCbis are both fully implemented, and Stalwart is the first mail server to support either of them. Signing, verifying, the chain-of-custody logic, recipe reversal, bounce validation, the DNS tree walk, the new and retired DMARC tags: all of it ships and runs.

We wanted the protocols to be easy to try without setting up a server, so both are exposed in the browser. At the mail-auth playground anyone can sign a message with DKIM2 and watch it verify, break it and see the chain reject it, or run a message through DMARCbis side by side to see how the tree walk resolves the Organizational Domain. It runs Stalwart’s own authentication code compiled to WebAssembly, so what the playground shows is exactly what the server does, no install and nothing to configure.

For Rust developers, the same code is available as a library. DKIM2 and DMARCbis live in the mail-auth crate, the message authentication library Stalwart itself is built on, which also covers DKIM1, SPF, DMARC, and ARC. It is the engine behind both the server and the playground, and it is open source under the same permissive terms as the rest of Stalwart, so any Rust project can add DKIM2 and DMARCbis support by pulling in a single dependency.

Looking forward

DKIM2 and DMARCbis pull in the same direction. DKIM2 makes a signature vouch for the whole journey rather than a frozen snapshot of content. Forwarding stops breaking authentication, replayed mail no longer verifies on borrowed reputation, and bounces finally carry their own proof. DMARCbis takes the layer that ties all of this to the domain a person actually reads and rests it on live DNS the domain owner controls, retiring the tags that never worked and the static list that sat on the critical path of global mail. Neither demands a flag day: existing DKIM and DMARC records keep working, and the new mechanisms layer in alongside them.

Supporting them first is the part of this that Stalwart cares most about. Being early to a standard is how the standard gets tested against real mail before it hardens, and it is how operators who want the newest protections get them without waiting for the rest of the ecosystem to catch up. Stalwart has made a habit of shipping the latest IETF work as it lands, and DKIM2 and DMARCbis are the newest entries on that list. Try them at the mail-auth playground, read the code in the mail-auth crate, and upgrade to v0.16.12 to run them in production.

Zero open bug reports: The road to Stalwart 1.0

Sun, 21 Jun 2026 00:00:00 GMT

Today we released Stalwart v0.16.10, and it comes with a milestone we have been working toward for a while: as of today, there are no open bug reports for Stalwart. This release fixes every reported bug we have on record, both the legacy issues that had accumulated on GitHub and the reports submitted through our new support portal.

We want to be precise about what this means, because it is easy to misread. It does not mean Stalwart is bug free. No non-trivial piece of software is, and we would not claim otherwise. What it means is narrower: as of today there are no open bug reports awaiting a fix. Every issue that a user took the time to report has been triaged and resolved. New reports will arrive, and we will keep working through them, but for now the queue is empty.

That leaves 108 issues still open on the GitHub tracker. These are not bugs. They are minor feature enhancements and requests: refinements, quality-of-life additions, and ideas worth keeping on the list. We will get to them, but none of them block correct operation today.

Latest fixes

The headline of this release is RFC conformance. Stalwart v0.16.10 now passes all 309 tests of the JMAP test suite, a shared conformance effort that aims to align the behaviour of Stalwart, Cyrus, and Fastmail so that JMAP clients see consistent semantics regardless of which server they talk to. Reaching full conformance touched many corners of the JMAP implementation.

Beyond JMAP, this release implements the latest drafts from the IETF mailmaint working group. On the authentication side, Stalwart now supports the OAuth Profile for Open Public Clients along with client secret verification for confidential clients. On the IMAP side, it implements the IMAP Extension for Object Identifiers (OBJECTID+) and adds the GETJMAPACCESS command so clients can discover the JMAP session resource URL directly from an IMAP connection. We are glad to share that Stalwart Labs is coauthoring the OBJECTID+ extension together with Fastmail.

For the full list, see the release notes. We recommend everyone upgrade.

Road to 1.0

With the bug queue clear, the path to version 1.0 comes down to two pieces of work: finalizing the database schema and a focused round of performance optimization.

The first is the reason 1.0 matters. The goal is to stabilize and finalize the database schema so that it is flexible enough to avoid migrations after the 1.0 release. Stalwart is already running in production across a wide range of deployments, but committing to a stable on-disk format is a promise we only want to make once we are confident it will hold. We are taking the time now to make the schema general enough that future features can be added without forcing operators through a migration. When 1.0 ships, upgrading should stop being something you schedule a maintenance window for.

The second is performance. Stalwart is already fast, and that is not an accident: over the past year we have made substantial improvements driven directly by reports from users running it at scale, including deployments with thousands of accounts and others delivering hundreds of thousands of emails per day. Those real-world workloads have been the best optimization guide we could ask for. For 1.0 we want to push further in two specific areas.

The first is the internal full-text search engine, which matters most for users who do not run an external Elasticsearch or Meilisearch backend and rely on the built-in indexer instead. We want search to be fast out of the box, without an external dependency. The second is a systematic pass over the hot paths in the codebase: benchmarking the code that runs most often to find concrete optimization opportunities, whether that means vectorizing an inner loop, reworking a data structure, or rewriting a section for better cache behaviour. The point is to let measurements, not guesses, decide where the effort goes.

ETA

We expect to release Stalwart 1.0.0 this year, most likely around October and hopefully sooner. Schema work and performance work are both the kind that reward patience, so we would rather give a realistic window than a date we cannot keep. We will keep you posted as the schema settles and the benchmarks come in.

In the meantime, v0.16.10 is the most conformant and most thoroughly debugged release we have shipped. Thank you to everyone who filed an issue, opened a ticket on the support portal, or sent us a reproducer. An empty bug queue is your work as much as ours, and it is the best possible foundation to build 1.0 on.

Migration proxy: zero-downtime upgrades

Wed, 10 Jun 2026 00:00:00 GMT

A good number of Stalwart deployments are still running an old release, some on v0.15 and some as far back as v0.11, and in most cases not by choice. Upgrading between versions on a populated server has meant migrating the stored data onto a new on-disk schema, and migrating data means downtime, and downtime on a mail server is the one thing nobody wants to schedule. So the upgrade keeps getting postponed, and a deployment that should be on the current line stays where it is. We promised a way out of that bind: a zero-downtime migration path built from two tools that work together.

The first of those, Vandelay, shipped a couple of weeks ago. It is the transfer tool, the part that moves an account’s data, its mail, calendars, contacts, filters and files, from one server to another, one account at a time.

Today we are shipping the second and final component, the migration proxy, and with it the full workflow is complete. A live production deployment can now move from an older Stalwart version to v0.16 on an account-by-account basis, with no scheduled maintenance window and nothing for end users to reconfigure. What makes that possible is the proxy standing in front of both the old and the new deployment as a single endpoint, routing each connection to whichever server currently owns the account behind it.

A single endpoint in front of two deployments

The proxy sits on the public mail and web ports that clients already use and terminates each protocol far enough to see who is connecting. From the credentials the client presents, its IMAP, POP3, SMTP, ManageSieve or JMAP login, it derives which account the connection belongs to, looks up which of the two deployments currently owns that account, and bridges the session to it. Because the decision comes from the login itself, clients keep the same hostname, the same ports and the same passwords throughout, and nothing on their devices changes.

Inbound mail is handled without needing a login to route on. The new deployment becomes the public mail exchanger for the duration of the migration and performs split delivery: a message for an account that has already moved is delivered locally, while a message for an account that still lives on the old server is relayed there. Mail never has to be repointed in the middle of the migration, and it keeps flowing to every account regardless of which side currently holds it.

Moving an account is then a small, self-contained operation. Vandelay copies the account’s mail, mailboxes, sieve scripts, contacts, calendars and files into the new deployment while the account continues to be served from the old one, so the work is invisible to its owner. When the copy has been verified, a single routing entry is flipped and the account’s next connection lands on the new server. The switch disconnects any live session, which reconnects on its own, and that is the entire visible effect. Until an account accumulates new data on the new server the move stays fully reversible, because the old copy is never removed. The result is that a gradual, account-by-account, reversible migration looks, from the outside, like an ordinary server that never went down.

Migrating from other self-hosted systems

Although the immediate reason we built the proxy was Stalwart-to-Stalwart upgrades, the same model works for moving onto Stalwart from another self-hosted mail server. Legacy stacks built on Dovecot and Postfix, the foundation of distributions such as Mail-in-a-Box and mailcow, can sit behind the proxy exactly as an older Stalwart does. The proxy announces the real client to those backends over XCLIENT and the IMAP ID rather than the PROXY protocol, and Vandelay reads their data over IMAP, ManageSieve, CalDAV and CardDAV instead of JMAP, but the shape of the migration is the same: front both servers, copy each account, flip it over, keep a way back. For operators who have been looking for a path off an aging self-hosted deployment and onto a modern open-source server, this is that path, and it comes without a flag day.

Documentation and where to start

Alongside the proxy we are publishing the documentation we promised when Vandelay shipped: a complete, step-by-step migration guide that covers the whole workflow end to end. The migration overview introduces the two tools and how they fit together, and the migration guide walks through the entire procedure, from installing the new deployment and configuring the proxy to moving accounts one at a time, validating each one, and finalizing the migration once the old server is empty. The proxy itself lives on GitHub, with its own reference documentation for every configuration option.

Upgrading to v0.16 now, or waiting for 1.0

With the migration path complete, the question many operators will reasonably ask is whether to move to v0.16 now or hold out for the next milestone. Stalwart 1.0 is planned for release later this year, and it is worth being clear about how it relates to v0.16.

We do not foresee 1.0 introducing the kind of major breaking changes that earlier upgrades did. v0.16 is already very close to what 1.0 will be, and the heavy architectural work that made previous upgrades disruptive is behind us. What remains before 1.0 is a final round of performance and code optimization, and until that review is finished we cannot yet promise that the current database schema is final. If it does change, we intend for 1.0 to be an automated upgrade from v0.16 that detects any schema difference and migrates it in place, so that going from v0.16 to 1.0 is a routine update rather than another migration exercise.

What this means in practice is straightforward. Operators who need something in v0.16 today, whether a specific feature or simply a supported path off a much older release, can migrate now with no downtime, and as described above our aim, though not yet a guarantee, is for the later step to 1.0 to be a routine, automated upgrade rather than another migration. Operators who are comfortable where they are and do not need anything in v0.16 with any urgency may prefer to wait for 1.0 and make a single move then. Both are sound choices, and the difference between them is only timing. For the first time, that timing is no longer dictated by how much downtime a migration would cost.

Vandelay: the JMAP importer-exporter

Fri, 29 May 2026 00:00:00 GMT

A good number of Stalwart deployments are running an older version not because the operators want to be, but because they cannot afford the disruption. Upgrading across a major release sometimes means migrating off an older on-disk schema, and migrating data means downtime, and downtime on a mail server is the one thing nobody wants to schedule. So the upgrade gets postponed, again, and a deployment that should be on the current line stays where it is. The question we get asked most often is when we will ship something to fix exactly this.

We have said before that the right answer is a zero-downtime migration path, built from two parts: a proxy that sits in front of both the old and the new server so that clients keep working throughout, and a transfer tool that moves account data from one to the other. Today we are shipping the first of those two parts.

It is called Vandelay, and it is a one-shot account migration and backup utility for JMAP. Yes, it is named after Art Vandelay, the importer-exporter George Costanza made up as a cover story on Seinfeld. The tool imports and it exports, so the reference wrote itself.

What Vandelay does

Vandelay is the JMAP analogue of imapsync, generalized from mail to every JMAP data type: mail, contacts, calendars, identities, sieve scripts, and file storage. It works in two stages that never talk to each other directly. An import reads a source account into a local SQLite file that Vandelay calls an archive; one archive holds exactly one account and fully describes it on its own. An export then pushes an archive into a target JMAP server. Because import and export only ever touch the archive, never each other, the two halves are completely decoupled: you can import today and export next week, import from one protocol and export to JMAP, or keep the archive around and do nothing with it at all.

A few properties make it pleasant to operate at scale. Both halves are convergent, so re-running an interrupted import or export simply picks up where it left off, with no bookkeeping flags to reset and no half-finished state to clean up; re-running an import later also catches anything new since the last snapshot. Every command takes --dry-run, which computes the full plan without writing anything, so you can see exactly what a run would do before it does it. Emails, sieve scripts, and file payloads are content-addressed, stored once by their hash and deduplicated across the archive. Work runs multi-threaded across a worker pool sized to your CPUs, with per-server connection caps respected automatically and no async runtime involved. And each archive remembers which account filled it, so pointing it at a different one by mistake fails unless you explicitly allow it.

A typical migration is two commands:

# 1. Import an IMAP mailbox into a fresh archive.
export VANDELAY_PASSWORD='source-app-password'
vandelay import imap \
  --url imaps://imap.example.com \
  --auth-basic alice@example.com \
  alice.sqlite

# 2. Push the archive into a target JMAP server.
export VANDELAY_PASSWORD='target-password'
vandelay export \
  --url https://jmap.example.org \
  --auth-basic alice@example.org \
  --account-name alice@example.org \
  alice.sqlite

There is also an inspect command that dumps any object type from an archive (mailbox tree, message list, contacts, calendar events, and so on) without ever opening a network connection, which is handy for verifying a capture before you push it anywhere.

Account backup tool

Migrating between Stalwart versions over JMAP is what prompted Vandelay, but it is far from all it does. The first thing that falls out of the design is backup. Because an archive is a self-contained SQLite file that fully describes one account, you can treat it as a per-account backup in its own right. Run an import on a schedule to capture a fresh snapshot, keep the resulting file, and restore it later by running an export against any JMAP target. Since imports are convergent, each scheduled run only has to fetch what changed rather than re-reading the whole account every time.

Migrating from legacy servers and formats

Vandelay reads from a wide range of sources, not just JMAP, which makes it a practical way off an older self-hosted stack. Over IMAP it imports mail from any server, with folder selection by regex, exact name, or SPECIAL-USE role. Over CalDAV and CardDAV it imports calendars and events, address books and contacts, and over WebDAV it imports a file collection as a JMAP FileNode tree. ManageSieve brings across sieve scripts and records which one is active. It can also read a local Maildir++ tree straight off disk, with no network involved at all.

In practice this means Vandelay is a path off Dovecot, Cyrus, Radicale, Baikal, Apache mod_dav, and similar servers, and onto a JMAP server such as Stalwart, with mail, calendars, contacts, files, and filters all moving through the same tool.

Moving off Google and Microsoft Exchange

For accounts that live on a proprietary platform, Vandelay can pull data out of the two big ones. Google data exported through Takeout imports directly: Vandelay scans a directory tree for .mbox, .ics, and .vcf files and brings in the mail, calendars, and contacts it finds. It is tuned to the Takeout layout but works on any such tree.

For Microsoft Exchange, Vandelay can read mailboxes two ways. Over EWS it works against either on-premises Exchange Server or Exchange Online, with autodiscover, Basic auth, pre-acquired bearer tokens, interactive device-code OAuth, and app-only client-credentials OAuth. Over Microsoft Graph it reads Exchange Online mailboxes, using the interactive device-code flow by default.

One clear caveat: Exchange support is experimental. So far it has only been tested against a mock server, not a real Exchange deployment. The code paths are there and they pass against the mock, but Exchange is a large and quirky target, and we would not feel right calling this production-ready until it has met real mailboxes. If you have an Exchange tenant or an on-prem server and some appetite for testing, this is exactly the kind of help that moves a feature from experimental to supported. Please open an issue with what you find.

Sovereignty over your data

There is a bigger reason we built the importers as broadly as we did, and it is not only about Stalwart upgrades.

A lot of email, calendar, and contact data lives today on platforms where the operator, not the user, holds the keys. Getting your own data out of Google or Microsoft in a form you can actually use somewhere else is harder than it should be, and that friction is not accidental. It is what keeps people on a platform long after the reasons for choosing it have faded.

Owning your data means being able to leave. Vandelay is meant to make leaving straightforward: pull a full account out of a proprietary platform, hold it in an open, inspectable SQLite file that you control, and push it into a modern open-source JMAP server that you run yourself. No lock-in on the way in, and an open format in the middle that you can read with sqlite3 if you ever want to. Self-hosting is the part of the privacy conversation that is easy to agree with and hard to act on, and a migration tool that actually works is one of the things that makes acting on it realistic.

What is next

Vandelay is the first installment, not the whole story. The zero-downtime migration path we described still needs its second half, the migration proxy that lets clients keep talking to a single endpoint while accounts move from the old server to the new one behind it. That work is underway now, and we expect to release it in about two to three weeks.

When the proxy ships, we will also publish proper documentation covering the full migration workflow end to end, including how to use Vandelay as part of it. For now, the README is the documentation, and it covers every importer, every flag, and the quick-start path in detail.

If you have been putting off an upgrade, or you have data sitting on a platform you would rather not be on, Vandelay is ready to try today. We would love to hear how it goes, and if you can help us test the Exchange importers against the real thing, even better.

MTA Hooks at the IETF

Thu, 21 May 2026 00:00:00 GMT

What is MTA Hooks

If you have been running Stalwart for a while you have probably already met MTA Hooks. We introduced it in version 0.8.2, alongside Webhooks, as part of our broader effort to make Stalwart’s filtering and observability layer feel like the rest of modern infrastructure rather than like 1998.

MTA Hooks is an HTTP-based protocol that lets a mail server delegate per-stage decisions to external services. At each SMTP stage (connect, ehlo, mail, rcpt, data on the inbound side; delivery, defer, and DSN on the outbound side), the MTA sends an HTTP POST to a registered scanner. The scanner gets the envelope, the parsed message, the raw message, authentication results, TLS state and connection context, and replies with an action (accept, reject, quarantine, and so on) plus optional modifications expressed as JSON Pointer patches. Multiple scanners can be chained. Serialization is JSON or CBOR. Everything is just HTTP over TLS with a documented schema, which means any language with an HTTP library can implement either side without a binary protocol parser in sight.

Why it was built

Most mail filtering today still rides on Milter, the protocol Sendmail introduced around the year 2000. Milter does its job, but it carries a number of design choices that have aged poorly. There is no formal specification: the protocol is defined by libmilter, a C library whose wire semantics are documented only by reading the source. The two MTAs that support Milter (Sendmail and Postfix) have behaviourally divergent implementations, so a filter that works against one cannot always be relied on to behave identically against the other. Milter has no concept of outbound or post-delivery hooks, which means an entire category of use cases (delivery logging, compliance, DSN policy) sits outside its scope. And because the protocol is binary and C-centric, implementing a Milter filter in Go, Rust, Python, or whatever language your team actually uses is more painful than it should be in 2026.

MTA Hooks addresses these specifically. It has a written specification. It covers the full SMTP lifecycle, inbound and outbound. It speaks HTTP, so every HTTP load balancer, reverse proxy, observability stack, and auth middleware you already run works out of the box. It has explicit capability negotiation, so a scanner that does not understand a new stage simply will not subscribe to it, and the MTA and the scanner can evolve independently without breaking each other.

Why standardization matters

We could have kept MTA Hooks as a Stalwart-only feature and called it done. We deliberately did not, for two reasons.

The first reason is that a protocol that only one mail server speaks is not a protocol, it is an API. If you want filter authors to invest real engineering effort into supporting it, they need confidence that the wire format will not shift under them at our convenience, and that other mail servers will speak it too. Standardization is how you give them that confidence.

The second reason is the larger one. Email filtering is critical infrastructure for the internet. The mechanism by which a substantial fraction of the world’s mail gets inspected for spam, viruses, and policy violations should not be controlled by a single vendor’s source tree, no matter how friendly the vendor. The right home for a protocol of this scope is an open standards body, and for internet protocols the open standards body that matters is the IETF.

Standardization also forces a kind of rigour that internal development simply does not. Every assumption gets challenged, every edge case gets named, every security consideration gets cross-examined by people whose job is to find the corner you missed. The current draft is already noticeably better than what we shipped, precisely because reviewers have pushed back on parts we had taken for granted.

How the IETF actually works, briefly

If you have never been near the IETF, the process is shorter to describe than it looks. Someone writes an Internet-Draft, a versioned document describing a proposed protocol. Drafts are individual submissions until a Working Group adopts them, at which point they become Working Group documents. The WG iterates on the document in public, on a mailing list and in meetings, until it reaches consensus. At that point the draft enters Working Group Last Call, then goes to the Internet Engineering Steering Group, and if approved becomes an RFC on the Standards Track.

For a Working Group to be chartered, the IETF needs to see two things: a clear problem that justifies dedicated effort, and a community of people prepared to actually do the work and use the result. This is established through a Birds of a Feather session, universally abbreviated to BOF. A BOF is a one-time meeting at an IETF where the proponents make the case for the work and the room either does or does not show enough interest to justify forming a Working Group. You get one BOF. If it does not go well, the work does not die exactly, but it loses a substantial amount of momentum and may take a long time to recover.

Where MTA Hooks is right now

The current draft is draft-degennaro-mta-hooks-01. It has been presented twice at IETF meetings: at MAILMAINT at IETF 123 in Madrid, and at DISPATCH at IETF 125. Both sessions encouraged us to proceed toward a BOF. We have submitted the BOF request, and the responsible Area Director has asked us, very reasonably, to spend the time before the BOF building visible community engagement and a worked-out Working Group charter.

To support that, a dedicated mailing list now exists for the work:

List: mtahooks@ietf.org
Subscribe: https://mailman3.ietf.org/mailman3/lists/mtahooks.ietf.org/

On the ecosystem side, Rspamd plans to implement MTA Hooks support on the scanner side. Fastmail and Heinlein are also involved in the proposal. And of course MTA Hooks is in production today in every Stalwart deployment that uses it.

How you can help

The single most useful thing a Stalwart user can do right now is post to the mailing list. Not a long technical review, not a polished position paper, just a short message saying that you exist, that you are interested in MTA Hooks becoming a standard, and (if applicable) a sentence or two about how you use it or plan to use it. That kind of post takes five minutes to write and is worth a surprising amount when the IETF is deciding whether to charter a Working Group. The IESG and the chairs look very hard at who is going to use the result; visible, named interest from real operators and real integrators is the most persuasive signal there is.

You do not need to be an IETF regular. You do not need to have read the entire 60-page draft. You do not need to have an opinion on every design decision. If you read this far and the idea of an open standard for MTA filtering matters to you, even passively, please join the list and say so. If you have time to read the draft and push back on anything in it, even better, but the bar for being useful is low and the impact is real.

What is next

The proximate milestone is the BOF, currently targeting IETF 126 if charter discussion converges in time, with a virtual interim BOF as the fallback. Between now and then, the work happens on the mailing list: refining the charter, gathering implementation reports, and addressing reviewer comments on the draft. If the BOF goes well, a Working Group gets chartered, the draft becomes a WG document, and the path to an RFC opens up.

If it goes really well, the next time we write a blog post about MTA Hooks, we will be linking to an RFC number rather than a draft number. That is the goal. We would like as many of you as possible to be part of getting there.

See you on the list.

Introducing the Stalwart Support Portal

Thu, 07 May 2026 00:00:00 GMT

For most of the project’s life, support has happened wherever the community already was: GitHub Discussions for users following the repository, Discord and Matrix for real-time chat, and Reddit for the wider conversation. That worked well when the project was small. It does not scale.

As Stalwart has grown, we have started receiving hundreds of questions per day across these channels combined. A meaningful share of them have already been answered, sometimes more than once, on a different platform. Tracking four parallel inboxes, deduplicating threads, and making sure no one is left waiting has become a job we can no longer do reliably. The result is the opposite of what a support channel should produce: slower answers, repeated work for the people helping out, and good information buried in chat scrollback where the next person with the same question will never find it.

There is a second reason, raised by users themselves. Several community members have told us they would rather not open a GitHub or Discord account just to ask a question. That is a fair concern, and we agree that asking for help should not require signing up to a third-party platform that the user otherwise has no use for.

What the support portal is

support.stalw.art is a Discourse instance that we operate ourselves. It is hosted at Hetzner in their Germany datacenters and is GDPR-compliant, so the data stays in the EU and under European data protection law.

Discourse is open source, it indexes well, and it is built around the idea that a question and its answer should be permanent and findable. Threads are easy to link to, replies have stable URLs, and the search is good enough that the next user with the same problem has a real chance of finding the existing answer before opening a new topic. Over time, this should turn the portal into a knowledge base that the project actually owns, rather than one scattered across platforms we do not control.

Registration is open. You can sign in with the account you already use:

GitHub
Google
Discord
LinkedIn

Or, if you would rather not link an external account, you can register with any valid email address and a password. The choice is yours, and the experience inside the portal is the same either way.

What happens to the existing channels

GitHub Discussions, Discord, Matrix, and Reddit are not going away. They remain useful for casual chat, announcements, and community conversation, and we will continue to read them. What is changing is where support questions are answered: from now on, the canonical place to ask is support.stalw.art, and that is where our team’s attention will be focused. If you ask a support question on one of the chat channels, expect to be pointed at the portal so that the answer ends up somewhere durable.

Enterprise support

Enterprise customers with priority support will shortly receive an email with instructions for accessing the Priority Support area on the portal. Priority Support tickets stay private to your organization and to our team, with the response-time commitments that come with your subscription. Nothing changes about the support entitlement itself; the portal is simply where it now lives.

Looking forward

Thank you to everyone who has helped one another across the old channels over the years. The portal is built on top of that work, and we are looking forward to seeing the conversation continue in a place where it can finally accumulate.

Stalwart v0.16: A New Foundation

Mon, 20 Apr 2026 00:00:00 GMT

A Brand-New WebUI

The WebUI has been rewritten from the ground up. It has a refreshed, modern look, and it resolves a backlog of 76 enhancement requests and bug fixes that had accumulated over the years. If there was something you had been missing, there is a very good chance it is now there.

The most requested addition is also the most consequential: the new WebUI can authenticate against external OIDC providers. Signing in with Keycloak, Authentik, Authelia, Zitadel, or any other standards-compliant identity provider is now a first-class flow, with full support for audience and scope validation, group claims, and PKCE (RFC 7636) for public clients. This has been one of the most frequent community asks, and it is finally here.

Unified Management via JMAP and a New CLI

In previous releases, Stalwart was managed through a REST API that lived alongside its native JMAP interface. In v0.16, the REST API is gone. Every configuration and management action is now a JMAP object, reachable through the same /jmap endpoint that already serves email, calendars, contacts, and files.

The benefits of this change are hard to overstate. JMAP (RFC 8620) is a well-specified, transport-efficient protocol with first-class support for batch operations, push notifications, and fine-grained change tracking. In practice, this means dozens of configuration changes can be applied in a single round-trip, any JMAP client library can drive the management surface, and a single authentication flow covers both mail access and administration. Centralizing configuration inside the datastore as JMAP objects also removes an entire category of operator confusion: there is no longer a split between “settings in a file” and “settings in the database”, and in clustered deployments the configuration is consistent across every node by definition.

Alongside the WebUI, we also shipped a brand-new CLI. The new stalwart-cli is built on top of the same JMAP management API and can configure and administer every aspect of Stalwart. It is designed for day-to-day administration, scripted deployments, and infrastructure-as-code workflows. The stalwart-cli apply subcommand takes a declarative plan file and idempotently reconciles the live server state to match it, creating what is missing, updating what has changed, and removing what the plan no longer declares. This fits naturally with Ansible, Terraform, NixOS, and similar tooling, and follows the same pattern used by projects like CockroachDB, Consul, Elasticsearch, and HashiCorp Vault, where infrastructure-as-code tools target an API rather than a configuration file.

The new CLI is also a very pleasant surface for AI agents. Because every operation maps to a well-defined JMAP object with a clear schema, agents can discover capabilities, plan changes, and apply them idempotently without any bespoke integration work.

Automated DNS Management

In previous releases, Stalwart only managed the TXT records required for the ACME DNS-01 challenge. In v0.16, it can take care of every DNS record a modern mail and collaboration server needs: MX, TXT, CNAME, SRV, CAA, and TLSA. The server computes the records your deployment should be publishing and keeps them in sync with your DNS provider automatically.

This covers most of the authentication and discovery story out of the box. SPF, DKIM, and DMARC records are managed alongside autoconfig and autodiscover SRV records, CAA records for certificate issuance authorization (including the accounturi parameter for account-scoped issuance), and TLSA records for DANE. The TLSA records are automatically refreshed when ACME certificates are renewed, so DANE-enabled domains no longer risk a validation gap during certificate rotation.

On the provider side, v0.16 ships support for Route53, Google Cloud DNS, Bunny, Porkbun, DNSimple, and Spaceship, and also supports RFC 2136 dynamic updates signed with SIG(0) for operators running their own authoritative DNS.

Automated DKIM Rotation

DKIM key rotation is one of those tasks that everyone knows they should be doing, and almost nobody actually does, because it is tedious and easy to get wrong. In v0.16, Stalwart takes over the entire workflow. It can generate DKIM keys automatically, rotate them on a schedule, and publish the matching TXT records through the new DNS management layer so that the published keys always match the keys the server is signing with. DKIM keys are now stored in the database alongside the rest of the configuration, which means rotation works naturally in clustered deployments without any manual coordination.

Masked Emails

Masked emails are disposable, per-service email addresses that route to a user’s real inbox. Instead of handing out a primary address to every newsletter, shop, or forum, a user can generate a unique masked address for each one. If a service leaks its database or starts sending unwanted mail, the corresponding masked address can be disabled individually, without affecting anything else and without touching the user’s real address. It is one of the most effective privacy tools available today, and it integrates cleanly with the rest of the directory in Stalwart.

This feature is part of the Enterprise edition.

Security Enhancements

Security gets a substantial upgrade in v0.16. User passwords can now be checked against the zxcvbn strength estimator at set-time, so weak credentials never make it into the system in the first place. Passwords can also be given explicit expiration and rotation policies, and user accounts can be restricted to specific IP ranges so that an account is only usable from expected networks.

App passwords and API keys receive the same treatment, and then some. Both can now be scoped to a specific set of permissions rather than inheriting the full privileges of the owning account, which means a token used by a single IMAP client or a single automation script can be limited to exactly what it needs. Both also support human-readable labels, expiration dates, and IP address restrictions, so long-lived credentials can be audited, rotated, and confined without having to revoke them entirely.

Taken together, these features make the credentials surface of a Stalwart deployment dramatically easier to reason about and lock down.

Other Highlights

There are many other additions worth calling out. On the account configuration front, v0.16 implements the new Automatic Configuration of Email, Calendar, and Contact Server Settings draft, which is shaping up to replace the fragmented autoconfig and autodiscover mechanisms clients use today, and adds MS Autodiscover V2 support for environments that still rely on it.

The directory layer gains domain aliases, alias descriptions, the ability to disable aliases without deleting them, and, for the Enterprise edition, account archiving and un-deletion and per-domain directory backends. The ACME layer picks up the new DNS-PERSIST-01 challenge, on-demand certificate renewal, and a certificate detail view. Sieve scripts can now be deactivated without being deleted. Clustering is cleaner, with automatic node ID generation, unified cluster management, and a new outbound MTA role for dedicated queue nodes.

On top of all of this, dozens of bug fixes land across the directory, MTA, JMAP, IMAP, WebDAV, CalDAV, OIDC, and storage backends. If you have been tracking an issue, there is a good chance it is resolved in v0.16.

Upgrading

Because of the scope of the architectural changes, v0.16 is a major upgrade with multiple breaking changes. Please do not upgrade a production deployment without first reading the upgrading documentation in full. We also strongly recommend spinning up a fresh v0.16 instance in a container or throwaway VM first, getting comfortable with the new WebUI and CLI, and exporting any settings you build there as an apply plan to replay against production after the migration.

If any questions come up along the way, a dedicated discussion thread for the v0.16 upgrade is open at https://github.com/stalwartlabs/stalwart/discussions/3004. We will be following it closely.

This release has been in the making for over three months, and it represents one of the largest single steps forward in Stalwart’s history. Thank you to everyone who filed bugs, contributed code, tested pre-releases, and kept the conversation going in issues and discussions: v0.16 is very much your release too. We cannot wait to hear what you build with it.

Marginal Gains: Major Impact

Tue, 16 Dec 2025 00:00:00 GMT

Rethinking Spam Classification

Stalwart v0.14 (and earlier) included a spam classifier which was a direct port of the classifier used by Rspamd. This classifier is grounded in Bayesian theory and uses more advanced methods to combine probabilities, including sparse bigrams (OSB) and the inverse chi-square distribution. This approach is well understood and robust, particularly when training data is limited. It produces reasonable results quickly and has a long track record in production systems.

However, it comes with a significant cost in distributed environments. Both Rspamd and Stalwart v0.14 relied on OSB-5, which generates a very large number of features per message. Each of these features was stored in Redis. Even with aggressive caching, training or classifying a single message could involve hundreds or even thousands of round trips to Redis. At scale, this becomes a bottleneck: latency increases, throughput drops, and horizontal scaling becomes inefficient.

For v0.15, we went back to first principles and redesigned the spam classifier from scratch, guided by more recent research. We evaluated several models and ultimately settled on a logistic regression classifier trained using the FTRL-Proximal (Follow the Regularized Leader) algorithm. This algorithm—famously used by Google for large-scale online learning—is particularly well suited to spam classification workloads where models must be updated continuously and efficiently.

One immediate benefit of this approach is that Stalwart can now support collaborative filtering out of the box. Multiple users can benefit from a single shared classifier trained on aggregated data, dramatically improving accuracy in environments with many accounts. At the same time, individual users can still maintain their own personal classifiers trained solely on their own messages.

The new classifier also adopts feature hashing (often called the hashing trick) to keep the feature space compact and predictable. This significantly reduces memory usage and improves cache locality. For very large deployments, cuckoo feature hashing is available to further reduce hash collisions. If you are interested in the theoretical background, the original feature hashing paper is available at Feature Hashing for Large Scale Multitask Learning and the cuckoo feature hashing paper at Cuckoo Feature Hashing: Dynamic Weight Sharing for Sparse Analytics.

With the default configuration of 2²⁰ features, the entire model fits in approximately 4 MB of memory and is loaded only once after each training cycle. The result is a classifier that is both faster and more accurate than the previous version, particularly in distributed deployments where network overhead matters.

We also evaluated RetVec (Resilient and Efficient Text Vectorizer), the embedding technique used by Gmail. RetVec excels at generating compact semantic representations of email content, but it is primarily designed to feed neural networks and deep learning models. For now, logistic regression offers a better balance of simplicity, performance, and operational transparency. That said, we plan to ship a pre-trained RetVec model alongside BERT in a future release.

A Faster, Simpler Search Layer

Search is another area where small architectural choices have outsized effects. In Stalwart v0.15, the search layer has been substantially rewritten.

For deployments using PostgreSQL or MySQL, Stalwart now leverages the built-in full-text search capabilities of the database instead of relying on a custom implementation. This reduces complexity, improves query planning, and allows the database to do what it already does well.

We have also added support for Meilisearch, a lightweight, fast search engine with excellent performance characteristics and simple operational semantics. Meilisearch offers low-latency full-text search, typo tolerance, and efficient indexing, making it a good fit for many Stalwart deployments.

For large installations backed by FoundationDB, we plan to significantly improve the built-in search functionality by embedding Seekstorm. Until that work is complete, we recommend pairing FoundationDB with an external search engine such as OpenSearch or Meilisearch to achieve the best performance.

Faster Database Access and Leaner Storage

Stalwart v0.15 includes a number of optimizations to the database access layer. We have reduced the number of reads and writes required to store and retrieve messages, particularly along hot paths such as IMAP and JMAP access. The result is noticeably faster message retrieval and improved overall responsiveness under load.

In parallel, we revisited how email metadata is stored and reduced some serialization overhead. This lowers disk usage and improves cache efficiency, which again compounds into better performance at scale.

Individually, these changes are modest. Collectively, they make the system feel tighter and more predictable under real-world workloads.

Meet Us at FOSDEM 2026

We are excited to announce that Stalwart will be present at FOSDEM 2026 in Brussels, Belgium.

Our talk, Stalwart: Can Open Source do Gmail-scale Email?, builds naturally on the marginal gains theme. While v0.15 focuses on incremental improvements, the talk zooms out to the other end of the spectrum: what it takes to design and operate a truly large-scale email system.

Using a 1,024-node cluster as a concrete example, we will explore how modern providers store and index petabytes of messages, survive hardware failures without data loss, and run spam and phishing filtering across billions of daily deliveries. We will walk through the architectural patterns behind distributed storage, large-scale spam filtering, MTA queue management, and load balancing for IMAP, JMAP, and SMTP.

We will also discuss cluster coordination, orchestration, autoscaling, and how to reason about failure before it happens. The goal is to give attendees a practical understanding of how planet-scale email systems are built, and how those same principles can be applied using open-source technology.

If you are attending FOSDEM, we would love to meet you, answer questions, and talk about where Stalwart is heading next.

Looking Ahead

Stalwart v0.15 is a release shaped by the philosophy of marginal gains. There are no new flashy features, but there are dozens of small improvements that add up to something meaningful: faster spam classification, better scalability, simpler search, leaner storage, and more predictable performance.

If you are already running Stalwart, we encourage you to try v0.15 and let us know how it performs in your environment. Your feedback continues to guide where we focus next.

The team is already working on future releases that build on this foundation. With the core systems now leaner and more robust, we can continue to add new capabilities without compromising performance or reliability.

As with cycling, progress comes from steady, thoughtful refinement. Stalwart v0.15 is one more step in that direction.

JMAP for Calendars, Contacts and Files now in Stalwart

Wed, 22 Oct 2025 00:00:00 GMT

A New Generation of Protocols

Over the past few years, the IETF has been redefining how email, calendars, and contacts are synchronized and shared. Building upon the success of JMAP for Mail, several new protocol extensions have been introduced:

JMAP for Calendars - A modern replacement for CalDAV and CalDAV Scheduling.
JMAP for Contacts – A powerful alternative to CardDAV.
JMAP for File Storage – A replacement for WebDAV-based file storage.
JMAP Sharing – A modern successor to WebDAV ACL.
JSCalendar - A clean, JSON-based evolution of iCalendar.
JSContact – A modernized, JSON-native successor to vCard.

Together, these standards offer a cohesive and elegant ecosystem that replaces decades of fragmented WebDAV-based technologies.

Limitations of Yesterday’s Technology

WebDAV and its descendants — CalDAV, CardDAV, and related extensions — have served the Internet well. They are robust, widely adopted, and battle-tested. Yet, their XML-based design is notoriously verbose, inconsistent, and difficult to implement correctly. Information is scattered across HTTP headers, XML payloads, and even embedded iCalendar data, creating endless compatibility and interoperability challenges between clients and servers.

Similarly, iCalendar and vCard, while expressive and versatile, have accumulated decades of technical debt. They contain countless properties and parameters—many rarely used, some obsolete, and others inconsistently implemented across versions. This clutter has made both formats unwieldy and error-prone, often requiring complex parsing logic to handle edge cases.

JMAP: A Modern Solution for Modern Needs

The JMAP protocol was originally developed as a more efficient, modern replacement for IMAP and SMTP submissions. Its strengths lie in simplicity, clarity, and network efficiency — all built on top of JSON over HTTPS.

Now, with the introduction of JMAP for Calendars, Contacts, Files, and Sharing, the same design philosophy extends beyond email to the entire collaboration stack. These protocols deliver what DAV always aimed for but never quite achieved: a clean, uniform, and easily implementable API for all personal and group data — mail, calendars, contacts, files, and shared resources.

Meanwhile, JSCalendar and JSContact reimagine iCalendar and vCard as elegant JSON-based formats. They strip away decades of accumulated cruft, unify representations, and offer a clear, unambiguous, and expressive data model. Both are human-readable, developer-friendly, and efficient to parse — a perfect fit for modern applications.

Together, JMAP and these new data models make calendaring, contact management, and file sharing not only easier to implement but also faster and more reliable.

Why This Matters

This release represents more than new features — it marks a shift in how groupware protocols are designed and implemented. For the first time, developers and organizations can build on a single, coherent, JSON-based framework for mail, contacts, calendars, and shared resources.

We believe this will revolutionize calendaring and collaboration. Implementations will become easier, interoperability issues will decrease, and innovation will accelerate. The simplicity and predictability of JMAP empower both clients and servers to focus on features and user experience, not protocol gymnastics.

Client Support and Ecosystem

As Stalwart is the first complete JMAP server to support these new protocols, client support is still emerging. However, we’re excited to share that several projects are already working to adopt these new standards. Mailtemi and OpenCloud are actively developing client-side implementations for JMAP Calendars, Contacts, and File Storage. The ecosystem is growing, and we expect rapid adoption as developers experience the elegance and power of JMAP firsthand.

A Word of Thanks

We would like to express our sincere gratitude to NLNet for supporting the development of these features through the NGI Zero grant program. Their commitment to open standards and privacy-respecting technology continues to make projects like Stalwart possible.

Looking Ahead to 1.0.0

After four years of dedicated development, we’re proud to announce that Stalwart is now feature complete. With this milestone, all the core capabilities of a modern mail and collaboration server are fully implemented.

That said, our work is far from over. We are now focusing on finalizing the database schema, improving performance, and addressing the hundreds of enhancement requests on GitHub. Our goal is to deliver a stable 1.0.0 release within the next few months — one that sets a new standard for open, efficient, and modern communication servers.

Stalwart is now the most complete, elegant, and forward-looking JMAP collaboration platform available.

And this is only the beginning.

Security at the Core: Stalwart completes Second Security Audit

Tue, 07 Oct 2025 00:00:00 GMT

Comprehensive Assessment

The audit, conducted between September 9 and September 25, 2025, focused on version v0.13.2 of Stalwart mail and collaboration server. The goal was clear: rigorously evaluate the security posture of the platform, identify potential vulnerabilities, and ensure our defenses are as strong as possible.

The penetration test followed a “crystal-box” methodology, combining source code review with targeted exploitation attempts. This included testing against the latest OWASP Top 10 risks, analyzing protocol implementations, and probing external interfaces — the most exposed and therefore most critical components of the system.

Findings

The audit uncovered a total of seven security issues: two high-severity vulnerabilities and five low-severity issues. All but one minor issue were promptly addressed.

The most significant findings involved Denial-of-Service (DoS) vulnerabilities:

CVE-2025-59045 — Memory Exhaustion via CalDAV REPORT: A crafted CalDAV request could trigger unbounded memory usage, potentially crashing the server.
CVE-2025-61600 — Unbounded Buffer Growth in IMAP Parser: A flaw in the IMAP protocol parser could allow an attacker — even without authentication — to cause memory exhaustion.

Both of these high-severity vulnerabilities were resolved within four hours of disclosure, underscoring our team’s rapid response capability and deep focus on platform resilience. Patches were released in versions v0.13.3 and v0.13.4, and the issues have been assigned CVE-2025-59045 and CVE-2025-61600, respectively.

Among the lower-severity findings were issues related to RFC compliance in email parsing, permission checks, and quota enforcement. These were addressed swiftly as well, with most fixes included in v0.13.4. One low-severity race condition related to disk quotas (TOCTOU) remains partially mitigated; however, its practical impact is limited due to built-in concurrency controls.

For those who would like a deep dive into the audit’s findings, the full report is accessible here.

Our Commitment to Security

The final report praised Stalwart’s codebase as robust, well-architected, and cleanly compartmentalized, with memory safety ensured by Rust and attacker-aware design principles evident throughout. At the same time, the audit highlighted that our “build everything in-house” philosophy — while a strength — requires careful attention to detail, particularly in protocol parsing and input handling.

Security is never a one-time checkbox — it’s an ongoing process. That’s why regular audits like this one are an integral part of how we develop Stalwart. As our platform evolves, so does our approach to safeguarding it.

We’re proud of how quickly and effectively our team responded to the findings of this audit, and we remain committed to maintaining transparency and trust with our users and the broader open-source community.

Stalwart Joins GitHub's Open Source Secure Fund

Mon, 11 Aug 2025 00:00:00 GMT

About GitHub’s OSSF

GitHub launched the Open Source Secure Fund in November 2024 as a comprehensive initiative to strengthen security across the software supply chain. The program represents a strategic approach to open source security that goes far beyond simple financial support. Instead of merely providing funding, the initiative creates a structured pathway for maintainers to develop deep security expertise while building lasting connections within a community of security-focused developers.

The fund operates on a model that combines immediate intensive training with long-term support and accountability. Each session consists of a three-week sprint, delivered by security experts from GitHub and their partners through the GitHub Security Lab. However, the relationship extends far beyond these initial weeks, with participants receiving ongoing support and resources throughout a full twelve-month engagement period.

What makes this program particularly valuable is its emphasis on community building and ongoing support. Participants gain access to a specialized security-focused community and regular office hours with the GitHub Security Lab throughout the entire twelve-month period. This extended engagement ensures that the security improvements initiated during the sprint continue to evolve and mature over time.

Our Experience

The training component of our participation concluded six weeks ago, and we can confidently say it provided valuable insights that have already begun to shape Stalwart’s security posture. The comprehensive nature of the program allowed us to step back and evaluate our security practices from multiple perspectives, leading to concrete improvements in our security infrastructure.

One of the most significant outcomes of our participation has been the development of a comprehensive Incident Response Plan specifically tailored to Stalwart’s architecture and user base. This plan establishes clear protocols for identifying, containing, and resolving security incidents while maintaining transparency with our community. Having a well-defined incident response strategy is crucial for any mail server software, given the sensitive nature of email communications and the potential impact of security breaches.

Additionally, we’ve substantially enhanced our existing Security Policy, incorporating lessons learned from the GitHub training and feedback from security experts. This updated policy provides clearer guidelines for security researchers, establishes more robust vulnerability disclosure procedures, and outlines our commitment to maintaining security standards throughout Stalwart’s development lifecycle.

The training also introduced us to various security concepts and tools, including an introduction to fuzzing techniques for discovering potential vulnerabilities. However, the Rust programming language’s memory safety guarantees and the security-conscious culture of the Rust community mean that many of the security recommendations from the GitHub program were already implemented in Stalwart’s codebase. This validation from security experts reinforced our choice of Rust as the foundation for Stalwart and highlighted the proactive security feedback we’ve received from the broader Rust ecosystem.

Leveraging Azure Credits

While the GitHub funding provides important financial support for the project, we’re particularly excited about the $100,000 in Azure credits that accompany our participation in the program. These credits represent an unprecedented opportunity to conduct large-scale testing and optimization of Stalwart’s performance and security characteristics.

We plan to use these Azure credits to deploy Stalwart across a massive cluster configuration, enabling us to generate millions of concurrent connections and simulate real-world load scenarios that would be impossible to replicate in smaller testing environments. This extensive testing will focus on three critical areas that are essential for any mail server infrastructure.

First, we’ll conduct comprehensive performance testing to identify and resolve bottlenecks that might emerge under extreme load conditions. Email servers must handle varying loads gracefully, from quiet periods to sudden spikes in activity, and this testing will help us optimize Stalwart’s resource utilization and response times across all scenarios.

Second, we’ll focus extensively on scalability improvements, ensuring that Stalwart can grow seamlessly from small deployments to enterprise-scale installations. Understanding how different components interact and potentially conflict under high-load conditions will enable us to make architectural improvements that benefit all users, regardless of their deployment size.

Finally, and perhaps most importantly for security, we’ll conduct thorough resilience testing against various types of Denial of Service (DoS) attacks. Mail servers are frequent targets for such attacks, and having the ability to simulate these scenarios in a controlled environment will allow us to implement and verify defensive mechanisms that protect real deployments. The insights gained from this testing will be invaluable for administrators who need to deploy Stalwart in security-conscious environments.

Ongoing Security Audit

Our commitment to security extends beyond the GitHub program, as evidenced by our current engagement with Radically Open Security for a comprehensive second security audit of Stalwart. This audit represents a significant milestone in our security journey, coming approximately two years after our first security audit conducted on October 7, 2023.

The timing of this second audit is particularly important because Stalwart has evolved considerably since that initial security review. New features have been added, performance optimizations have been implemented, and the overall architecture has matured significantly. A fresh security perspective is essential to ensure that these improvements haven’t introduced new vulnerabilities and that our security posture has kept pace with the software’s development.

Radically Open Security brings extensive experience in open source security auditing, and their thorough approach will provide valuable insights into Stalwart’s current security status. This audit is being financed through a grant from NLNet, demonstrating the broader open source community’s investment in Stalwart’s security and reliability.

We expect to release the complete results of this security audit soon, continuing our commitment to transparency and community trust. The combination of the GitHub security training, the ongoing Azure-powered testing, and this comprehensive security audit represents a multi-faceted approach to security that reflects the importance we place on protecting our users’ communications and data.

Acknowledgments

We want to take a moment to express our sincere thanks to GitHub for selecting Stalwart to participate in the Open Source Secure Fund and for providing us with the training and resources that will help strengthen the security of our project. We also want to extend our gratitude to Zerodha for referring Stalwart to be part of GitHub’s OSSF Session 2. Their support has been invaluable, and we look forward to continuing this journey of growth and improvement with their help.

Stalwart is committed to providing secure and reliable mail and collaboration services, and with the backing of the GitHub OSSF and the ongoing work of our team, we are confident that we can continue to meet and exceed the expectations of our users.

Thank you for your continued support!

Introducing Virtual Queues and Strategy-Driven Delivery in Stalwart MTA

Tue, 15 Jul 2025 00:00:00 GMT

Smarter Queueing with Virtual Queues

To solve this, we’ve introduced virtual queues—a powerful feature that allows administrators to define separate, independently managed delivery queues for different categories of mail.

Each virtual queue operates with its own set of delivery threads, giving you control over how system resources are allocated. Messages can now be segmented by message type, source, priority, recipient domain, or any other attribute, and assigned to different queues with tailored delivery policies.

For example, you can isolate system-generated messages such as DSNs or reports into low-concurrency queues, while prioritizing user-facing transactional mail in high-capacity queues—ensuring the latter is never blocked or delayed by the former.

Strategy-Driven Delivery

At the core of this system is a strategy-based architecture that governs how messages are handled from the moment they’re queued to the point of delivery. These strategies are dynamically evaluated per recipient and control four key aspects of delivery:

Scheduling Strategy: Determines which virtual queue to use, how frequently to retry failed deliveries, when to notify the sender of delays, and when to give up and bounce a message.
Routing Strategy: Controls whether a message should be delivered locally, via MX resolution, or relayed through a smart host.
Connection Strategy: Defines connection parameters such as the source IP address, EHLO hostname, and SMTP timeouts.
TLS Strategy: Enforces transport-layer security policies, including STARTTLS behavior and support for MTA-STS and DANE.

All of these strategies are defined through expressions that can evaluate runtime variables like the sender, recipient, message size, source classification, and more. This enables extremely granular control over delivery logic, with different strategies dynamically assigned to different recipients within the same message.

With this enhancement, Stalwart now gives you the tools to build highly customized delivery workflows. You can throttle or isolate problematic traffic, prioritize VIP clients, set domain-specific retry policies, and fine-tune your system for performance, reliability, and security—all with a simple and transparent configuration model.

MTA Hooks: Moving Toward Standardization

For those not already familiar, MTA Hooks is a modern alternative to the legacy Milter protocol originally developed for Sendmail. Milter has long served as a way to inspect, modify, or reject messages during the SMTP transaction, but its binary format and low-level implementation have made it difficult to work with and integrate into modern systems.

MTA Hooks, introduced by Stalwart Labs some years ago, was designed to solve these problems with a cleaner, more accessible approach. Instead of relying on obscure binary protocols, MTA Hooks uses HTTP and a human-readable JSON schema, making it easy for administrators and developers to write filters in any language, debug behavior transparently, and integrate with modern infrastructure.

Using MTA Hooks, it’s possible to intercept, inspect, and alter any part of the SMTP transaction—whether that’s rejecting mail during RCPT TO, modifying headers after DATA, or applying policy logic during message queuing. Many users are already using MTA Hooks in production for a wide range of use cases, from spam filtering and data leak prevention to routing logic and outbound content policy enforcement.

Now, we’re excited to share that Stalwart Labs will begin the process of standardizing MTA Hooks with the broader email community.

We’ll be presenting the protocol at IETF 123 in Madrid, where we plan to engage with the mailmaint working group to start formal discussions around standardization. Our goal is to make MTA Hooks an open, community-driven specification—so it can serve as a modern, interoperable alternative to Milter for the entire mail ecosystem.

If you’re attending IETF 123 and would like to connect with us about this effort, we welcome your input. Please reach out through any of our official channels or come speak with us during the event. Whether you’re an MTA developer, operator, or interested party, we’d love to hear your perspective.

Looking Ahead

Stalwart is evolving rapidly, and this release represents a major step forward in performance, flexibility, and modern protocol design. As always, we’re grateful to our community for your feedback and support. We look forward to seeing what you build with these new capabilities.

Stay tuned for more updates—and see you in Madrid!

The Future of Stalwart: Webmail, Roadmap, and Beyond

Fri, 20 Jun 2025 00:00:00 GMT

Almost exactly one year later, on September 17th, 2022, we proudly released version 0.1, initially known as the Stalwart JMAP server. From that initial launch, we’ve continuously expanded Stalwart’s capabilities, consistently introducing valuable new features. Just last month, we celebrated a major milestone by transforming Stalwart from solely a mail server into a comprehensive mail and collaboration server. This significant update brought CalDAV, CardDAV, and WebDAV support, positioning Stalwart as the open-source mail and collaboration server with the most extensive feature set available today—even compared to many commercial solutions.

Despite these significant advancements and the existing web-based administration interface that includes essential self-service capabilities, we’ve noticed one prominent request from our community: a built-in webmail client. Many of you have been eagerly asking whether we plan to offer this feature. Today, we’re excited to share with you that yes, a dedicated Stalwart Webmail is indeed in our plans—but it’s not currently our immediate priority.

Our roadmap for the remainder of 2025 is already well-defined. We will first release JMAP support for Calendars, Contacts, and File Storage, which will further strengthen Stalwart’s position as a powerful collaborative tool. Immediately following these updates, our main focus will shift to preparing for our much-anticipated version 1.0 release.

Although Stalwart is already being confidently used in production environments globally, version 1.0 marks an essential milestone. It signifies that we’ve finalized our database schema—no more daunting database migrations!—ensuring stability for long-term users. Unless an entirely new protocol surpassing email emerges (who knows?), our database schema will remain stable and optimized. Moreover, this version will involve a comprehensive performance optimization initiative. Every line of our code was initially written with speed and efficiency in mind, yet there are still critical areas we believe can be further improved. By systematically benchmarking critical code paths, we’re confident we’ll find opportunities to make Stalwart even faster and more efficient.

Post version 1.0, our commitment remains firm: Stalwart will remain lean and specialized. While our GitHub issue tracker proudly showcases numerous exciting enhancement requests, rest assured we won’t lose sight of our core mission. Our primary goal is to continue being the absolute best in JMAP, IMAP, POP3, SMTP, and WebDAV protocols—nothing more, nothing less. We strive to avoid becoming a proverbial jack-of-all-trades, instead remaining focused and exceptional at our core competencies.

As for the much-requested Webmail, once we’ve achieved the critical milestone of version 1.0, we plan to start its development—most likely sometime in 2026. We’ll be building a Single Page Application (SPA) using Rust and the Dioxus framework. Dioxus is quite distinct from more popular frameworks like React, meaning many necessary UI components still don’t exist. Consequently, we’ll likely spend considerable time contributing directly to the Dioxus ecosystem, expanding available components and features.

Now, you might ask, “Why not simply use React or another established framework?” Well, humorously and earnestly, at Stalwart, we operate by an unofficial motto: “Aut Rust aut nihil,” meaning “Either Rust or nothing.” We’re committed to Rust because we truly believe it’s the best language for creating secure, reliable, and performant software—even if this approach means occasionally delaying releases by a few months.

In the meantime, while our webmail is in development, we highly recommend using alternative webmail solutions that integrate smoothly with Stalwart. Some choices include Roundcube, SnappyMail, SoGo, or TMail Web—which notably supports the JMAP protocol.

We’re grateful for your continued support and patience as we steadily build toward a fully integrated Stalwart experience. Stay tuned, and thank you for being part of this exciting journey!

Introducing Calendars, Contacts and Files in Stalwart

Mon, 26 May 2025 00:00:00 GMT

Calendars, Contacts & Files – All in One Place

With v0.12, you no longer need to integrate third-party groupware solutions or run parallel systems to support collaboration. Stalwart now includes first-class support for CalDAV calendars, CardDAV contacts, and WebDAV-based file storage. This means users can manage their events, address books, and documents through any standards-compliant client, seamlessly connected to the same backend that handles their email.

Shared resources such as group calendars, shared address books, and team-accessible file folders are also fully supported, providing a robust foundation for collaboration without the need for external software or services. And, to support flexible collaboration, Stalwart includes full support for the WebDAV Access Control List (ACL) extension, enabling detailed, per-user and per-group permission management.

Improved Spam Filtering

Another thoughtful addition in this release is the integration of the spam filter with users’ personal address books. Messages from known or trusted contacts are now far less likely to be incorrectly flagged as spam. And if a legitimate message does get misclassified, the system automatically trains the Bayesian classifier to treat future similar messages as legitimate, improving accuracy over time without additional user intervention.

Performance Enhancements

Under the hood, Stalwart v0.12 introduces several key performance optimizations designed especially for large, multi-node environments. One of the most impactful changes is the introduction of incremental caching: Stalwart now keeps account metadata in memory and only fetches updates when something changes in the database. This significantly reduces load and speeds up response times.

Another major enhancement is the use of zero-copy deserialization. This means Stalwart can read data directly from memory buffers without copying it into new structures, lowering CPU usage and improving throughput. Combined with optimizations that reduce the number of required database queries for common operations, these changes result in a leaner, faster backend that scales much more efficiently.

While these gains may not be noticeable in smaller setups, larger clusters and high-volume deployments will see noticeable performance improvements.

Smarter and Faster Clustering

We’ve also made big strides in cluster coordination. Previously, Stalwart relied on a UDP-based gossip protocol that performed well but didn’t scale ideally under heavy workloads. With v0.12, cluster behavior is now adaptable based on deployment size.

In small deployments, Stalwart uses Eclipse Zenoh, a lightweight and efficient peer-to-peer pub/sub protocol. For larger infrastructures, you can now choose from robust, scalable backends like Apache Kafka, Redpanda, NATS, or Redis for handling inter-node coordination, state synchronization, and workload distribution.

Looking Ahead: What’s Next?

With Stalwart v0.12, we’re delivering more than just features—we’re delivering freedom from fragmented infrastructure. No more patching together third-party services to get the basics of collaboration working. Now, everything—email, calendars, contacts, files, and sharing—lives in a single, efficient, and secure system.

While v0.12 is a major leap forward, we’re already preparing additional enhancements for the next point release. In v0.12.1, you can expect support for CalDAV Scheduling (RFC 6638), enabling automatic meeting invitations and attendee responses. We’re also adding support for event notification alerts via email, so users are always aware of upcoming events, even if they’re not logged into their calendars.

Additionally, in the coming months, we will be releasing support for the JMAP for Calendars, JMAP for Contacts, and JMAP for File Storage extensions. JMAP offers a modern, efficient, and JSON-based alternative to legacy protocols, making it faster and easier to develop responsive, real-time collaboration tools. These additions will further streamline the user experience and reduce bandwidth and processing overhead across client-server interactions.

Thank you to everyone who contributed feedback, suggestions, and encouragement. We can’t wait to hear what you build with this release—and we’re just getting started.

Stalwart Receives NLNet Grant to Build Collaboration Server

Fri, 21 Mar 2025 00:00:00 GMT

Expanding the Vision: From Email to Collaboration

Stalwart Mail Server was created to address the challenges of self-hosting email by offering a secure, easy-to-maintain, and high-performance solution. With native support for JMAP, IMAP4, POP3, and SMTP, it already serves as a powerful alternative to traditional email solutions, giving individuals and organizations full control over their email systems.

With the help of this new grant, we are now expanding the Stalwart platform beyond email. Development is officially underway on the Stalwart Collaboration Server, a new component that will integrate seamlessly with Stalwart Mail Server. This addition will provide support for calendaring through CalDAV and JMAP for Calendars, contact management using CardDAV and JMAP for Contacts, and file storage and sharing using WebDAV and JMAP for File Management. Together, these features will form the foundation of a fully integrated, open-source collaboration suite.

Our goal is to offer a privacy-focused, vendor-neutral alternative to platforms like Microsoft Exchange. By consolidating email, calendar, contacts, and file sharing into one unified system, Stalwart will give users the ability to self-host their entire collaboration stack without sacrificing modern functionality, scalability, or security.

What the Grant Will Fund

The new funding will support a series of developments that will be released gradually throughout the year under the AGPL-3.0 license:

A full-featured CalDAV and CardDAV server will be implemented, allowing users to manage their calendars and contacts directly within Stalwart. This means there will be no need to rely on external software to provide these functions. Users will be able to keep all of their collaboration data in one place, within a single, tightly integrated platform.
In addition, we will extend Stalwart’s existing JMAP implementation to support JMAP for Calendars and JMAP for Contacts. This will involve developing parsers for JSCalendar and JSContact, as well as creating bidirectional converters between JSCalendar and iCalendar, and JSContact and vCard.
File storage and management will also become a first-class feature of the platform. A WebDAV-based file storage system will be built on top of Stalwart’s internal blob store. Alongside this, we will implement support for JMAP for File Management, allowing users to upload, organize, and share files using either standard WebDAV clients or JMAP-based applications. The JMAP support will align with the ongoing efforts to standardize file management within the JMAP ecosystem.
Finally, the grant will fund the implementation of the three most requested features by the Stalwart community. These include support for the IMAP XAPPLEPUSHSERVICE extension, which enables push notifications on iOS devices; automatic DKIM record updates via RFC2136, making it easier to manage DNS records dynamically; and support for exporting Maildir mailboxes with nested folders, improving compatibility and backup workflows.

Acknowledgements

We would like to express our sincere thanks to the NLnet Foundation and the European Commission for making this work possible. The project is funded through the NGI0 Core Fund, a fund established by NLnet with financial support from the European Commission’s Next Generation Internet programme, under the aegis of DG Communications Networks, Content and Technology, as part of grant agreement No. 101092990.

This support plays a vital role in advancing open-source infrastructure and helps ensure that secure, decentralized alternatives remain viable and accessible to everyone.

Looking Ahead

As we roll out these new features throughout the year, we remain committed to the core values that drive Stalwart’s development: privacy, performance, transparency, and user empowerment. The Stalwart Collaboration Server will transform the platform into a comprehensive, modern collaboration suite — one that is open, scalable, and fully self-hosted.

We look forward to sharing more progress soon. In the meantime, we invite developers, testers, and curious users to follow our work, contribute ideas, and help shape the future of self-hosted collaboration.

Stay tuned, and thank you for your continued support.

OpenID Connect Integration is now Open Source

Fri, 31 Jan 2025 00:00:00 GMT

Why is Stalwart Not 100% Free?

At Stalwart Labs, our goal is to provide a robust and feature-rich mail server solution. However, sustaining long-term development for a project of this scale requires significant financial resources. At present, open-source sponsorships alone do not generate sufficient funding to cover these costs entirely.

To ensure that Stalwart Mail Server continues to evolve and improve, we offer a paid Enterprise version. Revenue from Enterprise subscriptions allows our team to dedicate full-time efforts to development, ensuring the continuous enhancement of both the open-source and paid versions. This funding model allows us to introduce new features while maintaining the high standards that make Stalwart Mail Server a leading solution in the industry.

Furthermore, the existence of an Enterprise edition directly benefits the open-source community. By sustaining active development, we can periodically release new features into the open-source version, as we have done with third-party OIDC support. It is worth noting that even the community edition of Stalwart Mail Server already provides more features than any other open-source or commercial mail server available today. We are dedicated to maintaining and expanding this competitive edge.

If you would like to support open-source development and help accelerate the release of additional features as open-source, we invite you to become a sponsor. Your sponsorship plays a vital role in the project’s sustainability and future growth. Thank you for your support and understanding.

Join Us at FOSDEM 2025

To learn more about Stalwart Mail Server and its latest developments, we invite you to watch our talk at FOSDEM 2025. The session will take place tomorrow, Saturday, February 1st, at 12:00 PM Central European Time in Brussels. If you cannot attend in person, you can follow the presentation online at fosdem.org.

We look forward to sharing more about the project and engaging with the community at this exciting event!

Goodbye Spam: Introducing Faster, Smarter Spam Filtering

Mon, 06 Jan 2025 00:00:00 GMT

A Faster, Smarter Spam Filter

In earlier versions of Stalwart Mail Server, the spam filter was implemented as a Sieve script. This design choice was inspired by platforms like Rspamd, which use scripting languages like Lua to allow customizations. However, over time, we identified two key challenges with this approach. First, because it was an interpreted script, the spam filter’s performance was slightly slower than we’d like. Second, many users found it complicated to update the script when adding custom rules or configuring custom DNSBL (Domain Name System Blocklist) servers.

To address these issues, we rewrote the spam filter entirely in Rust. The result is a system that is five times faster than before, delivering superior performance while keeping resource usage minimal. Moreover, defining new rules or adding DNSBL servers is now as simple as editing the configuration file—no scripting expertise required. This shift eliminates complexity while maintaining the high level of customization our users expect. For those who still need advanced control, Stalwart continues to support custom Sieve scripts and expressions, ensuring maximum flexibility.

Enhanced Training

One of the most requested features we’ve added is the ability for end users to train their own spam filter Bayesian model. Now, users can customize their spam filtering by simply moving messages to and from the “Junk Mail” folder or by adding and removing the $Junk flag. This personalized approach allows each account to maintain its own tailored spam filter, providing greater accuracy and user satisfaction.

Improved Performance

This update isn’t just about the spam filter. We’ve also made broader performance enhancements to Stalwart Mail Server. Previously, we relied on LRU (Least Recently Used) caches. With this release, we’ve switched to scan-resistant S3-FIFO caches, offering better performance under heavy workloads. Additionally, we’ve optimized Stalwart’s handling of large distributed SMTP queues, ensuring smoother operation in clustered environments. These changes make Stalwart even more capable of handling demanding enterprise setups.

Meet Us at FOSDEM’25

We’re thrilled to announce that Stalwart Mail Server will be featured at FOSDEM’25! Join us on February 1st at 12:00 PM in Brussels, where we’ll showcase these new features and share insights into what’s coming next for Stalwart. This is a fantastic opportunity to connect with our team, ask questions, and explore how Stalwart can power your email infrastructure.

Upgrade Today

These improvements are available now, and we’re confident they’ll make a big difference for administrators and users alike. Whether you’re drawn to the speed of the new spam filter, the enhanced training capabilities, or the overall performance boosts, this update is designed to help you get the most out of Stalwart Mail Server.

As always, thank you for choosing Stalwart. We’re committed to delivering a reliable, feature-rich email server that evolves with your needs. Here’s to a productive and spam-free 2025!

Diagnose and Resolve Email Issues Faster

Wed, 04 Dec 2024 00:00:00 GMT

Advanced Troubleshooting

One of the key highlights of version 0.10.7 is the addition of comprehensive troubleshooting tools designed to help administrators diagnose and resolve email delivery and DMARC-related issues more efficiently.

The email delivery troubleshooting tool provides a step-by-step simulation of the email delivery process. Accessible through the Webadmin interface under Manage -> Troubleshoot -> Email Delivery, this tool allows administrators to test delivery paths for any email address or domain. It performs critical tasks like resolving MX records, retrieving IP addresses, validating MTA-STS and DANE policies, upgrading the connection to TLS, and verifying recipient availability. Importantly, this tool does not send actual emails but offers a detailed analysis of the delivery pipeline, displaying each step in real-time and flagging any issues that arise. This ensures that administrators can identify and address problems before they impact actual email traffic.

The DMARC troubleshooting tool is another powerful addition. Located under Manage -> Troubleshoot -> DMARC, it enables administrators to verify the DMARC setup for both local and remote domains. By simulating the server’s authentication process, this tool checks SPF, DKIM, ARC, and DMARC policies while also verifying that the reverse PTR matches the SPF EHLO hostname. Administrators can input details such as the sender address, server IP, EHLO hostname, and optionally, the message body for detailed DKIM and ARC testing. This comprehensive tool mirrors the checks Stalwart performs when receiving emails, making it easier to identify and resolve policy compliance issues.

External Recipients

Another significant enhancement in version 0.10.7 is the ability to add external recipients to mailing lists. In previous versions, mailing lists were restricted to local recipients, limiting their flexibility. With this update, administrators can now include recipients from external domains in mailing lists, enabling broader collaboration and more versatile email distribution. This change reflects our commitment to making Stalwart Mail Server more adaptable to the diverse needs of our users.

Azure Blob Storage

In addition to the major feature updates, Stalwart Mail Server 0.10.7 introduces support for storing emails and blobs on Azure Blob Storage. This new capability provides users with greater flexibility in managing their data storage, especially for organizations already leveraging Azure’s robust cloud infrastructure. The release also includes a range of minor fixes to improve overall stability and performance.

Looking Ahead

As we celebrate the release of version 0.10.7, we are already working on the next major feature: faster and improved spam filtering. This enhancement, another highly requested feature, will bring more effective tools to combat unwanted emails while ensuring legitimate messages are processed efficiently. We are eager to share more details in the coming weeks.

Shape the Future

Stalwart Mail Server continues to evolve based on feedback from our community. New features and improvements are implemented in the order of the votes they receive, ensuring that development aligns with the needs of our users. We invite you to visit our GitHub page to review the current list of enhancement requests and vote for the features you would like to see implemented next. You can find the list at GitHub Enhancement Requests.

Thank you for your ongoing support and feedback, which are instrumental in shaping Stalwart Mail Server into the reliable, user-focused solution it is today. We look forward to hearing your thoughts on version 0.10.7 and what you’d like to see in future releases!

Revolutionize Your Email Workflow with AI

Mon, 07 Oct 2024 00:00:00 GMT

Unlocking the Power of AI

With the introduction of AI model integration, Stalwart Mail Server can now analyze email content more deeply than traditional filters ever could. For instance, in the realm of spam filtering and threat detection, AI models are highly effective at identifying patterns and detecting malicious or unsolicited content. The system works by analyzing both the subject and body of incoming emails through the lens of an LLM, providing more accurate detection and filtering.

In addition to bolstering security, AI integration enhances email classification. By configuring customized prompts, administrators can instruct AI models to categorize emails based on their content, leading to more precise filtering and organization. This is particularly useful for enterprises managing a high volume of messages that span various topics and departments, as AI-driven filters can quickly and intelligently sort messages into categories like marketing, personal correspondence, or work-related discussions.

The flexibility of using either self-hosted or cloud-based AI models means that Stalwart can be tailored to your infrastructure and performance needs. Self-hosting AI models ensures full control over data and privacy, while cloud-based models offer ease of setup and access to highly optimized, continuously updated language models.

LLMs in Sieve Scripts

One of the most exciting features of this release is the ability for users and administrators to access AI models directly from Sieve scripts. Stalwart extends the Sieve scripting language by introducing the llm_prompt function, which allows users to send prompts and email content to the AI model for advanced processing.

For example, the following Sieve script demonstrates how an AI model can be used to classify emails into specific folders based on the content:

require ["fileinto", "vnd.stalwart.expressions"];

# Base prompt for email classification
let "prompt" '''You are an AI assistant tasked with classifying personal emails into specific folders.
Your job is to analyze the email's subject and body, then determine the most appropriate folder for filing.
Use only the folder names provided in your response.
If the category is not clear, respond with "Inbox".

Classification Rules:
- Family:
   * File here if the message is signed by a Doe family member
   * The recipient's name is John Doe
- Cycling:
   * File here if the message is related to cycling
   * File here if the message mentions the term "MAMIL"
- Work:
   * File here if the message mentions "Dunder Mifflin Paper Company, Inc." or any part of this name
   * File here if the message is related to paper supplies
   * Only classify as Work if it seems to be part of an existing sales thread or directly related to the company's operations
- Junk Mail:
   * File here if the message is trying to sell something and is not work-related
   * Remember that John lives a minimalistic lifestyle and is not interested in purchasing items
- Inbox:
   * Use this if the message doesn't clearly fit into any of the above categories

Analyze the following email and respond with only one of these folder names: Family, Cycling, Work, Junk Mail, or Inbox.
''';

# Prepare the base Subject and Body
let "subject" "thread_name(header.subject)";
let "body" "body.to_text";

# Send the prompt, subject, and body to the AI model
let "llm_response" "llm_prompt('gpt-4', prompt + '\n\nSubject: ' + subject + '\n\n' + body, 0.6)";

# Set the folder name
if eval "contains(['Family', 'Cycling', 'Work', 'Junk Mail'], llm_response)" {
    fileinto "${llm_response}";
}

This example demonstrates how the llm_prompt function can be used to classify emails into different categories such as Family, Cycling, Work, or Junk Mail based on the content. The AI model analyzes the message’s subject and body according to the classification rules defined in the prompt and returns the most appropriate folder name. The email is then automatically filed into the correct folder, making it easier to organize incoming messages based on their content.

Self-Hosted or Cloud-Based

With this new feature, Stalwart Mail Server allows for seamless integration with both self-hosted and cloud-based AI models. If you prefer full control over your infrastructure, you can opt to deploy models on your own hardware using solutions like LocalAI. Self-hosting gives you complete ownership over your data and ensures compliance with privacy policies, but it may require significant computational resources, such as GPU acceleration, to maintain high performance.

Alternatively, you can integrate with cloud-based AI providers like OpenAI or Anthropic, which offer access to powerful, pretrained models with minimal setup. Cloud-based models provide cutting-edge language processing capabilities, but you should be aware of potential costs, as these providers typically charge based on the number of tokens processed. Whether you choose self-hosted or cloud-based models, Stalwart gives you the flexibility to tailor the AI integration to your specific needs.

Available for Enterprise Users and Sponsors

This exciting AI integration feature is exclusively available for Enterprise Edition users as well as GitHub and OpenCollective monthly sponsors. If you want to harness the full potential of AI-powered email processing in Stalwart Mail Server, upgrading to the Enterprise Edition or becoming a sponsor is a great way to access this feature and other advanced capabilities.

Try It Out Today!

The release of Stalwart Mail Server v0.10.3 marks a major milestone in our journey toward building intelligent, highly customizable email management solutions. By combining traditional email filtering with the power of LLMs, Stalwart gives you the tools to take your email infrastructure to the next level, enhancing security, organization, and automation in ways that were previously impossible. We’re excited to see how you’ll use this new feature to optimize your email workflows!

OpenID Connect - Secure Authentication Just Got Easier

Wed, 02 Oct 2024 00:00:00 GMT

What is OpenID Connect?

OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0 that allows clients to verify the identity of users. With OIDC, instead of just authorizing an app to access a resource, the system can also authenticate the user securely. This means users can log in to multiple applications with a single set of credentials, making OIDC ideal for Single Sign-On (SSO) across services.

Why is this important? Because it saves users from password fatigue, reduces login complexity, and centralizes authentication in a secure manner. Stalwart Mail Server’s new OIDC support allows you to authenticate your users either directly through Stalwart as an OpenID Provider or by integrating with third-party OIDC providers like Authentik, Keycloak, or any compliant identity system.

Alongside full OIDC support, Stalwart Mail Server v0.10.2 also introduces several important new features that expand its capabilities:

OpenID Connect Dynamic Client Registration

Dynamic Client Registration allows clients (applications) to automatically register with the OIDC provider without requiring manual intervention. This feature makes it easier to integrate multiple applications, as clients can dynamically obtain credentials (like client IDs) directly from Stalwart Mail Server. This adds flexibility and reduces administrative overhead.

OpenID Connect Discovery

With the OpenID Connect Discovery feature, clients can automatically discover the relevant OIDC endpoints and supported capabilities via the /.well-known/openid-configuration endpoint. This simplifies the configuration of OIDC clients, as they don’t need to be manually configured with URLs for token, authorization, and userinfo endpoints — they just query the discovery endpoint and set themselves up!

OAuth 2.0 Token Introspection

OAuth 2.0 Token Introspection allows resource servers (like APIs or mail servers) to validate access tokens provided by clients. This ensures that the token being used is still active, hasn’t expired, and has the right permissions attached. This is particularly useful for securing interactions between various services while verifying that tokens are still valid.

OpenID Provider or Third-Party OIDC Support

Stalwart Mail Server v0.10.2 can now act as an OpenID Provider (issuing ID tokens and managing authentication), which means your organization can use it to handle authentication for all your internal applications and services. Alternatively, Stalwart can also integrate with third-party OIDC providers, so you can delegate authentication to systems like Authentik or Auth0, while still using Stalwart to manage your email infrastructure.

This dual functionality gives you the flexibility to choose how you want to manage authentication while taking full advantage of OIDC’s security features.

About OAUTHBEARER…

Now, let’s talk about mail clients and the OAUTHBEARER SASL mechanism. While Stalwart fully supports OIDC, the majority of mainstream mail clients (looking at you, Outlook, Thunderbird, and Apple Mail) still don’t support OAUTHBEARER for OAuth-based authentication. Sure, we’ve done our part by adding OpenID support to Stalwart — now it’s up to the mail clients to follow suit and add proper support for OIDC authentication. Maybe one day, we’ll see these clients finally catch up, and we can all enjoy the seamless authentication experience that OIDC offers.

In the meantime, users of these clients will need to continue using App Passwords to access their email accounts. But hey, maybe this is the gentle nudge the developers of these clients need to jump on the OpenID bandwagon!

Try It Out

Stalwart Mail Server v0.10.2 is available now, so download it, upgrade your server, and start taking advantage of these new features! Whether you’re setting up Stalwart as your OpenID Provider or integrating with a third-party provider, this release gives you the tools to secure authentication with modern standards like OpenID Connect.

Happy mailing and happy authenticating!

Stalwart | Stalwart Blog

DKIM2 and DMARCbis have landed, and Stalwart speaks them first

Meet DKIM2

Issues with DKIM1

DKIM2, in a nutshell

One mechanism per broken promise

Recipes: putting a message back the way it was

A message through two hops

Bounces carry their own proof

ARC steps aside

Meet DMARCbis

TL;DR

A quick refresher on DMARC

Issues with DMARC

DMARCbis, one specification becomes three

Climbing the tree instead of trusting a list

Tuning the record: what arrived, what retired

The p=reject reality check

Reporting grows up

What stayed exactly the same

Both protocols live in Stalwart today

Looking forward

Zero open bug reports: The road to Stalwart 1.0

Latest fixes

Road to 1.0

ETA

Migration proxy: zero-downtime upgrades

A single endpoint in front of two deployments

Migrating from other self-hosted systems

Documentation and where to start

Upgrading to v0.16 now, or waiting for 1.0

Vandelay: the JMAP importer-exporter

What Vandelay does

Account backup tool

Migrating from legacy servers and formats

Moving off Google and Microsoft Exchange

Sovereignty over your data

What is next

MTA Hooks at the IETF

What is MTA Hooks

Why it was built

Why standardization matters

How the IETF actually works, briefly

Where MTA Hooks is right now

How you can help

What is next

Introducing the Stalwart Support Portal

What the support portal is

How to sign in

What happens to the existing channels

Enterprise support

Looking forward

Stalwart v0.16: A New Foundation

A Brand-New WebUI

Unified Management via JMAP and a New CLI

Automated DNS Management

Automated DKIM Rotation

Masked Emails

Security Enhancements

Other Highlights

Upgrading

Marginal Gains: Major Impact

Rethinking Spam Classification

A Faster, Simpler Search Layer

Faster Database Access and Leaner Storage

Meet Us at FOSDEM 2026

Looking Ahead

JMAP for Calendars, Contacts and Files now in Stalwart

A New Generation of Protocols

Limitations of Yesterday’s Technology

JMAP: A Modern Solution for Modern Needs

Why This Matters

Client Support and Ecosystem

A Word of Thanks

Looking Ahead to 1.0.0

Security at the Core: Stalwart completes Second Security Audit

Comprehensive Assessment

Findings

Our Commitment to Security

Stalwart Joins GitHub's Open Source Secure Fund