Question DMARC validation

[QWeb Ric]

Server operating system version

AlmaLinux 9.8 (Olive Jaguar)

Plesk version and microupdate number

Plesk Obsidian 18.0.77 Update #4

Not sure if this is a bug or a feature misunderstanding, and I haven't tested enough yet, so I'm starting off here but may open a bug report later.

With "Enable DMARC to check incoming mail" enabled in the server-wide mail settings, it looks like spamd is skipped if the DMARC check returns a fail, which makes sense from a resource usage perspective as long as failed DMARC causes the mail to then be rejected/deleted, but as far as I can tell this isn't actually happening. So effectively an SPF softfail which causes DMARC fails for some domains, then proceeds to drop obvious spam into the mailbox because SpamAssassin doesn't bother firing.

It's entirely possible that this only happens with certain DMARC rules. I haven't had chance to do much testing there, but I have a hunch that Postfix is seeing something like an ~all flag in the SPF causing a DMARC fail, deciding that this isn't enough to reject the email, and since spamd didn't kick in to add relevant spam headers it's then otherwise just looking like a reasonably legit email.

For now I've just disabled the DMARC validation and, touchwood, incoming spam appears to have reduced.

 

[Kaspar]

I can't replicate this behavior. On the tests I ran where DMARC fails because of an SPF soft fail, the message gets quarantined as expected (moved to the spam folder), SpamAssassin still runs and examines the message fully.

Just to be sure, you're running spamd natively, without amavis, right?

 

[QWeb Ric]

Admittedly I still haven't had chance to do any further testing, sorry. But yes - we're just running the SpamAssassin that Plesk pulls in, and not Amavis. We do have a bunch of custom SpamAssassin rules but don't change anything fundamental.

I reached out to one of our clients who'd been receiving a large quantity of spam recently, and they've noticed a significant difference since I switched DMARC validation off. What's interesting is that the logs do show "message discarded by a mail handler", but then immediately follow with "delivered via plesk_virtual service". For example if I pull some examples from before I switched DMARC validation off...

May 29 03:35:03 hosting4 postfix-local[3914756]: AD6D661794: dmarc: stderr: STOP
May 29 03:35:03 hosting4 postfix-local[3914756]: message discarded by a mail handler
May 29 03:35:03 hosting4 postfix/pipe[3914755]: AD6D661794: to=<REDACTED>, relay=plesk_virtual, delay=2.5, delays=0.54/0.01/0/2, dsn=2.0.0, status=sent (delivered via plesk_virtual service)
May 29 03:35:03 hosting4 postfix/qmgr[3056114]: AD6D661794: removed
--
May 29 03:35:16 hosting4 postfix-local[3914887]: 52CE56179C: dmarc: stderr: STOP
May 29 03:35:16 hosting4 postfix-local[3914887]: message discarded by a mail handler
May 29 03:35:16 hosting4 postfix/pipe[3914755]: 52CE56179C: to=<REDACTED>, relay=plesk_virtual, delay=1.3, delays=0.49/0/0/0.79, dsn=2.0.0, status=sent (delivered via plesk_virtual service)
May 29 03:35:16 hosting4 postfix/qmgr[3056114]: 52CE56179C: removed
--
May 29 03:35:16 hosting4 postfix-local[3914895]: D5E87617A4: dmarc: stderr: STOP
May 29 03:35:16 hosting4 postfix-local[3914895]: message discarded by a mail handler
May 29 03:35:16 hosting4 postfix/pipe[3914894]: D5E87617A4: to=<REDACTED>, relay=plesk_virtual, delay=0.75, delays=0.48/0.01/0/0.26, dsn=2.0.0, status=sent (delivered via plesk_virtual service)
May 29 03:35:16 hosting4 postfix/qmgr[3056114]: D5E87617A4: removed
--
May 29 03:37:00 hosting4 postfix-local[3915053]: 92D5661846: dmarc: stderr: STOP
May 29 03:37:00 hosting4 postfix-local[3915053]: message discarded by a mail handler
May 29 03:37:00 hosting4 postfix/pipe[3915052]: 92D5661846: to=<REDACTED>, relay=plesk_virtual, delay=1.1, delays=0.49/0.01/0/0.64, dsn=2.0.0, status=sent (delivered via plesk_virtual service)
May 29 03:37:00 hosting4 postfix/qmgr[3056114]: 92D5661846: removed

