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

Текущие практики применения STARTTLS для взаимодействий между серверами следующие:
- если клиент и сервер поддерживают MTA-STS или DANE, то следовать спецификации MTA-STS или DANE (TLS в таком случае обязателен и валидность сертификата проверяется)
- иначе в случае поддержки STARTTLS сервером клиент не проверяет валидность сертификата (сервер может использовать в т.ч. самоподписанный сертификат)
- если произошел сбой в STARTTLS то письмо отправляется в открытом тексте
- статистика использования STARTTLS доступна через TLS-RPT.

Почему используется именно такой подход (не проверяется сертификат сервера):
- в случае пассивного MitM (когда можно только слушать трафик) не важно, какой именно сертификат использует сервер
- в случае акттивного MitM между серверами атакующий может изменить MX записи направив трафик на другой сервер и/или выпустить сертификат для одного из серверов, поэтому проверка сертификата не спасает без дополнительных мер (определяемых MTA-STS и DANE).

Поскольку MTA-STS и DANE вы наверняка не поддерживаете, вам надо в конфигурации вашего сервера
- отключить проверку сертификата
- разрешить фолбек на отправку письма в открытом тексте (не требовать обязательного STARTTLS)
- там где надо гарантировать доставку писем поверх TLS на определенные домены, сконфигурировать MTA-STS, DANE (в зависимости от поддержки доменами) либо отдельные транспорты с жестким прописыванием имени MX сервера для каждого домена назначения и включением TLS и проверки сертификата для транспорта.

Иначе ужесточая требования TLS без дополнительных мер вы только стреляете себе в ногу.

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

вы не можете получать внешнюю почту для разных получателей одного домена на разные серверы, т.к. MX прописывается для домена в целом. Можно
1. Получать все письма для всех получателей на свой onpremise сервер, оттуда часть писем перенаправлять на внешний (и/или наоборот).
2. Сделать отдельный поддомен для другого сервера и использовать его

P.S. отлуп, залуп, вылуп это русские слова, в латинице выглядит странно. В английском это называется bounce.

Ваш SPF разрешает отправку только с mx1.timeweb.ru/mx2.timeweb.ru, а таймвеб для отправки использует другие серверы. Настройте SPF по рекомендациям timeweb
https://timeweb.com/ru/help/pages/viewpage.action?...

Зайди на
https://clienttest.ssllabs.com/ssltest/viewMyClien...
там будет список поддерживаемых Cipher Suites

Для защиты адреса отправителя от подделок используется протокол DMARC. То, возможно ли подделать адрес отправителя, зависит от того, установил ли владелец домена DMARC-политику для своего домена и какая это политика. Если политика reject - письма без авторизации приниматься не будут, quarantine - будут попадать в спам.

Если вы подписываете письма DKIM и 2a06:6440:0:2c13::2 не ваш адрес (это не Digital Ocean, а Hosting Ukraine Ltd.), значит кто-то пытается с этого адреса слать поддельные письма от вашего домена.

На доставку ваших писем именно на GMail это влиять не должно.

Увеличивайте
queue_run_max
и remote_max_parallel (если одно письмо отправляется на большое количество адресов)

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

В Exchange нет проблем с почтовыми доменами.
Из коммерческих решений под Windows можно порекомендовать Communigate Pro.