Коротко — MX‑запись отвечает только за входящую доставку писем на ваш домен и на исходящую доставку напрямую не влияет. Предложение техподдержки «поставьте MX на SMTP‑Relay» имеет смысл только если они хотят, чтобы входящая почта шла через этот сервис (и/или если сам relay требует такой записи для верификации домена). Но оно не решит проблему, когда ваш сервер при попытке соединиться с удалённым SMTP «видит» Exim хостинга и падает по ошибке сертификата — это явный симптом того, что соединение перехватывается/редиректится на стороне хостера.
Дальше — что проверить и какие шаги предпринять для диагностики и устранения (порядок действий и команды, которые выполнить на хостинге/сервере):
1) Подтвердите, куда реально идёт TCP‑соединение
- dig/host: проверить разрешение имени
- dig +short smtp.relay.example
- traceroute/tcptraceroute к порту 587 или 2525
- traceroute -T -p 587 smtp.relay.example
- telnet/nc/openssl: попытка соединения и посмотреть баннер/сертификат
- telnet smtp.relay.example 587
- openssl s_client -starttls smtp -crlf -connect smtp.relay.example:587 -servername smtp.relay.example
Если вы видите в ответ баннер Exim (или сертификат с именем, принадлежащим хостингу), то соединение не доходит до внешнего реле.
2) Посмотреть, какой IP используется и совпадает ли он с ожидаемым
- сравните IP из dig с документированной IP у провайдера реле.
- попробуйте подключиться напрямую по IP:
- openssl s_client -starttls smtp -connect X.X.X.X:587
Если по IP — то же поведение, значит это не DNS‑подмена, а сетевой редирект на уровне хостинга/провайдера.
3) Проверить локальные/хостинговые перенаправления (если у вас есть доступ)
- iptables/nftables NAT‑правила:
- sudo iptables -t nat -L -n -v
- sudo nft list ruleset
- Просмотреть процессы/слушающие порты:
- ss -tnlp | grep :587
Если есть правило DNAT/REDIRECT портов на локальный Exim — причина найдена.
4) Посмотреть логи Exim у хостинга (времена соответствуют попыткам вашего скрипта)
- /var/log/exim_mainlog или аналог — там будет видно, кто подключился и почему выдан местный сертификат.
Попросите техподдержку прислать фрагменты логов подключения/RELAY.
5) Захватить трафик (tcpdump) для точного анализа
- sudo tcpdump -n -s0 -w smtp.pcap host smtp.relay.example and \(port 587 or port 2525 or port 465\)
Анализ pcap покажет: куда идут SYN, какие адреса и какая TLS‑сертификатная цепочка приходит.
6) Проверить настройки клиента/скрипта
- правильный hostname в конфиге, порт, тип шифрования (STARTTLS на 587, SMTPS на 465), включена ли проверка сертификата, передаёте ли SNI (openssl -servername).
- временно для диагностики попробуйте отключить валидацию сертификата (не для продакшна) — чтобы понять, TLS‑проблема ли или соединение вообще не туда идёт.
7) Понять политику хостинга
- часто хостеры блокируют исходящий SMTP (25/465/587/2525) и перенаправляют на свой Exim/Relay для борьбы со спамом. Нужно спросить: «Перехватываете ли вы исходящие SMTP‑соединения и делаете ли transparent proxy/DNAT на local Exim?»
- если да, попросите разрешения на исходящие соединения к IP/портам вашего SMTP‑провайдера или настройку исключения.
8) Варианты решений
- Попросить хостинг разрешить прямые TCP‑соединения с IP/портом вашего реле.
- Если они требуют использования их Exim — получить у них настройки relay (smtp, порт, логин/пароль) и настроить ваш скрипт на их relay.
- Использовать другой порт, который хостинг гарантированно пропускает (например 465/587/2525, но многие хостеры блокируют все) — но если хостинг делает прозрачный прокси, смена порта не поможет.
- Использовать API (HTTP/HTTPS) почтового сервиса (Mailgun, SendGrid и т.п.) вместо SMTP — HTTPS как правило не блокируется.
- Настроить SMTPS (порт 465) или включить/выключить STARTTLS в зависимости от требований реле.
9) О сертификате
- Сертификатная ошибка возникает, потому что вместо сертификата remote relay клиенту приходит сертификат Exim хостинга (CN/SAN не совпадает с именем реле). Это прямой признак того, что TLS‑рукопожатие обслужил не тот сервер. Возможно также, что SNI не был передан, и Exim ответил своим сертификатом, но чаще — это именно перехват соединения.
10) О MX‑записи: что она даёт и чего не даёт
- MX указывает, куда доставлять входящую почту для домена. Не управляет тем, как и куда ваш скрипт делает исходящие SMTP‑соединения.
- Некоторые SMTP‑провайдеры в процессе валидации домена требуют установки TXT (SPF), DKIM, иногда MX, но это часть верификации/доставляемости, а не технический метод маршрутизации исходящей отправки из вашего сервера.
- Если техподдержка предлагает поставить MX туда, возможно они предлагают перенаправлять входящую почту на этот сервис или хотят, чтобы вы использовали тот же сервис в качестве relay. Но сам факт изменения MX не снявт перехват исходящих соединений со стороны хостера.
Резюме и рекомендации
- Технических оснований считать, что простая смена MX решит проблему с тем, что Exim «вставляет себя» в исходящее соединение — нет.
- Скорее всего хостер перехватывает/редиректит исходящие SMTP (или DNS/маршрутизацию), поэтому вы видите Exim и сертификат хостинга. Нужно либо добиться у хостинга разрешения на прямой выход к IP/порт вашего SMTP‑реле, либо использовать их релей/их учетные данные, либо перейти на API отправки.
- Для диагностики попросите у хостинга логи подключения Exim и/или выполните команды выше (openssl s_client, dig, traceroute, tcpdump) и пришлите вывод — по ним можно точно сказать, где теряется соединение.
Если хотите, пришлите:
- строку лога с ошибкой сертификата (вырезанную),
- hostname и порт вашего реле (можно анонимизировать),
- вывод: dig +short, openssl s_client -starttls smtp -connect host:587 (или pcap) — и я помогу проанализировать дальше.