Доставляемость почты после переезда на свой сервер: PTR, SPF, DKIM, DMARC, репутация IP и чёрные списки

Вам годами внушали, что письма со своего сервера попадают в спам. Это миф, который выгоден облакам. Главный страх перед уходом из облака — «а будут ли доходить наши письма». Доставляемость почты со своего сервера зависит не от размера провайдера, а от аккуратной настройки: PTR, SPF, DKIM, DMARC, чистый IP и разумная отправка. Облако делает это за вас, но и решает за вас; свой сервер требует один раз сделать правильно — и дальше репутация домена принадлежит вам. Разбираем, что проверить после переезда и как держать письма во входящих.

Облако не делает ваши письма надёжнее

Распространённое мнение — «из облака письма доходят лучше». На деле облачный провайдер просто уже настроил всё то, что вы можете настроить сами: подписи, политики, репутацию IP. При этом репутация общая: если с соседних ящиков того же облака пошёл спам, получатели могут ужесточить проверки для всего провайдера, и ваши письма пострадают за чужие ошибки.

Свой сервер с чистым IP и правильными записями отправляет письма не хуже, а репутация домена и IP зависит только от вашей отправки. Нужно один раз всё сделать правильно и следить за несколькими показателями.

Миф о спаме, который держит вас в клетке

«Свой сервер — это письма в спаме» — главный страх, на котором держится облачный рынок. Правда проще: письма в спам отправляет не свой сервер, а плохо настроенный сервер. Облако просто настроило за вас то, что вы можете настроить сами за один день, — и взяло за это вашу свободу.

Хуже того: в облаке ваша репутация общая с миллионами соседей. Чужая спам-рассылка с того же провайдера бьёт и по вашим письмам. На своём сервере репутация домена и IP — только ваша, и зависит только от вашей почты. Ниже — каждая настройка, которая держит ваши письма во входящих.

Шаг 1. PTR и прямая запись

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

dig +short -x 203.0.113.10          # PTR: должно вернуть mail.company.ru.
dig +short mail.company.ru          # A: должно вернуть 203.0.113.10
dig +short TXT company.ru           # SPF: v=spf1 mx -all
dig +short TXT dkim._domainkey.company.ru
dig +short TXT _dmarc.company.ru

Имя в PTR должно совпадать с именем, которым сервер представляется в SMTP-приветствии. Если PTR указывает на техническое имя вида 203-0-113-10.provider.net, письма почти гарантированно получат штрафные баллы в антиспаме получателя.

Шаг 2. SPF

SPF — список серверов, которым разрешено отправлять почту от имени домена. После переезда в нём должен быть ваш сервер. Пока идёт переходный период, в SPF остаётся и старый провайдер; через одну-три недели после переключения его нужно убрать. Завершайте запись -all или ~all, а не ?all: нейтральная политика ничего не защищает.

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

Шаг 3. DKIM

DKIM — цифровая подпись письма ключом домена. Ключ генерирует ваш почтовый сервер, открытая часть публикуется в DNS. Используйте ключ длиной 2048 бит и проверьте, что запись в DNS опубликована целиком: длинные ключи иногда обрезаются в панелях DNS или разбиваются на части с ошибкой. Если подпись не проходит, проверьте сначала имя селектора — это самая частая опечатка.

Шаг 4. DMARC

DMARC говорит получателю, что делать с письмами, которые не прошли SPF и DKIM в связке с доменом из поля «От», и куда присылать отчёты. Начните с p=none и адреса для отчётов: несколько недель отчётов покажут все источники почты от вашего имени, о которых вы забыли. Затем переходите на quarantine, а когда отчёты чистые — на reject.

Крупные почтовые сервисы с 2024 года требуют SPF, DKIM и DMARC от массовых отправителей и всё строже относятся к письмам без них. Даже если вы отправляете немного, DMARC защищает домен от подделки — фишинговых писем «от вашего имени». Подробно — в статье о DMARC и BIMI.

Шаг 5. Проверка заголовков

После настройки отправьте письма на внешние ящики разных сервисов и откройте полные заголовки. Принимающий сервер записывает результаты проверок в строку Authentication-Results. Все три проверки должны быть pass, а домен в DKIM — ваш.

Authentication-Results: mx.example.net;
       spf=pass smtp.mailfrom=company.ru;
       dkim=pass header.d=company.ru;
       dmarc=pass header.from=company.ru

Если одна из проверок не pass, причина почти всегда в DNS: опечатка в записи, старый TTL, не тот селектор DKIM. Если всё pass, а письмо всё равно в спаме — смотрите на содержимое и репутацию IP.

Шаг 6. Чёрные списки

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

# проверка IP 203.0.113.10 в зоне Spamhaus ZEN (октеты в обратном порядке)
dig +short 10.113.0.203.zen.spamhaus.org
# пустой ответ — IP не в списке; ответ 127.0.0.x — IP в списке

Учтите: Spamhaus не отвечает на запросы через крупные публичные DNS-резолверы, поэтому проверку нужно делать со своего резолвера, иначе вы получите ложный результат. Мы подробно описывали эту ловушку в статье о блокировке запросов к Spamhaus через открытые резолверы. Если IP в списке, на сайте списка есть процедура исключения; обычно нужно устранить причину и подать заявку. Регулярную проверку стоит автоматизировать — как это сделать, разобрано в статье о мониторинге домена в чёрных списках.

Шаг 7. Постмастерские сервисы

Крупные почтовые сервисы дают владельцам доменов кабинеты с данными о репутации: сколько писем доставлено, сколько помечено как спам, нет ли проблем с аутентификацией. Это Google Postmaster Tools, Постмастер Mail.ru, Постмастер Яндекса. Подключите домен во всех трёх — это бесплатно и требует только подтверждения владения доменом через DNS.

