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

SPF и DKIM сами по себе не проверяют поле From письма в котором содержится адрес отправителя, поэтому письмо может пройти SPF и DKIM но при этом может содержать поддельный адрес. DMARC использует SPF и DKIM и при этом добавляет проверку, что поле From соответствует доменам использованным в SPF и DKIM + политику что делать с теми письмами, в которых From не авторизован. Без DMARC ваш адрес может подделать кто угодно.

Если не хочется самостоятельно разбираться с отчетами, можно использовать сервис типа Agari или Dmarcian, они будут рисовать красивую статистику откуда идут письма от вашего домена и у кого из отправителей они проходят или не проходят авторизацию. Обычно следят чтобы с тех сервисов или почтовых серверов, с которых вы действительно что-то шлете проходил DMARC и по SPF и по DKIM. Все что не ваше можете игнорировать.

После успешного тестирования с none обычно рекомендуют включить политику reject на небольшой процент (например p=reject;pct=10) и посмотреть по логам нет ли реджектов.

У вас во From домен need.com, при этом в SPF (SMTP-конверт) адрес example.com а в DKIM домен need-com.20150623.gappssmtp.com. Чтобы прошел DMARC, SPF или DKIM должны быть от того же домена, который используется во From с точностью до домена организации. Настройте DKIM для своего домена, сейчас у вас есть только дефолтная псевдо-подпись гугла и используйте в SMTP-конверте (MAIL FROM) адрес из того же домена, который используется во From.

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

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

При отправке через mandrillapp у вас в SMTP-конверте mandrillapp.com

<spf><domain>mandrillapp.com</domain><result>pass</result></spf>

Для DMARC не достаточно прохождения SPF, необходимо чтобы домен находился в элайне с доменом из From. В mandrillapp должна быть возможность замапить ваш поддомен на mandrillapp и использовать его для SMTP-конверта. Но в принципе, если в письмах есть ваш DKIM, можно оставить домен конверта как есть, т.к. для DMARC достаточно прохождения DKIM.

>host -tAAAA diso.ru
diso.ru has no AAAA record

PTR резолвится в имя, а имя обратно в тот же IP не резолвится, для IPv6 адресов обычно требуют строгого прохождения FCrDNS.

Но причин может быть много, например плохая репутация у домена.

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

Необходимо сделать две вещи:
1. Прописать в SPF include'ами SPF-политики Mailchimp и Gmail:
https://habrahabr.ru/company/mailru/blog/338700/
2. Завести отдельный DKIM-селектор для Mailchimp, сгенерировать ключевую пару DKIM, публичный ключ опубликовать в DNS с данным селектором, приватный ключ прописать его в Mailchimp для рассылок

Есть несколько вероятных причин, все они связаны с нарушением стандартов при отправке:
1. 1С не формирует какой-то из обязательных заголовков, обычно Date: или Message-ID:. Письмо подписывается DKIM, после чего почтовый сервер добавляет обязательный заголовок для соответствия стандарту и DKIM-подпись бьется.
2. 1C формирует письма с длинной строкой (обычно свыше 998 октетов). Письмо подписывается, после чего почтовый сервер его нормализует для соответствия стандарту и DKIM бьется
3. 1C формирует письма с некодированными 8-битными символами в заголовках или другими нарушениями стандарта, например, неправильным заголовком From:. Поведение DKIM на таких письмах непредсказуемо.

Обычные редиректы не должны менять содержание письма, а значит не должны портить DKIM-сигнатуру и DMARC в такой ситуации не мешает прохождению письма. Бывают ошибки типа https://support.microsoft.com/en-us/kb/2993556 которые Microsoft устраняет, попробуйте установить последние сервис паки и rollup update'ы.

Возможно именно в вашей конфигурации по каким-то причинам письмо перестраивается, например в настройках формата стоит принудительное изменение формата на RTF/HTML. Я не силен в настройках Exchange, но проверьте чтобы этого не происходило. Попробуйте отправить письмо с любого другого адреса на получателей на обеих серверах, сравните diff'ом результат, чтобы понять, почему бьется DKIM.

И имйте ввиду, что если бьется DKIM-сигнатура письма, значит вы не получаете письма не только от mail.ru, но и от yahoo, aol, linkedin, facebook, Вконтакте, paypal и много кого еще, включая письма от самого гугла (@google.com) - т.к. на всех этих доменах тоже строгий DMARC.

1. Настроить SPF
domen.ru. IN TXT "v=spf1 a:smtp1.ru a:smtp.2.ru a:smtp3.ru ~all"
(если у провайдера SMTP-серверов есть готовые SPF-записи лучше включить их через include)
2. выбрать селектор DKIM, например mail1 (можно выбрать разные селекторы для разных SMTP, можно один общий)
3. опубликовать ключ(и) DKIM для выбранного селектора(ов)
mail1._domainkey.domen.ru. IN TXT ...
4. настроить подпись писем парным ключом для домена domen.ru с выбранными селекторами
5. Убедиться, что и в заголовке From: и в SMTP-конверте используется домен domen.ru. Если, например, в конверте будет подставляться обратный адрес типа blablabla@smtp1.ru то SPF будет проходить, но не будет проходить проверка DMARC через SPF, т.к. домен SPF не элайнится с доменом в From:. Отправить тестовое письмо, убедиться, что SPF и DKIM проходят именно для домена domen.ru.
6. Опубликовать DMARC
_dmarc.domen.ru. IN TXT "v=DMARC1;p=none;rua=mailto:dmarc-report@domen.ru;ruf=mailto:dmarc-report@domen.ru;fo=1;"
последить за приходящими репортами.
При необходимости, если все нормально, дальше можно перейти на ограничивающую политику DMARC (p=none заменить на p=reject).