My most recently added domain is forwarding inbound reports to the end user even though the Forward reports switch is off. All previously added domains are working correctly and don’t forward reports.
What makes this even stranger is it is sending reports between two local domains, so the report is actually being generated by Stalwart, being received by Stalwart, then being forwarded.
I was positive there was an issue raised that local to local reports were supposed to be suppressed, but I can’t find it in the forum search. If this is the case, then this is a two for one.
Stalwart Version
v0.16.x
Installation Method
Binary (Linux)
Database Backend
PostgreSQL
Blob Storage
S3-compatible
Search Engine
Internal
Directory Backend
Internal
Additional Context
I believe the domain itself was added in 0.16.15 or 0.16.16
The postmaster alias was forgotten and wasn’t added until 0.16.18. I saw postmaster get a 550 in the log.
The report behavior was then spotted under 0.16.18.
I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.
on
I have searched this support forum (open and closed topics) and confirm this is not a duplicate.
on
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.
Can you open one of the reports that landed in the mailbox and check who sent it? The envelope sender and the org_name in the XML are the two fields I care about. If they come back as your own hostname, your server generated that report and it never came in over SMTP at all, which puts it on a different path through the code than the one the forwarding switch covers.
I ask because the forwarding setting and the address list it matches against are server-wide, not per-domain. A report arriving over SMTP gets matched during the DATA stage and dropped there, before it is ever queued, and that happens the same way for every domain you host. If inbound reports were slipping through, you would see it on all of them.
What does vary per domain is the rua you publish in DNS. If the new domain has rua=mailto:postmaster@thatdomain, then your server is generating aggregate reports for it and posting them to itself through the queue, which never reaches the DATA stage check at all. That lines up with what you saw about reports being generated and received locally, and it fits the timing too: before the postmaster alias existed there was nowhere to deliver them, so they just failed.
So: what is the rua on the affected domain, and what is it on one of the domains that behaves? And does the message carry a Received header from an outside host, or does the chain start on your own machine?
Also, is there anything sitting in front of Stalwart that connects with SMTP auth, a filtering service or a relay of your own? The report check is skipped on authenticated sessions, so anything coming in that way is delivered normally regardless of the switch.
The envelope_from is my Postmark Return Path for the local domain in question.
The report is all pass results.
My guess would be these reports are being generated locally in response to my voicemails being received from my PBX, which are sent via Postmark.
All domains I host are the same, default of postmaster@domain. I alias all postmaster@domains to my administration account (when I remember to).
There are actually no received headers. The fact it is signed with DKIM2, and the From is "Report Subsystem" <[email protected] confirms it was generated locally.
Full headers, domains masked:
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Delivered-To: [email protected]
X-Spam-Status: No
DKIM-Signature: v=1; a=ed25519-sha256; s=v1-ed25519-20260801; d=serverdomain.ca; <remainder stripped>
DKIM-Signature: v=1; a=rsa-sha256; s=v1-rsa-20260801; d=serverdomain.ca; <remainder stripped>
Message-Instance: m=1; h=sha256:A5Vh3j+R5JnAph564FAhOBElLhw/+uXbFEaC2Ql/ u8s=:TqQKH2FIcL/WT2w+xAShhdqidb9IOvLiOlHxjms45b0=;
DKIM2-Signature: i=1; m=1; t=1787977924; d=serverdomain.ca;
From: "Report Subsystem" <[email protected]>
To: <[email protected]>
Auto-Submitted: auto-generated
Message-ID: <18d02c73026787f2.a1b478768024b69f.c4c3479449f1f0ab@mx.serverdomain.ca>
Subject: =?us-ascii?Q?Report_Domain:_localdomain.com_Submitter:_mx.<stripped for privacy but is server domain encoded>
Date: Sat, 29 Aug 2026 04:32:04 +0000
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="18d02c730267cb1d_6e80859c0afafc03_7ae2534a4ca8657e"
No, simple one node, one MX record going straight to it. No filter, sieve, milter, etc. unless it’s built-in and default.
I agree, and I can turn forwarding on and receive those, so that whole subsystem is working correctly. This one report being generated locally is the one going a different route and passing through.
That begs the question, are they being processed as reports at all, or just being delivered as a normal Email?
A quick look at my inbound DMARC reports confirms NO, these are not being processed as reports at all.
That explains the forwarding, since these are being missed as reports. Stalwart just thinks they are normal Email.
In the time frame concerned, I have logged reports from Amazon SES and Google for this local domain, so reports received via SMTP are working correctly.
That should really narrow it down, but let me know if you need any other details.
