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

Судя по всему, mandrillapp.com видит только начало записи. Сделайте

"v=spf1 include:_spf.google.com include:servers.mcsv.net include:spf.mandrillapp.com ~all"

Проблема не в настройках IMAP, а в настройках SMTP. Скорей всего, вы забыли включить авторизацию для SMTP.

Есть несколько вариантов:
1. Возможно нет TXT записи, но есть устаревшая записи типа SPF (RFC 7208 отменил использование SPF-записей, в RFC 4408 они были).
2. Некоторые получатели при отсутствии SPF используют т.н. best guess record, как если бы отправитель публиковал "v=spf1 a/24 mx/24 ptr ?all". Использование best guess не вошло в стандарт SPF и сейчас не рекомендуется.

Для резолвинга используется не имя Windows-домена, а домен прописаный в конфигурации DNS в TCP/IP (или отдаваемый DHCP-сервером)
https://s.mail.ru/8nh8/FC5e8inua

Очень нехорошо иметь офисный NAT и почтовый сервер на одном IP. Скорей всего, кто-то в офисной сети подхватил троянца, через который идет активная рассылка спама, поэтому IP блеклистят, причем поскольку он является частью ботнета, то блеклистят как IP конечных пользователей, что скорей всего надолго. Репутация IP скорей всего убита, на ее восстановление у разных почтовых провайдеров может потребовать от недели до бесконечности.

Закройте доступ из локальной сети наружу по 25му порту. Это следовало сделать сразу, чтобы не подставлять почтовый сервер в подобных ситуациях + обязательно установите рейтлимиты по пользователям на самом почтовом сервере, чтобы нельзя было активно спамить через него, обязательно следите за превышениями рейтлимитов / блокируйте скомпрометированных пользователей.
После этого два варианта:
1. Ждать пока репутация восстановится, параллельно вынося себя из известных RBL'ей
2. Попросить у провайдера выделить дополнительный IP адрес или небольшую сеть и назначить отдельный IP почтовому серверу.

Возьмите хостинг в IPv6 сети и используйте прокси или туннель 6-to-4. Например в 3proxy для проброса порта

tcppm -iIP_v6_address port IPv4_backend_address port

в 3proxy

tcppm 80 host1 80
tcppm 8888 host2 8888

Корректно настроенный DNS необходим для AD, т.к. все службы AD, включая контроллеры доменов, ищутся через DNS-запросы.

Надо смотреть содержимое пакетов, иначе плохо понятно что происходит, попробуйте поснифать трафик. DHCP Discover может быть не только для получения IP адреса, некоторые службы, например WPAD, тоже используют DHCP, при этом идет отдельный запрос.
Мне больше кажется странным то, что у вас идет
Apr 15 08:09:55 mail dhcpd: DHCPACK on 192.168.1.187 to 50:46:5d:8c:77:20 (comp1) via rl0
Apr 15 08:10:08 mail dhcpd: DHCPACK to 192.168.1.187 (50:46:5d:8c:77:20) via rl0
два ACK на один DHCPREQUEST. И у вас случайно не поднят шлюз DHCP где-нибудь? Может быть сервер ждет ответа от шлюза, т.к. шлюз всегда отвечает с задержкой, а ответ на адресный запрос при обновлении лиза обычно имеет приоритет над броадкастным.

У вас опубликован DKIM-ключ для селектора mail (mail._domainkey) а письмо подписано с селектором dkim (s=dkim в DKIM-Signature). Насколько я понимаю, письмо формировалось вашим сервером и DKIM-подпись добавлял он, а не яндекс. Соответственно, или поправьте селектор в настройках своего почтового сервера с dkim на mail (подойдет только в том случае, если вы используете тот же ключ, что и Яндекс) или опубликуйте публичный ключ, который он использует в записи dkim._domainkey или используйте отправку через SMTP Яндекса с авторизацией, тогда письма будет подписывать он.