The DMARC failure depends on features in the headers which we cannot see.
DMARC depends on a policy set by the original sender. In this particular instance, I'm guessing they don't want their messages to be forwarded, either because of an oversight in their policy configuration, or because they genuinely want to disallow it (realistically because they regard this as an acceptable price to pay for prohibiting certain types of forgeries).
A simple but perhaps unacceptable way to avoid those is to embed the forwarded message inside a new message; or perhaps try not modifying the message you are forwarding. If the DMARC failure occurs because of an underlying SPF failure, perhaps the simplest fix is to update the From:
header, too (but this rests on multiple guesses about what happened and what you would like to happen instead).
:0 c
* (^TO_|X-Original-To:.*)root@myserver\.com
* <46000000
* ^From:\/.+
{
FROM=$MATCH
:0 hfw
* ^Subject:\/.+
| formail -I "Subject: FORWARDED:$MATCH" \
-I "X-Original-From:$FROM" \
-I "From: You <[email protected]>"
:0 a
! [email protected]
}
This should bypass the DMARC failure because you are no longer making it appear as if you are attempting to send a message "from:" the original domain without their approval.
In some more detail, the DMARC record you quote only specifies how DMARC failures should be handled; but the overall symptomps suggest that the recipient domain does not permit external senders to use their domain name in the From:
header, by way of an SPF record which specifies this policy in more detail. Unfortunately, there is no mechanism in SPF to say "except if you are forwarding a message which is really originally from us"; indeed, its lack of support of forwarding is one of the common criticisms against SPF. But for many purposes, you can easily work around it by replacing the From:
header with one you have control over (and then perhaps putting the original From:
header in X-Original-From:
, like this recipe does.)
Replacing headers will also often wreck any DKIM signature, which is another mechanism which DMARC integrates. If you care about DKIM integrity, your forwarding server will presumably replace the original DKIM wrapper with one of your own, which then again will work around the preferences expressed in the original sender's DMARC and DKIM policies.
Without a copy of the SPF and DKIM records and the actual headers of the message, this is necessarily a high-level overview; but the solution I propose should work around the problem you are asking about.
From
header, notTo
. The DMARC record of your domain only matters if you rewrite theFrom
header.