Письма перестали доходить после переезда: восстанавливаем цепочку

MAATRIX

Перевезли почту на новый сервер — и через день-два начинаются жалобы: письма клиентам падают в спам, часть вообще не доходит, в логах Postfix bounce с формулировками про репутацию или подпись. При этом конфиг вы скопировали один в один со старого сервера, ничего в настройках Postfix или Exim не меняли. Проблема в том, что почтовая аутентификация в интернете привязана не к тому, как настроен ваш сервер, а к тому, с какого IP-адреса он отправляет письма — и после переезда эта привязка ломается сама по себе, даже если вы ничего не трогали внутри.

«Всё настроено так же, как было» — и это не помогает

Первая реакция почти всегда одна: перепроверить конфиг почтового сервера построчно, сравнить со старым, найти опечатку. Час-два уходит на это, конфиг оказывается идентичным — а письма всё равно не доходят. Это нормальная, но неверная точка приложения усилий: сам сервер тут почти всегда ни при чём.

Дело в том, что Postfix, Exim или любой другой MTA просто передаёт письмо дальше по протоколу SMTP. Решение «доверять или нет» принимает не ваш сервер, а сервер получателя — Gmail, Yandex, Mail.ru, корпоративный Exchange. И решение это строится на трёх независимых механизмах, которые смотрят не на конфиг вашего сервера, а на DNS-записи домена и на историю IP-адреса:

• SPF — список IP-адресов, которым домен разрешает отправлять от своего имени;
• DKIM — криптографическая подпись письма приватным ключом, публичная часть которого лежит в DNS;
• DMARC — политика, что делать, если SPF или DKIM не сошлись.

Все три опираются на DNS-записи, которые указывают на конкретную инфраструктуру. Когда вы переезжаете на новый IP, эти записи автоматически не обновляются — их держит человек, а не переезд сервера. Плюс к этому добавляется вторая, отдельная проблема: у нового IP-адреса просто нет истории. Формально всё может быть подписано правильно, но получатель видит: письма с этого адреса раньше никогда не приходили — и включает повышенную подозрительность. Это две разные причины одного симптома, и лечатся они по-разному.

Причина 1: SPF-запись всё ещё ссылается на старый сервер

SPF-запись — это TXT-запись в DNS домена вида:

example.com.  TXT  "v=spf1 ip4:203.0.113.10 include:_spf.google.com -all"

Здесь 203.0.113.10 — старый IP почтового сервера. Если вы переехали на 198.51.100.20, а запись не тронута, получатель видит: письмо пришло не с адреса, разрешённого доменом. Результат проверки — SPF fail (или softfail, если в конце стоит ~all вместо -all). Дальше всё зависит от DMARC-политики получателя: письмо может улететь в спам, а может быть отклонено сразу на этапе SMTP-диалога.

Частая деталь, которая усложняет картину: если для отправки используются внешние сервисы (Google Workspace, Mailgun, Amazon SES, сервис рассылок), SPF-запись обычно составная — несколько include: вдобавок к ip4: для собственного сервера. При переезде меняется только один сегмент — IP вашего сервера, — а остальные include трогать не нужно. Ошибка, которая встречается на практике: администратор переписывает всю запись с нуля и случайно теряет include:_spf.google.com или аналогичный, из-за чего перестаёт проходить SPF не только новая инфраструктура, но и старые интеграции, которые работали нормально.

Причина 2: у нового IP нет репутации

Это отдельная и более коварная проблема, потому что она не лечится правкой DNS. Почтовые системы получателей (особенно крупные — Gmail, Microsoft, Yandex) годами накапливают репутацию каждого IP-адреса: сколько писем с него приходило, какая доля попадала в спам, сколько жалоб на спам приходило от получателей, насколько стабилен объём отправки. У нового IP-адреса, который вы только что получили от провайдера, этой истории попросту нет — он «холодный».

