I am having a tough time getting rspamd-mailcow to not flag good mail as spam and putting it in the junk folder. I have many emails going to junk when they should not. Even when I move those messages to my inbox, future emails still get flagged as spam. I even have white listed those senders and yet the emails still get rejected or put into the junk folder. Some of these emails are from my bank, for instance, so they really should not be labeled as junk. Here is a log snippet from one example of an email where I have whitelisted the sender but still it is flagged: Score [ 27.66 / 40 ] Symbols DMARC_POLICY_REJECT (16) [sliceglobal.com : No valid SPF, reject] R_SPF_FAIL (8) [-all] R_DKIM_REJECT (8) [sliceglobal.com:s=s1] FORGED_W_BAD_POLICY (3) URIBL_GREY (2.5) [sendgrid.net:url] SUSPICIOUS_URL_IN_SUSPICIOUS_MESSAGE (1) MID_RHS_NOT_FQDN (0.5) MV_CASE (0.5) MIME_HTML_ONLY (0.2) BAYES_HAM (-5.178923) [99.25%] LOCAL_FUZZY_WHITE (-4.719406) [13:30f6169004:0.90:txt] IP_REPUTATION_HAM (-1.033108) [asn: 398019(-0.39), country: US(-0.01), ip: 72.51.58.38(-0.64)] I had this email sent again and the second time it did not reject it but did but it in the junk folder. In the log it lsted the Action as "Add header" instead of "Reject" Not sure what to look for to resolve these types of false positives. I thought moving said emails to the inbox or whitelisting them would prevent these actions. Any insight is appreciated.

> @"tyarmas"#p31162 DMARC_POLICY_REJECT (16) [sliceglobal.com : No valid SPF, reject] > R_SPF_FAIL (8) [-all] > R_DKIM_REJECT (8) [sliceglobal.com:s=s1] > FORGED_W_BAD_POLICY (3) > URIBL_GREY (2.5) [sendgrid.net:url] This looks like the sender really f*cked up their mailserver config... do you really trust them? Then go to System -> Configuration -> Global filter maps Check the box at “I will be careful!” and head over to “Header-From: Allowlist” Add the domain like `/.+sliceglobal\.com/i` Click “Validate” and then “Save changes”

Thanks very much for the reply. Yes I do trust them, but do not have a way to make them change their config ;) Ironically, this is their way of doing 2FA and they do not have other options. I did see a post about doing ht you suggest, but I am wondering why the white listing and/or moving to the inbox does not change behavior. Am I missing something? Bug?

I looked into it a bit more and according to mxtoolbox.com and a dns query, this domain has a valid SPF record. So not sure why RSPAMD is not seeing it.

Are you running mailcow at home with some kind of reverse proxy?

no, it is hosted at a cloud provider

seeing this on too many domains. Symbols R_SPF_FAIL (8) [-all] R_DKIM_REJECT (8) [alignedortho.com:s=selector-1653576630, aro365532573.onmicrosoft.com:s=selector2-aro365532573-onmicrosoft-com] DMARC_POLICY_QUARANTINE (8) [alignedortho.com : No valid SPF, quarantine] EMPTY_SUBJECT (1) FROM_NAME_EXCESS_SPACE (1) ARC_REJECT (0.1) [signature check failed: fail, {[1] = sig:microsoft.com:reject}] BAYES_HAM (-1.707842) [86.39%] But that domain does have valid SPF records. and again, mxtoolbox.com shows no errors or warnings for mail server

Ok, there's definitely something off with your mailcow setup... anything special? Is unbound working at all? Errors in the logs anywhere?

