I sometimes receive aggregate TLS reports from Google in my catchall inbox while they are not being detected by Stalwart.
The setup
Two domains with multiple accounts and one catchall address each: mycatchall1.com, mycatchall2.com
Stalwart runs under the domain: mystalwart.com
In Stalwart under Reports → Inbox → TLS i can see nearly-daily reports from Google ([email protected]) to [email protected] with “Report Domain: mystalwart.com” but not referencing any of the other domains.
No TLS reports addressed to other domains are listed in there.
In my catch-all inboxes I have received three TLS reports from google so far:
Reviewing the Stalwart-generated Zone file for my catch-all domains, the following DNS entries will be shown (synced if auto sync enabled):
_dmarc.catchall1.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"
_smtp._tls.catchall1.com. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"
catchall1.com. IN CAA 0 iodef "mailto:[email protected]"
So Stalwart intentionally won’t set the postmaster address of the Stalwart server ([email protected]) but also won’t handle the incoming TLS reports to the catch-all domains correctly.
I can not say if other incoming reports are affected since I only got TLS reports so far but DMARC reports listed in the Stalwart Web UI also only include Report Domain mystalwart.com
Possible Workarounds
I could change the mailto: addresses in the DNS records to [email protected], but this will be overridden by the automated DNS sync
Stalwart could change the advertised postmaster addresses to the Stalwart base domain
Settings
In Stalwart Settings → MTA → Reports → General “Report Addresses” postmaster@* is configured as report address. I just turned off the “Forward” setting after discovering it, but nonetheless the report mails are not being handled by Stalwart correctly so I doubt this setting will affect the behavior.
Expected Behavior
The aggregates should be correctly handled by Stalwart and not sent to the inbox.
Reproduction Steps
Add a new domain + account
Configure the catch-all address to be this account for set domain
Let me look into how Stalwart handles incoming TLS/DMARC report detection to better understand the routing logic.
This looks like a genuine bug or a current limitation in how Stalwart intercepts inbound reports. Based on the source code and your description, here’s what appears to be happening:
Root cause: Stalwart’s inbound report interception appears to match incoming TLS/DMARC report emails against its configured inbound_report_addresses. The DNS zone generator for your catchall domains (mycatchall1.com, mycatchall2.com) advertises postmaster@<thatdomain> as the report address (e.g. _smtp._tls.mycatchall1.com TXT "v=TLSRPTv1; rua=mailto:[email protected]"). When Google delivers the report to [email protected], Stalwart does not recognise that address as a report sink and delivers it to the mailbox normally instead.
Reports for [email protected] (your Stalwart base domain) are intercepted correctly because that address is what gets registered as the report handler.
Workarounds you can try right now:
Override the report URI per domain — In Stalwart’s domain settings for each catchall domain, check if there is a “Report Address URI” field that lets you override the advertised mailto: to point to [email protected] instead of the per-domain postmaster. This would override what gets published in DNS without you having to manually edit zone files.
Add [email protected] / [email protected] to the “Report Addresses” list — In Settings → MTA → Reports → General, the postmaster@* wildcard should match these, but confirm the wildcard is actually evaluated as a glob and not a literal. Try adding the explicit addresses as a test.
Disable auto DNS sync and manually set the rua= targets to [email protected] in your DNS until Stalwart’s zone generator supports per-domain overrides.
This does appear to be a real limitation worth filing as a bug on the Stalwart GitHub issue tracker, since the auto-generated DNS records and the report interception logic are not fully in sync for multi-domain setups where the Stalwart base domain differs from the hosted domains.
The related forum topic you found about DKIM reports not being intercepted when the destination is a list suggests this is a known class of interception-matching issues.
This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong. If you found it useful, mention @helpbot in any reply to ask follow-up questions and the bot will respond again.
Let me look into how Stalwart handles incoming TLS/DMARC report detection to understand the root cause.
This is a well-described bug report. Here’s what the docs reveal about the root cause:
Root cause: The inboundReportAddresses setting (default ["postmaster@*"]) is what tells Stalwart to intercept and analyse an incoming report rather than deliver it as regular mail. The wildcard * matches any domain, so [email protected] and [email protected]should be matched — but only if those addresses are routable on the server.
The docs explicitly note: “These addresses must be routable.” That is almost certainly the key constraint here. Even though postmaster@* is the pattern, Stalwart won’t intercept a message unless it can verify the recipient address is actually handled by this server. If [email protected] isn’t explicitly routable (e.g. the domain exists but only a catch-all account handles it, with no dedicated postmaster mailbox or alias), the interception step may be skipped and the message falls through to the catch-all.
Suggested next steps to investigate:
Create a postmaster alias or account on each of your catch-all domains (e.g. [email protected], [email protected]) so those addresses are explicitly routable, not just caught by the catch-all.
Alternatively, if you want the DNS-published rua/_smtp._tls addresses to point at [email protected] instead of the per-domain postmaster, you can override the reportAddressUri field on each domain object to point to mailto:[email protected] — but be aware the DNS auto-sync task will regenerate those records and they need to be re-synced after any such change.
The inboundReportForwarding toggle you found only controls whether reports are forwarded after interception — it doesn’t affect whether they’re intercepted in the first place, so your instinct there was correct.
This looks like a legitimate gap (or at least a docs/UX gap) where the auto-generated DNS records point to per-domain postmaster addresses that aren’t explicitly provisioned as routable mailboxes, causing the interception to silently fail. This is worth filing as a bug or feature request on the Stalwart GitHub if it’s confirmed.
This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong. If you found it useful, mention @helpbot in any reply to ask follow-up questions and the bot will respond again.