Холодный IP по умолчанию не считается плохим, но и не считается заведомо хорошим — он под наблюдением. Если с такого адреса резко пойдёт объём, сопоставимый с тем, что раньше отправлялся со старого сервера, спам-фильтры воспримут это как подозрительный паттерн: новый неизвестный отправитель сразу шлёт много писем — типичное поведение спам-рассылки или скомпрометированного сервера. Даже при идеально настроенных SPF/DKIM/DMARC часть писем в первые дни и недели может уходить в спам просто из-за отсутствия истории.

Хуже, если старый IP-адрес до вас уже использовался кем-то другим и имеет подпорченную репутацию (провайдеры переиспользуют пулы адресов) — тогда письма могут блокироваться сразу, до всякого прогрева. Это стоит проверить отдельно — вписав IP в чёрные списки для восстановления репутации: та же диагностика (DNSBL-проверки) актуальна и для нового адреса перед тем, как начинать с него отправку.

Диагностика: читаем заголовки отклонённого письма

Прежде чем что-то чинить, нужно понять, что именно не сошлось — SPF, DKIM, DMARC или репутация IP по отдельности. Самый точный источник — заголовки самого отклонённого или ушедшего в спам письма.

Откройте письмо (в Gmail — «Показать оригинал», в других клиентах — «Просмотр исходного кода») и найдите блок Authentication-Results. Он выглядит примерно так:

Authentication-Results: mx.google.com;
       dkim=fail (bad rsa signature) header.i=@example.com;
       spf=fail (google.com: domain of no-reply@example.com does not designate 198.51.100.20 as permitted sender) smtp.mailfrom=example.com;
       dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=none) header.from=example.com

Тут прямым текстом сказано: SPF провалился, потому что 198.51.100.20 (новый IP) не значится разрешённым отправителем — то есть SPF-запись не обновлена. DKIM тоже fail — значит, подпись либо отсутствует, либо ключ на новом сервере не совпадает с тем, что опубликован в DNS.

Отдельно ищите строку Received-SPF — некоторые почтовые системы дублируют результат там же:

Received-SPF: fail (google.com: domain of no-reply@example.com does not designate 198.51.100.20 as permitted sender) client-ip=198.51.100.20;

Если письмо не отклонено, а просто попало в спам, заголовки те же — просто DMARC-политика получателя мягче (quarantine, а не reject). Если под рукой нет живого «отклонённого» письма, отправьте тестовое на сервис вроде mail-tester.com или mxtoolbox.com — они прогоняют письмо через ту же проверку и показывают результат по SPF/DKIM/DMARC в понятном виде, без необходимости лезть в сырые заголовки.

Проверяем актуальность SPF, DKIM и DMARC в DNS

Дальше — проверка самих DNS-записей, а не письма. Три команды dig, которые покрывают всё:

# SPF: смотрим, какие IP реально разрешены
dig +short TXT example.com | grep spf1

# DKIM: смотрим публичный ключ по селектору
# селектор обычно виден в заголовке DKIM-Signature письма: d=example.com; s=mail
dig +short TXT mail._domainkey.example.com

# DMARC: смотрим политику
dig +short TXT _dmarc.example.com

Если первая команда возвращает старый IP вместо нового — вот и причина SPF fail. Если вторая команда возвращает пусто или ключ не совпадает с тем, что реально стоит на новом сервере (например, ключ вообще не генерировался заново после переезда) — вот причина DKIM fail. DMARC обычно переезд не трогает — эта запись описывает политику, а не инфраструктуру, — но проверить стоит на всякий случай: если политика p=reject, письма с проваленным SPF/DKIM будут отбрасываться жёстко, без вариантов, и это усиливает срочность фикса.

Для наглядной проверки удобны веб-инструменты (MXToolbox SPF/DKIM/DMARC Lookup, dmarcian, Google Admin Toolbox Check MX) — они показывают не просто содержимое записи, но и явно подсвечивают синтаксические ошибки вроде двух SPF-записей на одном домене (что само по себе делает SPF невалидным независимо от содержимого) или превышения лимита в 10 DNS-lookup при развёрнутой SPF-записи с множеством include.

Фикс: обновляем записи и добавляем PTR

Когда причина локализована, правки обычно укладываются в три шага.

