Rspamd 4.2.3 fixes ARC flaws that could weaken DMARC enforcement
News
Rspamd 4.2.3, released October 21, 2026, fixes two ARC trust flaws that allowed unverified authentication results to weaken DMARC enforcement. One involved a failed seal claiming a whitelisted signing domain. The other involved duplicate ARC-Authentication-Results headers at the same ARC instance. Both affected the path that uses trusted forwarder results to adjust DMARC handling.
I would prioritize this update on receiving gateways that trust ARC forwarders and use their results to reduce DMARC penalties. The official release documents the fixes. Administrators should review their effective configuration and test resulting mail actions, because exposure depends on how ARC trust feeds into local DMARC enforcement.
A failed seal could still gain trusted status
The first flaw crossed the boundary between allowing an ARC chain to continue and trusting a particular forwarder's authentication results. Rspamd has a compatibility whitelist for domains with broken ARC implementations. A seal claiming one of those domains could leave the chain valid even when cryptographic verification of that seal failed.
Previously, the trusted-signer check relied on the overall chain result. A failed seal with a whitelisted signing domain in its d= tag could therefore produce ARC_ALLOW_TRUSTED. Rspamd could then select that instance's ARC-Authentication-Results, or AAR, as trusted input for ARC_DMARC_ADJUSTMENT. An attacker-controlled authentication claim could reduce the effect of a DMARC failure without a verified seal establishing who supplied it.
Chain compatibility remains separate from trust
Version 4.2.3 records each seal's verification result and grants trust only to seals that verified successfully. The whitelist still preserves ARC_ALLOW chain behavior. A failed whitelisted seal does not automatically invalidate the entire chain. The security notes explicitly distinguish these outcomes.
Duplicate results created a second trust gap
The second flaw involved two ARC-Authentication-Results headers carrying the same instance number. The extra header was outside the seal's protection but could still be selected as the trusted forwarder's results. That gave an unsealed assertion a route into ARC_DMARC_ADJUSTMENT, with the ability to lower DMARC reject or quarantine handling.
Rspamd 4.2.3 requires exactly one AAR header per ARC instance. This is a per-instance requirement: a legitimate chain with several instances still contains results for those separate instances. The security problem is ambiguity within one instance, where the selected results must be the results authenticated by the chain. Adding another header cannot be allowed to substitute a different assertion.
ARC trust requires authenticated evidence
Forwarding can break SPF because the receiving server sees the forwarder's IP address. Message changes can also break DKIM. ARC carries earlier authentication results through intermediaries so a receiver can consider what a trusted forwarder observed before those changes.
DMARC passes when SPF or DKIM passes with a domain that matches the visible From domain under DMARC's matching rules. ARC-based handling is a receiver's local policy decision about a failure. An ARC adjustment therefore does not establish that the original message passed DMARC at the final receiver.
That decision needs both cryptographic verification and confidence in the forwarder's authentication practices. A recognizable domain written into a header proves neither. Even a valid signature establishes the origin and integrity of an assertion; the receiver must still decide whether that signer is a reliable source of authentication results.
Compatibility decision
A local whitelist lets chain processing tolerate a known implementation problem. ARC_ALLOW describes that chain outcome, including the preserved compatibility behavior.
Trust decision
DMARC adjustment needs authenticated results associated with a trusted forwarder. A seal that failed verification cannot establish that trust through its claimed domain.
I treat ARC-based exceptions as decisions that need evidence in the receiving system's logs. ARC is not permission for arbitrary mail to bypass DMARC, and these fixes protect the evidence used when an exception is considered.
Who should prioritize the review
Mail administrators and providers running Rspamd should identify where inbound ARC results influence DMARC decisions. Forwarding operators should also test their legitimate traffic against the patched validator, particularly when downstream receivers rely on their ARC results.
The relevant configuration deserves closer inspection than a simple check that ARC is enabled. Review the following settings and any local rules that consume the resulting symbols:
- Compatibility whitelist: Inspect whitelist entries that tolerate ARC validation failures.
- Trusted signers: Review whitelisted_signers_map and confirm why each forwarder is trusted.
- DMARC adjustment: Check adjust_dmarc and rules that use ARC_DMARC_ADJUSTMENT.
- Local actions: Trace how ARC_ALLOW_TRUSTED affects scores and final message disposition.
Check the installed version and effective settings
Start with the running deployment, including each receiving node or container. Record its installed version and package build. If a distribution supplies a backported fix, confirm its patch status through that distributor's guidance rather than relying only on the upstream version number.
Inspect the effective configuration, including referenced maps and local overrides. These commands provide a starting point when run in the environment that actually hosts Rspamd; use your deployment's configuration path and administrative permissions where required.
Inspect the local Rspamd installationbash
rspamd --version rspamadm configdump arc rspamadm configdump dmarc rspamadm configtest
Follow the official patch and package guidance to deploy 4.2.3. Validate configuration before restarting or replacing instances, then confirm the version in the running service. A successful configuration check confirms loadability; message tests establish whether the trust decisions changed as intended.
Test authentication symbols and final mail actions
Use staging with the same ARC maps and DMARC rules as production. I would keep a legitimate forwarding sample alongside controlled malformed samples, then compare results before and after patching. Preserve the original message bytes so header changes during test preparation do not accidentally create a different failure.
The minimum test set should cover both reported flaws and ordinary delivery. Record the selected authentication results alongside the emitted symbols, score, and final action for each case.
|
|
|---|---|
Forged whitelisted seal | No trust from failed seal |
Duplicate AAR instance | Ambiguous results refused |
Normal trusted forwarding | Verified results usable |
Direct DMARC failure | Local enforcement preserved |
Staging checks for the ARC trust fixes
For the forged-seal case, confirm that the failed seal cannot supply trusted AAR or earn ARC_ALLOW_TRUSTED on that basis. ARC_ALLOW alone is not evidence that the patch failed, because whitelist compatibility intentionally remains. For duplicate AAR, verify that the extra header cannot become trusted input that lowers DMARC handling.
Check the final mail action as well as the symbols. An unchanged disposition can hide a changed authentication decision when other rules dominate the score. Conversely, a changed score does not establish that the message was rejected or quarantined. Follow the decision through the mail server integration.
For end-to-end tests, preserve the relevant SMTP context, including the connecting IP and envelope sender. A saved message alone does not reproduce the original SPF evaluation. Keep DNS and trust-map inputs consistent between comparisons, and retain enough evidence to distinguish the ARC fix from changes elsewhere in the test environment.
Read the scoring compatibility notes before rollout
The release also changes RBL query merging and scoring. Checks in a rule that resolve to the same query now share a symbol insertion, so weight counts once per matched value. The 4.2.3 changelog explains the compatibility settings, including merge_checks = false for per-check insertions.
It also corrects the inverted dkim_domainonly test under dkim_match_from. Review custom rules that depend on these options before rollout. Keep these compatibility checks in the upgrade plan so a scoring change does not obscure the ARC security results.
Use reporting to check legitimate sender impact
After rollout, compare representative forwarding traffic with the staging baseline. Investigate new failures using receiver logs and retained message headers. Those records are the evidence for which ARC instance was trusted and why a local action was selected.
Our Suped platform's DMARC monitoring helps domain owners review reported authentication failures and sending sources during that follow-up. A DMARC record check confirms the published policy. Neither a DNS check nor aggregate reporting establishes that a receiver has patched this ARC implementation path; that requires deployment verification and message-level testing.
Patch the trust decision, then verify delivery
Prioritize receiving systems that use trusted-forwarder adjustments. Complete the rollout after staging confirms that failed seals and duplicate AAR cannot supply trusted results, while legitimate forwarding still works. Retain the configuration snapshot and test outcomes so administrators investigating a later delivery change can identify which trust decision produced it.
Frequently asked questions
No. The reported paths concern Rspamd's ARC trust and DMARC adjustment behavior. Assess the installed build and effective settings, including trusted signers, the compatibility whitelist, and rules that consume ARC results.
The whitelist still preserves chain compatibility and ARC_ALLOW behavior. The fix prevents a failed seal from establishing trusted-forwarder status or supplying trusted authentication results on that basis.
Yes, when they belong to separate ARC instances. Version 4.2.3 requires exactly one ARC-Authentication-Results header within each instance, preventing an extra header at the same instance from substituting unsealed results.
No. These are receiving-side implementation fixes. Update Rspamd and verify its trust decisions. Changing a sender's DMARC policy does not repair how a receiver selects or authenticates ARC results.