That said, I've just now checked the mail logs again for Spamd triggered discards, and although we're seeing an improvement, it looks like those "delivered via plesk_virtual service" lines still present, and still with the status=sent results. So I'm rather confused!

Jun 1 22:12:11 hosting4 spamd[1333653]: spamd: identified spam (4.5/4.0) for REDACTED:30 in 0.5 seconds, 14649 bytes.
Jun 1 22:12:11 hosting4 spamd[1333653]: spamd: result: Y 4 - BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE,RCVD_IN_SBL,RCVD_IN_SBL_CSS,SPF_HELO_PASS,SPF_PASS,URIBL_ABUSE_SURBL,URIBL_BLACK,URIBL_CSS_A,URIBL_SBL_A scantime=0.5,size=14649,user=REDACTED,uid=30,required_score=4.0,rhost=::1,raddr=::1,rport=41220,mid=<[email protected]>,bayes=0.000000,autolearn=no autolearn_force=no
Jun 1 22:12:11 hosting4 spam[1456053]: 6F4485F987: SPAM detected_by=spamassassin action=delete
Jun 1 22:12:11 hosting4 postfix-local[1456051]: 6F4485F987: spam: stderr: STOP
Jun 1 22:12:11 hosting4 postfix-local[1456051]: message discarded by a mail handler
Jun 1 22:12:11 hosting4 postfix/pipe[1455738]: 6F4485F987: to=<REDACTED>, relay=plesk_virtual, delay=1.2, delays=0.59/0/0/0.59, dsn=2.0.0, status=sent (delivered via plesk_virtual service)

 

[Kaspar]

I just realized that my earlier test setup was flawed. Running new, proper tests, I can actually confirm spamd isn't invoked when DMARC fails and it's policy is to quarantine. However, as far as I can tell, this should not really matter. Because when the DMARC policy is set to quarantine, messages are delivered to mailbox's spam folder anyway (or at least should be). When DMARC fails, but the policy is set to none, spamd is does get called and the messages is checked by SA.

Do messages where DMARC fails (and the policy is set to quarantine) not end up in the spam folder of the mailbox in your case?

 

[QWeb Ric]

Most, if not all, of our inboxes are set to delete all spam messages with a filter sensitivity of 5. I assume that this only works when SA adds a spam header to the email though, which of course doesn't happen if the SA layer is skipped over.

As far as I'm aware, nothing serer-side ever puts emails directly into the spam folders. I can't speak for our clients, but in my personal inboxes I always see messages that aren't deleted by spamd arrive into the inbox and then be moved by Thunderbird's own spam detection into the spam folder. I periodically work through my own spam folders to collate IPs and content patterns that I can then add to server-side firewalls and SA rules to prevent those messages from slipping through the net again in the future.

Perhaps the 'bug' is that Postfix/Plesk interprets quarantine as just "ignore at this level" but then doesn't invoke spamd so the emails just end up inboxed. It'd make sense for DMARC rejections to just delete the email or bounce it back without invoking SA, and for DMARC passes and quarantines to invoke SA for further testing.

 

[Kaspar]

As far as I'm aware, nothing serer-side ever puts emails directly into the spam folders. [...]

To my knowledge the default behavior on Plesk is for messages on which the DMARC policy is set to quarantine if DMARC fails, to move those to the spam folder of the mailbox . This is what I am seeing on my servers too.

2026-06-02 12:55:07 postfix-local [2056226] 95E16ABDDF: dmarc: stderr: STOP
2026-06-02 12:55:07 dovecot [2056229] service=lda, [email protected], ip=[]. sieve: msgid=<[email protected]>: stored mail into mailbox 'INBOX.Spam'
2026-06-02 12:55:07 dmarc [2056228] 95E16ABDDF: DMARC: smtpdomain=sender.com maildomain=sender.com [email protected] stamp=1780397707 ip=87.106.170.33 adkim=relaxed aspf=strict p=QUARANTINE sp=UNSPECIFIED pct=100 align_dkim=fail align_spf=fail spfres=softfail dkimres=unknown dmarccheck=DMARC_POLICY_QUARANTINE dmarcstatus=DEFER

Perhaps the 'bug' is that Postfix/Plesk interprets quarantine as just "ignore at this level" but then doesn't invoke spamd so the emails just end up inboxed. It'd make sense for DMARC rejections to just delete the email or bounce it back without invoking SA, and for DMARC passes and quarantines to invoke SA for further testing.

Agreed, it would be preferable (and even expected) to still have messages checked by SA if DMARC fails