Emails forwarded between two mailboxes for the same domain hosted on a Plesk server are marked as spam due to the sender domain's DMARC policy

Symptoms

• Plesk Obsidian is above 18.0.79 and a version of Warden Anti-spam and Virus Protection Version similar to 6.02-1 is installed on the server
• An email from a sender whose domain publishes a strict DMARC policy (p=reject) is delivered successfully to a Plesk mailgroup address (e.g. info@example.com), but the copy re-injected to the mailgroup member's mailbox (e.g. user@example.com) is scored as spam and lands in the Junk folder instead of the inbox.

• The original message passes all checks on the first (external) hop. The entry in /var/log/maillog is similar to the following:

  CONFIG_TEXT: amavis[...]: Passed CLEAN {AcceptedInbound}, ... Tests: [BAYES_00=-1.9,DKIM_SIGNED=0.1,DKIM_VALID=-0.1,DMARC_PASS=-0.1,...], Hits: -0.672
     postfix-local[...]: dk_check: stderr: PASS
     postfix-local[...]: dmarc: stderr: PASS
     postfix/pipe[...]: to=<info@example.com>, relay=plesk_virtual, status=sent (delivered via plesk_virtual service)

  While the second entry, for the internal copy sent to the mailgroup member, shows a DMARC failure and a much higher spam score:

  CONFIG_TEXT: amavis[...]: Passed SPAMMY {AcceptedInternal}, ... helo=localhost, Tests: [...,DMARC_REJECT=0.1,FORGED_SPF_HELO=0.001,HEADER_FROM_DIFFERENT_DOMAINS=0.248,KAM_DMARC_REJECT=7,...], Hits: 6.872
     dmarc[...]: SPF record was not found in Authentication-Results
     dmarc[...]: DMARC: smtpdomain=example.com maildomain=example.com ... align_dkim=fail align_spf=fail ... p=REJECT ... dmarccheck=DMARC_POLICY_REJECT dmarcstatus=STOP
     postfix-local[...]: dmarc: stderr: STOP
     postfix/pipe[...]: to=<user@example.com>, relay=plesk_virtual, status=sent (delivered via plesk_virtual service)

• The message is not bounced or rejected, because Postfix reports status=sent for both hops, but the second copy is filed as spam because of the high SpamAssassin/amavis score.

Cause

The email account info@example.com is configured in Plesk as a mailgroup, with user@example.com as a group member, rather than as a simple alias/forward. When a message arrives for the mailgroup, Plesk re-injects a copy locally (via postfix/pickup, helo=localhost) for delivery to each group member.

This local re-injection is treated as a new incoming message and is re-scanned in full, including a fresh DMARC check:

• The re-injected copy has no real remote sending IP, so SPF cannot be evaluated on this hop (SPF record was not found in Authentication-Results).
• DMARC is re-checked against the original From: header (the sender's domain, e.g. example.com), and since neither SPF nor DKIM aligns with that domain on this internal hop, DMARC alignment fails (align_dkim=fail align_spf=fail).
• Because the sender's domain publishes p=REJECT, this failure triggers the KAM_DMARC_REJECT SpamAssassin rule, which by default adds 7 points to the message's spam score, enough on its own to push most messages over the spam threshold.

Plesk does not rewrite the From: header or apply any ARC-based trust mechanism when re-injecting mail for mailgroup delivery, so any sender whose domain enforces a strict DMARC policy will be affected the same way, not just a single sender.

This behavior is now treated as a Plesk bug with ID #PPPM-15479, which will be fixed in future versions of Plesk and its extensions.

Note: Please click the Follow button near the article headline to stay informed - you will receive an update via email when the bug is fixed

Resolution

• Whitelist the external sender domain on the domain/mailbox which is the forwarding target in Plesk by using the steps in this article:
  How to whitelist a domain in a Plesk server antispam settings?

  Note: If you are using a mail-related Plesk extension, you should do the whitelisting within its interface instead

• Relax the DMARC policy of the original external sender domain to something other than p=reject by editing the DMARC DNS record in its primary DNS zone.
• On the mail server of the external sender domain, align the DKIM signature with the actual sending domain instead of it being something like example.onmicrosoft.com.