unbound is working, but I do see some errors in the log. sudo docker logs -f mailcowdockerized-unbound-mailcow-1 Setting console permissions... Receiving anchor key... Receiving root hints... ######################################################################## 100.0% setup in directory /etc/unbound Certificate request self-signature ok subject=CN=unbound-control removing artifacts Setup success. Certificates created. Enable in unbound.conf file to use 2026-03-06 17:58:36,920 INFO Set uid to user 0 succeeded 2026-03-06 17:58:36,928 INFO supervisord started with pid 1 2026-03-06 17:58:37,934 INFO spawned: 'processes' with pid 23 2026-03-06 17:58:37,946 INFO spawned: 'syslog-ng' with pid 24 2026-03-06 17:58:37,958 INFO spawned: 'unbound' with pid 25 2026-03-06 17:58:37,986 INFO spawned: 'unbound-healthcheck' with pid 26 [1772837918] unbound[25:0] notice: init module 0: subnetcache [1772837918] unbound[25:0] notice: init module 1: validator [1772837918] unbound[25:0] notice: init module 2: iterator Mar 6 17:58:38 e0b783a88285 syslog-ng[24]: syslog-ng starting up; version='4.8.1' [1772837918] unbound[25:0] info: start of service (unbound 1.22.0). 2026-03-06 17:58:39,101 INFO success: processes entered RUNNING state, process has stayed up for > than 1 seconds (startsecs) 2026-03-06 17:58:39,102 INFO success: syslog-ng entered RUNNING state, process has stayed up for > than 1 seconds (startsecs) 2026-03-06 17:58:39,102 INFO success: unbound entered RUNNING state, process has stayed up for > than 1 seconds (startsecs) 2026-03-06 17:58:39,102 INFO success: unbound-healthcheck entered RUNNING state, process has stayed up for > than 1 seconds (startsecs) [1772837919] unbound[25:0] info: generate keytag query _ta-4f66-9728. NULL IN 2026-03-06 18:37:36: Healthcheck: DNS Resolution Failed on attempt 1 for github.com! Trying again... 2026-03-06 18:47:20: Healthcheck: DNS Resolution Failed on attempt 1 for github.com! Trying again... 2026-03-06 18:58:56: Healthcheck: DNS Resolution Failed on attempt 1 for hub.docker.com! Trying again... [1772878076] unbound[25:0] info: generate keytag query _ta-4f66-9728. NULL IN 2026-03-07 09:05:07: Healthcheck: DNS Resolution Failed on attempt 1 for hub.docker.com! Trying again... 2026-03-07 10:01:01: Healthcheck: Failed to ping 9.9.9.9 on attempt 1. Trying again... However when I attach to th container and try ping or dig on those, I do not get errors

Which is your VPS provider? Any other firewall than the mailcow firewall in place?

dynu.com is VOS provider. No other firewalls as far as I know playing around with dig and ping commands in rspamd vs unbound containers, I see some ping and dig failures in rspamd but not unbound. seems intermittent

Too many SPAM false positives

tyarmas

DocFraggle

Still having issues with rspamd flagging emails it should not. I am not sure why things are going this way and am wondering why I would need to edit the Global filter maps. Why is whitelisting the domains or he sender enough?

[unknown]

And for that matter, I thought moving messages from the junk folder to the inbox would allow rspamd to learn and no longer mark those as spam. Am I wrong?

Kevo

tyarmas And for that matter, I thought moving messages from the junk folder to the inbox would allow rspamd to learn and no longer mark those as spam. Am I wrong?

AFAIK, the learning done by moving a message from junk to inbox only affects the bayes spam/ham score, not all the other tests that get done. So a problem with DNS that causes SPF and DKIM to get scored badly is still going to be a very strong indicator of spam. If you are still having that issue, I would focus on that. Once you resolve that issue things should improve substantially with the spam scoring.

ETNyx

Hi, can you post full header of mail you think is false positive?

tyarmas

I meant to write why is whitelisting not enough in the previous post. I have tried whitelisting specific domains and senders to no avail. I am getting items from my bank, for example, that is treated as spam even though the bank domain is whitelisted and seems to be a legit sender. I do see in the logs that something would be soft rejected and then resent by the sender and still end up in the junk folder.

As for the headers from an email that should not be considered junk. See below:

