Not sure whether it's modified by amavisd, but Postfix might handle this by default since it has "disable_mime_input_processing = no" and "disable_mime_output_conversion = no" (both are set to "no" by default which means Postfix will do mime processing / conversion), it modifies MIME if it's not RFC-compliant, it's good in your case since you don't have correct "Date:", but it might break DKIM signature too if it happens after signing. Anyway, you already found the solution and it's easy: generate RFC-compliant mime at the very beginning.

No, that actually fixes the symptom, which is failing DKIM signatures.  Fixing the problem would be changing the configuration slightly so that it does the DKIM-signing last and subsequently doesn't wind up changing fields that are protected by the DKIM signature.

I mean, what good is it if the thing DKIM failing was indicating was that the mail was tampered with by an overly-pedantic anti-virus program?

This is just super fun.  I do b'leev I've found a bug in the Amavis configuration.  We've been using iRedMail for a few years now, have SPF and DKIM and all that good stuff working, but are walking away from the previous distribution because reasons.  A brand new box was built with Trixie as the base, DKIM keys were just copied over into Amavis, and everything seemed good.  All the legacy devices  we've got sending mail were sending mail, and then while testing sending authenticated mail from a new internal host that I was spinning up, I started seeing signature failures.  WTF.

Mind you this program worked just fine from the old host and nine or ten others (going through the server running a much older version of iRedMail), and it's literally just a shell script so it's not like I could really have screwed up scp-ing it over, and it just hands the mail to sendmail (which I've been doing for like 20+ years) so... not fancy.  As I started digging into the issue I noticed something in the headers that caught my eye.  The "Date:" header showed -0000 as the timezone which won the stink-eye because the test program just calls $(date) which produces something not quite RFC-compliant ("Wed Apr  8 02:51:27 PM CDT 2026") but it's close enough for testing...or so I thought.  I thought there really should have been a CDT there or something to indicate the time zone wasn't UTC (because I hate converting those in my head).

It turns out that if Amavis doesn't like your date string, it will apparently replace it with a form that is RFC-compliant.  It didn't seem to care at all about my message ID that I forgot to wrap in angle-brackets and just passed that on through but whatevs...

Relevant information: h=message-id:subject:date:from:to;

The kicker is that this configuration apparently "corrects" the date string after it has generated the DKIM signature (which kinda breaks it).  Changing my date generator to using $(date +'%a, %d %b %Y %H:%M:%S %z') made the mails start passing DKIM checks.  That one change.  <<sigh>>

The other "clues" (blatantly fishing for Google with this on behalf of future admins) would be seeing Tests: [ALL_TRUSTED=-1,INVALID_DATE=0.432,INVALID_MSGID=1.167] showing up in the logs.  Again, it won't bother changing the message ID (most MTAs will just generate their own if you didn't specify one) to include <>'s, but it does replace your Date: string.  Heck, until today I didn't even know postfix or Amavis would bother altering the date string.