I need support for setting up stalwart as mx backup server

Questions
1

Your question

The documentation for a beginner using stalwart is simply inadequate. The primary server is running perfectly. But I am not able to manage setting up Stalwart as a mx backup when the the primary server is down. Can anybody guide me with step by step information how to set up Stalwart as a mx backup server from scratch, also spf record and dmarc record?
I am using the latest stalwart version.
Seriously. I’m truly at my wit’s end.

I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.

on

2

Setting up a backup MX involves two pieces: an extra MX record with a higher priority number pointing at the backup host, and configuring the backup Stalwart instance to accept and relay mail for the domain until the primary is reachable again.

1. DNS – add a second MX record

Add a higher-priority (higher number = lower preference) MX record for your domain pointing at the backup server, alongside the existing primary record:

MX  example.org.  10 mail.example.org.       ; primary
MX  example.org.  20 backup.example.org.     ; backup

Receiving servers will prefer the primary (lowest number) and only fall back to the backup host if the primary can’t be reached. This is described in the DNS setup docs.

2. Backup server – accept mail for the domain and relay it onward

On the backup Stalwart instance, the domain won’t have local mailboxes, so it needs to accept mail as a relay rather than reject unknown recipients. Set allowRelaying: true on the Domain object for example.org, and configure allowRelaying on MtaStageRcpt so the backup accepts mail for that domain even though the sender isn’t authenticated. Details are in RCPT stage / Relay.

3. Route the accepted mail toward the primary

Configure outbound routing on the backup server so mail accepted for that domain is delivered to the primary server (as an MX/Relay route), rather than resolved normally via DNS — otherwise it would just loop back through the same MX records. Stalwart’s failover-delivery pattern under Outbound Routing shows exactly this: an Mx route for the domain, with a Relay route pointing at a specific fallback host if delivery to the primary fails, selected via the retry_num expression. For a backup MX, you’d typically set up a Relay route on the backup box pointing directly at the primary’s hostname/IP, so it keeps retrying delivery to the primary until it comes back up (the message queue on the backup will hold and retry automatically).

4. SPF / DMARC

SPF and DMARC are published once per domain and don’t need to differ for backup vs primary — they authorize sending hosts, not receiving hosts. Publish:

TXT  example.org.        v=spf1 mx ra=postmaster -all
TXT  _dmarc.example.org. v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]

Using mx in the SPF record automatically covers any host listed in your domain’s MX records (primary and backup), so no extra SPF entry is needed for the backup MX. See SPF and DMARC.

If your backup server should just accept and queue mail without needing knowledge of local users at all, make sure it has no matching Directory-based accounts for example.org, only the relaying flags above — that’s what tells Stalwart “don’t look for a local mailbox, just hold and forward.”

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.

3

How to change this or better what to change on MtaStageRcpt. There is !is_empty(authenticated_as) only. I do not know what to put in there

4

allowRelaying on the RCPT stage is an expression, so you add a clause for the domain you’re backing up, for example !is_empty(authenticated_as) || rcpt_domain == 'example.org'. That is what makes the server accept RCPT for a domain it doesn’t host. It’s on the inbound RCPT page under Relay, at stalw.art/docs/mta/inbound/rcpt.

The important thing not to do is create a Domain object for that domain. That makes it local, and then unknown recipients get rejected and mail is routed for local delivery instead of being forwarded, which is the opposite of what you want.

For the forwarding half, define a route of type Relay with the address set to the primary’s hostname, then add a branch to the route expression on your outbound strategy selecting it for that domain. Don’t leave it to the normal MX route: the backup’s own MX record is in that domain’s MX set, so you can loop. Then raise the queue expiry on the schedule that applies, since it defaults to three days and a backup MX that bounces after three days of primary downtime isn’t much of a backup; five to seven is usual. DNS is just a second MX record with a higher preference number pointing at the Stalwart host, and SPF and DMARC need no changes since a store-and-forward backup never originates mail as that domain.