I have to disagree with Zach. SRS will no do nothing to fix your DMARC problem. SRS rewrites the SMTP MailFrom address to use your domain. That allows the forwarded message to pass SPF based on your domain, but does nothing for DMARC FAIL, because DMARC is based on the message From address, not the SMTP MailFrom address.
Since DMARC checks the message's From header, the domain being verified is the originator's domain. DMARC looks for alignment with a verified MailFrom address or alignment with a verified DKIM signature. Forwarded mail will lose SPF alignment or SPF verification, so the only surviving authentication option is DKIM.
Given that the rejected message failed DKIM verification, it had one of two problems:
1) It never had a valid DKIM signature for the originator domain, or
2) Your environment added or altered content so that the DKIM signature became invalid.
A domain should never publish a "Reject" policy until they are certain that all messages are transmitted with signatures, but not everybody does what they should. Given your other comments, this seems like the most likely case.
But your environment could be causing the problem if
(a) SmarterMail or your spam filter add any text, such as "This message received from an external source"
(b) You have a fancy spam filter that rewrites all links to provide "click-time" protection.
(c) You have SmarterMail configured to add a footer or signature to every outbound message.
(d) The target address is a SmarterMail mailing list address, and you have configured the list to add content to the subject or body to identify it as a list message.
If any of these apply, the solution is to disable any feature that is adding or altering message content.
Note that when Gmail (or anybody else) blocks a message, your server's reputation takes a hit. If you take enough hits, you could have all of your messages to that organization getting blocked. One organization posted in this forum about getting a temporary infection that led to a Gmail block. The block was cleared after 30 days, during which time they lost all communication to the world's largest email system. You could also end up on an RBL, and discover that your messages to lots of organizations are getting blocked.
Given that every email client handles multiple email accounts, there are very few good reasons to do message forwarding, and lots of downside risks. I suggest reviewing whether you want to allow forwarding off of your system at all. Unfortunately, SmarterMail has primitive options: everybody can forward, or nobody can forward.
SmarterMail (and every other mail product) should change the way that auto-forwarding is implemented. Instead of applying a user forward setting automatically, the setting should generate an approval request to the domain admin or system admin. The request should only be approved if the admin gets a message from the forwarding target account to confirm that it wants the forwarding stream. This prevents mistakes and abuse. Then the admin can decide whether the forwarding request is acceptable based on admin policy: lots of organizations are subject to data privacy regulations which are violated as soon as the organization's communications are forwarded to a personal account.