Владимир Дубровин

Для второго варианта (предпочтительней) добавьте для подомена DNS-запись с публичным ключем (mail._domainkey.subdomain.domain.com. IN TXT) аналогично родительскому домену.
Для первого вариант вам надо поменять правило для подписи, например так.

https://bugzilla.redhat.com/show_bug.cgi?id=1744391
можно поменять /etc/tmpfiles.d/opendkim.conf
но я бы рекомендовал перенести сокет, например в /var/spool/postfix/opendkim

Чтобы подписывался SMTP трафик, необходимо либо письмо отправлять с авторизацией либо прописывать хост, с которого идет отправка в InternalHosts и ExternalIgnoreList. При этом проверьте, что адрес конверта соответствует тому домену, для которого сконфигурирована подпись, т.к. домен обычно выбирается по адресу конверта (envelope-from aka SMTP MAIL FROM aka Return-Path) а не по заголовку From.

Скорей всего, это означает что у вашего домена плохие репутационные оценки (статья старая, но в целом актуальная). Зарегистрируйтесь в postmaster, это позволит посмотреть что именно не так с рассылками, так же вы можете тегировать различные рассылки чтобы смотреть статистику по разным категориям писем и отдельным рассылкам. Подпишитесь на FBL. Посмотрите в DMARC-репорты, нет ли подозрительного трафика с вашего домена, особенно с валидным DKIM, это может указывать на скомпрометированные эккаунты, ключи DKIM или replay-атаки DKIM. Посмотрите не идет ли спам через формы на сайте. Проверьте по логам вашего сервера, возможно в них тоже можно увидеть рассылки со скомпрометированных эккаунтов.

Да, влияет и иногда достаточно сильно, причем даже если домен DKIM-подписи не совпадает с доменом отправителя, но не всегда положительно. В целом, письма с DKIM доставляется значительно лучше, чем письма без DKIM. Но отрицательная репутация домена, который подписывает письма (например плохой рассыльщик с большим потоком спама) может отрицательно влиять на доставляемость подписаных им писем.

Проблема в том, что при текущих настройках пересылка у вас организована так, что меняет содержимое письма, что приводит к нарушению DKIM-подписи. Из-за этого у вас GMail не принимает письма от любых доменов со строгим DMARC, в т.ч. от mail.ru.

Вы можете попробовать организовать перенаправление таким образом, чтобы оно не приводило к изменению письма и не нарушало DKIM. Можно попробовать это сделать за счет настроек коннекторов в Exchange, чтобы пересылка не меняла формат сообщения либо поставить отдельный хост в качестве шлюза между Exchange и внешней сетью, я бы в любом случае рекомендовал это сделать, т.к. в Exchange нет поддержки DKIM/DMARC.

Message-ID и Date должны обязательно должны генерироваться вместе с письмом до того, как вы накладываете DKIM подпись. Иначе Message-ID и Date могут быть добавлены любым промежуточным релеем уже после того, как письмо подписано DKIM, и это приведет к некорректной подписи.

В OpenDKIM значение t= добавляется усли установлен параметр SignatureTTL.
А зачем убирать q= ?

DKIM требует, чтобы письмо соответствовало RFC 5322, RFC 5322 не допускает использования 8-битных символов в заголовках сообщений. Кодируйте имена файлов в заголовках в quoted-printable или base64.

Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="=?UTF-8?B?0KLQtdC60YHRgiDQtNC+0LrQu9Cw0LTQsC5kb2N4?="
Content-Disposition: attachment; filename="=?UTF-8?B?0KLQtdC60YHRgiDQtNC+0LrQu9Cw0LTQsC5kb2N4?="

1. Не надо делать рассылку через SMTP-сервер яндекса с авторизацией, он для этого не предназначен. Рассылайте напрямую со своего сервера.
2. Если вы все-таки делаете рассылку через SMTP-сервер Яндекс с авторизацией (SMTP submission), не подписывыайте письмо DKIM сами, т.к. при наличии авторизации письмо будет подписано submission-сервером. Опубликуйте в своей зоне публичный DKIM яндекса и он будет подписывать письмо вашим ключом. Если зона хостится у Яндекса, дополнительно ничего делать не надо.
3. Можете на данное предупреждение забить, т.к. наличие в письме более одной валидной сигнатуры является совершенно нормальным.

Щас угадаю. Конфиг в UTF-8, в начале файла byte order mark?

Проще всего установить почтовый MTA с проверкой DKIM (exim или postfix + OpenDKIM) и скормить ему это письмо. Но скорей всего там, где вы получили это письмо, DKIM уже был проверен и можно посмотреть на результат этой проверки в заголовке Authentication-Results.