Почта на домене ломается не от сложных вещей, а от двух-трех строк в DNS, которые кто-то вписал “по аналогии”. Самая частая история: в MX-записи стоит IP-адрес вместо имени хоста, а PTR для исходящего сервера никто не завел. Первое дает отказ в доставке еще на этапе SMTP-сессии, второе тихо убивает репутацию отправителя, и письма уходят в спам даже при живых SPF, DKIM и DMARC. Ниже разбор, почему так происходит и как это чинится без шаманства.
MX-запись с IP-адресом: почему регистраторы это пропускают, а почта не работает
Формально RFC требует, чтобы правая часть MX-записи была доменным именем, а не адресом. На практике панели регистраторов и хостеров принимают “192.0.2.10” в поле mail exchanger без единого предупреждения, запись сохраняется, зона валидируется, и создается полное впечатление, что все настроено. Дальше начинается расхождение: часть резолверов отбросит такую запись как некорректную, часть вернет ее как есть, и поведение отправителей разъедется. Одни почтовые системы доставят письмо, другие ответят отказом, и вы будете неделями ловить “плавающие” жалобы.
Корректная схема всегда двухступенчатая. MX-запись указывает на имя почтового хоста, например mail.example.ru, а уже A-запись сопоставляет это имя с IP-адресом сервера. Такое разделение позволяет менять IP при переезде, не трогая MX, и именно на него рассчитывают Postfix, Exim и любой другой MTA на той стороне. Когда MX содержит голый IP, отправитель не может выполнить обратное сопоставление и сверить сертификат TLS с именем хоста, а без этого современные проверки доставки становятся лотереей.
Отдельная путаница возникает с MX-записью, которая направляет всю входящую почту домена на один сервер, при этом в зоне остаются старые записи с приоритетами от прежнего провайдера. Приоритет решает, куда пойдет письмо первым, но если хоть одна запись битая, отправитель может выбрать именно ее. Проверяйте зону целиком, а не только ту строку, которую правили последней.
Отсутствие PTR и последствия для исходящей почты
Забудьте миф, что PTR нужен для приема. Он нужен ровно для одного: чтобы получатель мог проверить, что IP, с которого пришло письмо, действительно принадлежит заявленному домену. Крупные почтовые провайдеры оценивают наличие обратной записи как базовый признак легитимного отправителя, и отсутствие PTR часто превращается в “550 no such user” на стороне получателя или в молчаливую сортировку в спам. Причем SPF, DKIM и DMARC влияют только на исходящую почту и не спасают ситуацию: они подтверждают право домена отправлять письма, но не подтверждают, что IP честный.
Практика: PTR прописывается не у регистратора домена, а у провайдера, который выдал IP. В панели хостинга его обычно нет, и это главная причина, почему про запись забывают. Запросите обратную зону у хостера, дождитесь распространения (от нескольких минут до суток), затем проверьте прямым запросом. Прямая A-запись и обратная PTR должны совпадать: если PTR указывает на mail.example.ru, то A-запись для mail.example.ru должна вести на тот же IP. Несовпадение хуже, чем полное отсутствие PTR, потому что выглядит как подделка.
С PTR есть нюанс, о котором редко пишут: один IP может обслуживать несколько доменов, но обратная запись у него одна. Если на сервере живут пять клиентских доменов, PTR указывает на техническое имя вроде mail.provider.ru, и это нормально, пока HELO-имя в SMTP-сессии совпадает с PTR. Именно HELO, а не домен из заголовка From, сверяют фильтры. Рассинхрон между HELO и PTR дает ту самую картину, когда письма доходят, но репутация домена медленно умирает.
Catch-all: миф о том, что он “ловит все” и решает проблему опечаток
С catch-all связана самая стойкая иллюзия: включил его, и письма на любой нераспознанный адрес домена начнут доходить. Технически так и есть, но цена обычно не обсуждается. Catch-all принимает письма на любой нераспознанный адрес домена, включая те, что никогда не существовали и не должны были существовать. как работает catch-all почта стоит изучить подробнее. Спамеры давно прощупывают домены именно так: отправляют на info@, sales@, test@, admin@ и смотрят, что вернется. Ответ “принято” подтверждает, что домен живой и собирает все подряд, после чего поток мусора растет лавинообразно.
Второй миф: catch-all настраивается в DNS. Нет, catch-all настраивается на почтовом сервере, а не в DNS. В Postfix это virtual_alias_maps с записью вида @example.ru user@example.ru, в Exim аналогичная конструкция через alias-файл, в панели хостинга это галочка “принимать почту на несуществующие адреса”. DNS тут ни при чем, MX-запись только указывает, куда идти SMTP-соединению. Поэтому “я поправил MX, а catch-all не заработал” это не ошибка настройки, а непонимание уровней.
Третий миф, самый дорогой: catch-all помогает при опечатке в адресе. Помогает, но не так, как кажется. Правило catch-all складывает все письма в единственный ящик, и дальше вы вручную разгребаете поток, пытаясь понять, какое из писем адресовано вам, а какое пришло на email, которого не существует. Для бизнеса это прямой путь к пропущенным счетам и потерянным обращениям. Гораздо чище работают фильтры по адресу получателя и явные алиасы на конкретные ящики: тогда нераспознанная локальная часть честно получает 550 no such user, и отправитель сразу понимает, что ошибся.
Что еще ломают при настройке почты, пока чинят MX и PTR
Пока разбираются с MX и PTR, обычно успевают сломать маршрутизацию почты целиком. Классика: меняют MX на новый сервер, но забывают, что старый продолжает принимать почту, и часть писем оседает в ящиках, которые никто не читает. Или наоборот: ставят один MX с приоритетом 10 и не оставляют резервного правила сервера, так что при падении единственного хоста домен перестает принимать почту полностью и отправители получают временный отказ. Резервный MX с более высоким приоритетом это не роскошь, а страховка на случай обслуживания.
Еще один миф: SPF, DKIM и DMARC настраиваются один раз и забываются. Они влияют только на исходящую почту и привязаны к конкретным отправляющим серверам. Переехали на новый IP, добавили рассылку через сторонний сервис, поставили линкбилдинг-плагин на сайт, который шлет уведомления от имени домена, и SPF уже не покрывает новый источник. Письма начинают проваливать проверку, а вы ищете причину в MX. Проверяйте SPF-запись при каждом изменении инфраструктуры, а DMARC держите хотя бы в режиме p=none с отчетностью, чтобы видеть, кто отправляет почту от вашего домена.
Не забывайте и про клиентскую сторону. Пользователь забирает почту одним логином по POP3 или IMAP, и если ящики после переезда переименовали, а настройки в клиенте остались старые, человек будет уверен, что “почта не работает”, хотя сервер принимает письма нормально. То же с Dovecot: после смены схемы хранения или путей к Maildir старые письма “исчезают” из клиента, и это воспринимается как потеря почты. Перед любыми работами с MX и PTR проговорите, какие логины и какие порты остаются прежними.
Практический итог простой. В MX-записи всегда доменное имя, никогда IP, и A-запись для этого имени ведет на нужный сервер. PTR запрашивается у провайдера IP, сверяется с A-записью и с HELO-именем, и без него исходящая почта обречена на фильтры. Catch-all включайте только осознанно и только с фильтрами по адресу получателя, а не как замену нормальным алиасам. И проверяйте зону целиком после каждого изменения: одна забытая строка в DNS стоит дороже, чем час аккуратной сверки.