X-Spam-Level: **************************************************
Account.Type: OLB
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on MX1
Authentication-Results: mailcow.yarmas.com; dkim=fail (“headers rsa verify failed”) header.d=message.truist.com header.s=20210204 header.b=c4Dc1SHC; dmarc=fail reason=“No valid SPF” header.from=message.truist.com (policy=reject); spf=fail (mailcow.yarmas.com: domain of alertnotifications@message.truist.com does not designate 72.51.58.35 as permitted sender) smtp.mailfrom=alertnotifications@message.truist.com
X-Last-Tls-Session-Version: TLSv1.3
X-Ironport-Av: E=Sophos;i=“6.23,158,1770613200”; d=“scan’208,217”;a=“122570263”
X-Ironport-Av: E=Sophos;i=“6.23,158,1770613200”; d=“scan’208,217”;a=“130195401”
Return-Path: alertnotifications@message.truist.com
X-Rspamd-Queue-Id: 8C503DF21C
X-Original-To: tom@justtasktom.com
X-Spam-Flag: YES
Customeralertid:
Arc-Seal: i=1; a=rsa-sha256; d=justtasktom.com; s=dkim; cv=none; t=1775242064; b=ebaxnKp8269zyEfoBtnO5g9rMjwS4SsCo5BUQ5mqlgJA8RO7lUIND5×8KUGiV6A4INTB7g jR3k7cqDNzqxxPBPEeti7IAC1tZLi9GffZxUAZ+0WMLMaU+KndFoCKkmFeMC+OCoEILwIk 9ZrjX4pfRSTCnS7pzIlc2IfQ3ecv8jaYExPaE4UF841kISdltml8mkXq7nadRVx/6rTUmW PK7F1bTSAQxJ1K0zC8Vng5hSUBHfxqNXmrg+LAjYvZBcmqIPg8H+9VIUv6rXPVsGe5Cb+F xbGBtc4tDPhQLjpnBz/XdRM+UKkm1rozzALIUTJ4V69QVB9MaNMO81M8/GG2ug==
X-Spamd-Result: default: False [24.67 / 40.00]; DMARC_POLICY_REJECT(16.00)[message.truist.com : No valid SPF,reject]; R_DKIM_REJECT(8.00)[message.truist.com:s=20210204]; R_SPF_FAIL(8.00)[-all]; BAYES_HAM(-5.43)[99.84%]; RBL_SENDERSCORE_REPUT_9(-1.00)[72.51.58.35:from]; IP_REPUTATION_HAM(-0.78)[asn: 398019(-0.39), country: US(-0.01), ip: 72.51.58.35(-0.38)]; MIME_HTML_ONLY(0.20)[]; RCVD_IN_DNSWL_MED(-0.20)[74.120.68.121:received]; MIME_GOOD(-0.10)[multipart/mixed]; MX_GOOD(-0.01)[]; RCVD_COUNT_THREE(0.00)[4]; CLAM_VIRUS_FAIL(0.00)[failed to scan and retransmits exceed]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:~]; GREYLIST(0.00)[pass,meta]; RCPT_MAILCOW_DOMAIN(0.00)[justtasktom.com]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MISSING_XM_UA(0.00)[]; ASN(0.00)[asn:398019, ipnet:72.51.58.0/24, country:US]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[tom@justtasktom.com]; CTYPE_MIXED_BOGUS(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[message.truist.com:-]; ARC_SIGNED(0.00)[justtasktom.com:s=dkim:i=1]; MAILCOW_WHITE_EXCLUDE(0.00)[]; FROM_HAS_DN(0.00)[]
X-Spam-Status: No, score=-500 required=5.0 tests=WHITELIST_RECEPIENT autolearn=no autolearn_force=no version=4.0.0
Msip_Labels: MSIP_Label_bc53fd28-7c6c-4226-ba59-0a48113e59e0_SiteId=55651e97-f81c-4b3b-9131-af8a1cd02346; MSIP_Label_bc53fd28-7c6c-4226-ba59-0a48113e59e0_SetDate=2026-04-03T18:46:38Z; MSIP_Label_bc53fd28-7c6c-4226-ba59-0a48113e59e0_Name=private; MSIP_Label_bc53fd28-7c6c-4226-ba59-0a48113e59e0_Method=Privileged; MSIP_Label_bc53fd28-7c6c-4226-ba59-0a48113e59e0_Enabled=true; MSIP_Label_bc53fd28-7c6c-4226-ba59-0a48113e59e0_ContentBits=1; MSIP_Label_bc53fd28-7c6c-4226-ba59-0a48113e59e0_ActionId=8e5e43ae-4f64-4968-9c78-c63748ceae5f;
2075385991.29773.1775241998807@ip-10-72-0-138.ec2.internal
Account.Id: 050200004491611511722094
X-Titans-Ident: stg:20260403-144638-ZNbfc1eOb]
Arc-Authentication-Results: i=1; mailcow.yarmas.com; dkim=fail (“headers rsa verify failed”) header.d=message.truist.com header.s=20210204 header.b=c4Dc1SHC; dmarc=fail reason=“No valid SPF” header.from=message.truist.com (policy=reject); spf=fail (mailcow.yarmas.com: domain of alertnotifications@message.truist.com does not designate 72.51.58.35 as permitted sender) smtp.mailfrom=alertnotifications@message.truist.com
X-Spam: Yes
Titan-Env: $w0m$[:prod#cloud]
X-Cse-Msgguid: XScUHZExTqOmoIDyTmtBrQ==
X-Cse-Msgguid: Rw7OTKeqQzi838d/n082Fg==
Mime-Version: 1.0
Received: from mailcow.yarmas.com ([fd4d:6169:6c63:6f77::10]) by 5b31d73395f5 with LMTP id cJWuHlAL0GkyYhkA3FkmEg (envelope-from alertnotifications@message.truist.com) for tom@justtasktom.com; Fri, 03 Apr 2026 14:47:44 -0400
Received: from mx1.wiredblade.com (mx1.wiredblade.com [72.51.58.35]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mailcow.yarmas.com (Postcow) with ESMTPS id 8C503DF21C for tom@justtasktom.com; Fri, 3 Apr 2026 14:47:42 -0400 (EDT)
Received: from mail12302.bbandt.com (mail12302.bbandt.com [74.120.68.121]) by mx1.wiredblade.com with ESMTPS (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256) ; Fri, 3 Apr 2026 18:47:39 +0000
Received: from unknown (HELO appliancehostname.parentdomain.com) ([172.25.26.10]) by mail12302.bbandt.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Apr 2026 14:47:41 -0400
Received: from prd-iptblk101.bbtnet.com (unknown [10.168.240.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by Forcepoint Email with ESMTPS id AC43A59D62CEF4FF976E for tom@justtasktom.com; Fri, 3 Apr 2026 14:47:40 -0400 (EDT)
Received: from unknown (HELO ip-10-72-0-138.ec2.internal) ([10.72.0.138]) by prd-iptblk101.bbtnet.com with ESMTP; 03 Apr 2026 14:46:38 -0400
Content-Type: multipart/mixed; boundary=“—-=_Part_29772_1046892350.1775241998795”
X-Ms-Exchange-Organization-Classification: private
Delivered-To: tom@justtasktom.com
X-Cse-Connectionguid: yW3vuRS0RCW36ZIFQSboLg==
X-Cse-Connectionguid: cMM6bAMjTAqEnFKtSvCBBQ==
Arc-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=justtasktom.com; s=dkim; t=1775242064; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: dkim-signature; bh=9hWMAAjU2wuwsm31ozyQI2CM86mUzu5WTobWBzLeb+8=; b=iwpA6wsIfOFHWKPfcNfEJVL1vv1E5updqpsI9LR1wRdBgcZEe7Mf+YS3jKcW/Ud9137QHl mPn5+KD83XelzEpmv4zzVrcdhzNZRUx5qze0jJCPQKJ4GCDp7hpuOP/3hAUheJ+pTY3a0B FhhPHOqIQTx35sAnwWvJLEwK0oyeLiLgAB/cTUViBNBHPGb3JJMi7u9aldr68jvZRfTxKu TGHNtSCLNBkECNlUQKkyc0+9VhsC0ppTGzgmuBnfpWXwsGLcsfwjsv9+VKhFYE4anfhEc5 Ixvo4pFKmaubOgP4fF8+dNG4QoXZr8JrdBp+B7EYBxsT9+fzsU8Zo6JqICCpOQ==
Dkim-Signature: v=1; a=rsa-sha256; c=simple/simple; d=message.truist.com; i=@message.truist.com; q=dns/txt; s=20210204; t=1775242062; x=1806778062; h=date:from:to:message-id:subject:mime-version; bh=3eOGrcfXW1LmERVEWTBA/t3m8jsUHAaFYzd/6F7n3Ps=; b=c4Dc1SHCIkXHxqTSc38P64wVAtghFW6Nalxs3oIzDj/3TOVMQW3LUvHO ZuM6VYwOCuRUi/k9HJ/VRb/jswW3GdbK9Z7y0q7haHmkrt/ZAJwYH0pGI 2q0Mr2bzJUWyKL9+6ctTrERkV8q5Va69h4T29k2jbpXxj1xgOdHw1/ey5 k=;

Kevo

You can see in the X-Spamd-Result header how the score was calculated. If you can’t do anything about the SPF and DKIM issues then you will have to rely on whitelisting. I’ve gotten rid of all my whitelist entries, so I can’t easily check my logs, but IIRC, once properly whitelisted the message won’t even be scored. So I’m guessing your whitelist isn’t working, but check the Rspamd web interface under history. It should be pretty clear in there if it was actually whitelisted or not.

I know when I set up a domain in the whitelist I fat fingered things or added an extra .com about half the time. LOL

tyarmas

Well, I learned a bit about whitelisting. Seems you really need to be very specific.

The SPF and DKIM issues are at the senders end and since I cannot really do anything but send emails telling them they have them screwed up, the only think I can do is use whitelisting properly. Which means using the specific eemail address that is causing the rejection and not use a broad wild card.
I was using things like *.truist.com which did nothing. I needed to use alertnotifications@message.truist.com

Which if I read more closely is stated in the email from Truist.
Bottom line is this is not an issue with mailcow. It is an ID10T error. 😉

diko

Using the header analysis on mxtoolbox.com shows that the mail from alertnotifications@message.truist.com is delivered via mx1.wiredblade.com which has the IP address 72.51.58.35. That then delivers it to your mailcow.

mx1.wiredblade.com sees the mail coming form ip 74.120.68.121 which is a valid sender for the domain message.truist.com according to the spf record of that domain.

But your mailcow then sees the ip 72.51.58.35 of mx1.wiredblade.com - which is not listed in the SPF of message.truist.com. And therefore your system correctly considers this mail as spam.

What is mx1.wireblade.com in your setup?

tyarmas

my mailcow is seeing the proper ip for mx1.wiredblade.com, but mx1.wiredblade.com is not in my setup at all. I presume that it is an intermediary used by the bank.

diko

The MX records for your domains justtasktom.com and yarmas.com point to:
store1.dynu.com
store2.dynu.com

store1.dyno.com resovoles to these IPs:

162.216.242.36
162.216.242.35
162.216.242.37
162.216.242.38

mx1.wiredblade.com also resolves to 162.216.242.35.
So mx1.wiredblade.com is just another name for the same host.

Google tells me wireblade.com is a mail forwarding service: https://www.wiredblade.com/Resources/Tutorials/EmailServices/EmailServiceSetup/EmailForward

Are you using that service on purpose?

If no or if you no longer want to use it, you should simply update the MX records for your domains to point directly to the public IP of your mailcow server. Then it receives incoming mail directly and SPF lookup will work correctly because the ip of the sending host match the senders SPF policy.

tyarmas

I do use Dynu for email store/forward. I did not realize that dynu and wiredblade are the same service.

I also did not realize that using that store/forward caused these issues. I have been using the store/forward service for some time and started when I could not open port 25 where I was hosting. That is no longer the case, so I can stop using that service.

Thanks so much @diko

« Previous Page