1. Обновить SPF. Меняем IP старого сервера на новый (или добавляем новый, если старый ещё продолжает где-то отправлять почту в переходный период):

example.com.  TXT  "v=spf1 ip4:198.51.100.20 include:_spf.google.com -all"

Если переезд временный и оба сервера какое-то время работают параллельно — впишите оба IP через пробел, уберите старый только когда убедитесь, что он больше ничего не отправляет.

2. Настроить DKIM заново. DKIM-ключ физически лежит на сервере — при переезде на новую машину его нужно сгенерировать заново (в OpenDKIM, rspamd или встроенном DKIM-модуле панели), а публичную часть опубликовать в DNS под тем же или новым селектором:

mail._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."

Если используете тот же селектор (mail), убедитесь, что старая запись полностью заменена новым ключом, а не осталась висеть параллельно — иначе получатели, закэшировавшие старую запись по TTL, будут проверять подпись против неверного ключа ещё некоторое время.

3. Добавить PTR-запись для нового IP. Это отдельная и часто забываемая деталь: обратная DNS-запись (rDNS) должна указывать с IP на доменное имя почтового сервера, и желательно, чтобы прямая запись (A) для этого имени указывала обратно на тот же IP (forward-confirmed reverse DNS, FCrDNS) — многие фильтры проверяют именно это совпадение. PTR-запись не прописывается в зоне вашего домена — её обычно выставляет провайдер сервера через панель управления или по заявке в поддержку, потому что обратная зона принадлежит владельцу IP-блока, а не вам:

# проверка текущего PTR
dig -x 198.51.100.20 +short
# должно вернуться что-то вроде mail.example.com.

Отсутствие PTR или PTR, указывающий на generic-имя вроде 20.100.51.198.hostname-provider.net, — одна из самых частых причин, по которым письма с технически правильными SPF/DKIM всё равно тормозятся жёсткими корпоративными фильтрами.

Прогрев IP: почему правильных записей всё равно недостаточно

Даже после того как SPF проходит, DKIM проходит и PTR на месте, часть писем в первые дни всё равно может оседать в спаме — это ожидаемо, а не признак того, что вы что-то упустили в записях. Причина — холодная репутация IP, а её никакая DNS-запись не лечит, только время и аккуратный объём.

Практический подход к прогреву — постепенно наращивать объём отправки, а не переключать весь трафик со старого сервера на новый в один момент:

• Начните с малого объёма и «тёплой» аудитории — тех получателей, кто реально открывает и читает ваши письма (активные подписчики, недавние клиенты), а не с полной базы разом.
• Наращивайте объём постепенно в течение нескольких недель, ориентируясь на реакцию — открытия, ответы, отсутствие жалоб на спам, — а не на календарь. Точных цифр «сколько писем в день на N-й день» универсально не существует: у разных почтовых систем и разных типов рассылок пороги отличаются, это стоит воспринимать как общий принцип, а не таблицу с готовыми числами.
• Следите за метриками через Postmaster-инструменты получателей — Google Postmaster Tools и аналоги показывают репутацию IP/домена с точки зрения конкретного провайдера и жалобы на спам напрямую, это куда честнее, чем догадки по логам Postfix.
• Не смешивайте транзакционные письма с массовыми рассылками на одном IP в период прогрева — сбой в поведении рассылки не должен убивать доставляемость критичных писем вроде сброса пароля.
• Держите старый сервер в SPF (или полностью выключенным) до конца переходного периода — гибрид, где часть писем идёт со старого IP с уже наработанной репутацией, а часть с нового, снижает риск резкого провала доставляемости во время прогрева.

Если вы заранее знаете, что предстоит переезд почтовой инфраструктуры, для теста конфигурации перед прогревом удобно поднять параллельный сервер, а миграцию DNS — включая связку SPF/PTR — синхронизировать с уже описанным процессом смены A-записей, см. проблемы с DNS после переезда: большая часть задержек там та же самая — TTL и кэш DNS у резолверов получателей, только применительно не к веб-трафику, а к почте.

Частые вопросы