Данные появляются, когда объём отправки достаточный, поэтому у небольших компаний кабинеты могут быть пустыми. Но если что-то пойдёт не так — массовая рассылка, взломанный ящик, — именно там вы увидите это первым.

Шаг 8. Прогрев нового IP

IP, с которого раньше не отправлялась почта, не имеет репутации. Большие объёмы с такого адреса в первый же день выглядят подозрительно. Для обычной деловой переписки компании это не проблема: объёмы небольшие и растут естественно. Но если вы делаете рассылки клиентам — не запускайте их с нового сервера в первые недели. Начните с обычной переписки, затем увеличивайте объёмы рассылок постепенно.

Лучше вообще не смешивать: деловую почту — со своего сервера, массовые рассылки — через отдельный сервис или отдельный IP и поддомен. Тогда жалобы на рассылку не ударят по репутации основного адреса, с которого бухгалтерия отправляет счета.

Шаг 9. Защита от взлома — защита репутации

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

• лимит писем в час на ящик — подробнее в статье [о лимитах отправки в mailcow](https://itfresh.ru/articles/mailcow-limity-otpravki-pisem.html)
• Fail2ban от перебора паролей
• сложные пароли и двухфакторный вход в веб-почту
• мониторинг очереди: резкий рост — сигнал взлома
• оповещение администратору о попадании IP в чёрный список

Шаг 10. TLS при приёме и отправке

Современные сервисы ожидают, что почтовые серверы шифруют соединения между собой. Убедитесь, что ваш сервер принимает и отправляет почту по STARTTLS с действующим сертификатом на имя сервера и автоматическим продлением. Для дополнительной защиты от перехвата можно опубликовать политику MTA-STS и включить отчёты TLS-RPT: отправители будут требовать шифрование при доставке на ваш домен.

Если письма всё-таки уходят в спам

Порядок разбора: сначала заголовки — все ли проверки pass; потом чёрные списки — не попал ли IP; потом постмастерские кабинеты — нет ли жалоб; потом содержимое — нет ли в письмах ссылок на домены с плохой репутацией, сокращателей ссылок, вложений исполняемых файлов. В девяти случаях из десяти причина находится на первых двух шагах.

Переходный период: два сервера отправляют от одного домена

Первые дни после переключения почта от вашего домена уходит и со старого, и с нового сервера: часть сотрудников ещё не перенастроила телефоны, 1С отправляет по старым параметрам. В это время SPF должен разрешать оба источника, а DKIM-записи обоих провайдеров должны оставаться в DNS. Если удалить старые записи в день переключения, письма от забытых устройств начнут проваливать проверки.

Отчёты DMARC в эти недели особенно полезны: в них видно, с каких IP ещё идёт почта от вашего имени. Когда старый провайдер в отчётах больше не появляется, его можно убрать из SPF и удалить его ключ DKIM.

Как читать отказы в доставке

Если письмо не доставлено, отправитель получает уведомление с кодом ошибки. Код 5xx — постоянный отказ, 4xx — временный, сервер будет повторять попытки. Самое полезное — текст после кода: принимающие серверы обычно прямо пишут причину. «PTR record not found» или «reverse DNS» — проблема с обратной записью. «SPF fail» или «not permitted» — сервер не в SPF. «Blocked» или «listed» со ссылкой на сайт списка — IP в чёрном списке. «Message rejected due to DMARC policy» — письмо не прошло DMARC.

Журнал почтового сервера показывает то же самое со стороны отправки: в журнале Postfix у каждого письма есть строка со статусом и ответом принимающего сервера. Привычка смотреть в журнал при первой жалобе экономит часы гаданий.

Что в самих письмах вредит доставке

Даже при идеальных записях DNS содержимое может отправить письмо в спам. Типичные причины: ссылки через сокращатели ссылок, ссылки на домены с плохой репутацией, вложенные исполняемые файлы и архивы с ними, письма из одной картинки без текста, несовпадение адреса в поле «От» и в поле для ответа. Отдельно — подписи с множеством внешних изображений и трекеров.

Для деловой переписки правило простое: текст, а не картинка; прямые ссылки на свой сайт; документы в PDF, а не в архивах; один адрес отправителя. Для рассылок — отдельный сервис и отдельный поддомен.

Кто следит за доставляемостью после переезда

Доставляемость — не разовая настройка, а показатель, который нужно смотреть. Раз в неделю администратор открывает отчёты DMARC и постмастерские кабинеты, раз в день автоматическая проверка смотрит IP в чёрных списках и присылает оповещение при попадании. Раз в квартал — тестовые письма на ящики крупных сервисов с проверкой заголовков. При смене IP, площадки или добавлении нового сервиса рассылок весь чек-лист проходится заново.

Если в компании нет администратора, это входит в обслуживание сервера, которое мы ведём для клиентов. Общие правила смены записей при переезде — в статье о MX, SPF, DKIM и DMARC при смене провайдера.

Чек-лист доставляемости

Короткая версия для распечатки.

• PTR указывает на имя сервера, имя разрешается в тот же IP
• SMTP-приветствие совпадает с PTR
• SPF включает ваш сервер и все сервисы, отправляющие от имени домена
• DKIM 2048 бит, запись в DNS полная, подпись pass
• DMARC опубликован, отчёты приходят и читаются
• IP чист в основных чёрных списках, проверка со своего резолвера
• домен подключён к постмастерским сервисам
• рассылки отделены от деловой почты
• лимиты отправки и Fail2ban включены
• TLS с действующим сертификатом

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