Настройка почты на собственном домене: от DNS-записей до антиспама

Со стороны кажется, что завести ящик вида name@вашдомен.ru — это пять минут и одна запись в DNS. На деле же вы получаете полноценный почтовый узел, который должен уметь доказывать, что он не спамер, корректно шифровать трафик и не терять письма при сбоях. Если собрать всё правильно, письма будут стабильно доходить до входящих; если проигнорировать детали, сообщения начнут оседать в спаме, а часть получателей вообще перестанут их видеть.

Разберём по шагам, как настроить почту на своём домене с нуля: какие DNS-записи нужны, как работают SPF, DKIM и DMARC, почему PTR — это не опция, а необходимость, как не испортить доставляемость и что проверить перед запуском.

Зачем вообще делать почту на своём домене

Почта вида name@вашдомен.ru нужна не только «для солидности». Это базовый инструмент для:

• корпоративной переписки;
• доменных ящиков для сотрудников;
• сервисных адресов вроде info@, billing@, support@;
• писем от сайта: формы обратной связи, уведомления, восстановление пароля;
• защиты бренда, когда почта и сайт принадлежат одному домену.

Главное преимущество — контроль. Вы сами решаете, где хранить почту, как настраивать антиспам и что делать при миграции. Но вместе с контролем приходит ответственность: почтовая инфраструктура не прощает небрежности. Одна неправильная запись в DNS, и письма начинают уходить в никуда или попадать в спам.

Из чего состоит почта на домене

Если упростить, почта работает по схеме:

• домен указывает, куда доставлять письма;
• сервер принимает входящую почту;
• сервер отправляет исходящую;
• получатели проверяют, не подделано ли письмо;
• антиспам-фильтры решают, показать письмо во входящих или отправить в спам.

Для этого используются несколько технологий:

• MX-записи — говорят, какой сервер принимает почту для домена.
• A/AAAA-записи — указывают IP-адрес почтового сервера.
• SPF — список серверов, которым разрешено отправлять письма от имени домена.
• DKIM — цифровая подпись письма.
• DMARC — политика, что делать с письмами, которые не прошли проверки.
• PTR (reverse DNS) — обратная DNS-запись для IP-адреса сервера.
• TLS/SSL — шифрование соединения при передаче письма.

Без этого набора современная почта живёт плохо, особенно если речь о письмах в Gmail, Outlook, Yandex и Mail.ru. Это не просто список аббревиатур — каждый пункт закрывает свою дыру в доставляемости.

Варианты настройки: свой сервер или почтовый сервис

Перед настройкой полезно понять, какой сценарий вам нужен.

Если задача — быстро и надёжно запустить рабочую почту, сервис обычно выигрывает. Если нужен именно собственный почтовый сервер, придётся внимательно собирать всю инфраструктуру вручную: от MTA до антиспама и мониторинга очередей.

Какие DNS-записи нужны для почты

MX-запись

MX-запись указывает, на какой сервер слать входящую почту. Это основной указатель для внешних почтовых систем: куда складывать письма для вашего домена.

Пример:

example.ru.  IN  MX  10  mail.example.ru.

Здесь:

• example.ru — домен;
• mail.example.ru — сервер, принимающий почту;
• 10 — приоритет, чем меньше число, тем выше приоритет.

Если серверов несколько, можно задать резервные MX-записи. Приоритет работает так: отправители пытаются доставить письмо сначала на самый приоритетный сервер, а если он недоступен — на следующий. Не забывайте, что MX может указывать только на имя хоста, которое имеет A или AAAA запись. Указывать CNAME в MX нельзя — это частая ошибка новичков.

A и AAAA

Для mail.example.ru нужны адреса:

mail.example.ru.  IN  A      203.0.113.10
mail.example.ru.  IN  AAAA   2001:db8::10

A — IPv4, AAAA — IPv6. Если IPv6 не используете, лучше не добавлять его формально «на всякий случай». Некоторые почтовые системы могут пытаться установить соединение по IPv6 и получать таймаут, если сервер его не слушает, что ухудшает доставляемость.

SPF

SPF задаёт, с каких серверов разрешено отправлять письма от домена. Это TXT-запись, которая публикуется в DNS и сообщает принимающей стороне, какие IP-адреса являются легитимными отправителями.

Пример:

example.ru.  IN  TXT  "v=spf1 mx ip4:203.0.113.10 include:_spf.example.net -all"

Расшифровка:

• mx — разрешить серверы из MX-записей;
• ip4:203.0.113.10 — разрешить конкретный IP;
• include: — подключить чужой SPF, если отправку делегируете сервису;
• -all — запретить всё остальное.

Одна из частых ошибок — делать слишком мягкий SPF вроде ~all и считать, что этого достаточно. На практике ~all (softfail) воспринимается фильтрами как сигнал неуверенности в собственной конфигурации. Если вы полностью контролируете отправку, ставьте -all. И не забывайте, что SPF не работает для пересылаемых писем: при пересылке письмо приходит с IP сервера пересылки, который может не попадать в ваш SPF. Для таких случаев нужен DKIM.

DKIM

DKIM добавляет к письму криптографическую подпись. Получатель проверяет её через DNS. Ключ DKIM генерируется на вашем почтовом сервере: приватная часть хранится в конфигурации MTA, а публичная публикуется в TXT-записи.

В DNS появляется TXT-запись вида:

selector._domainkey.example.ru.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."

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

DMARC

DMARC связывает SPF и DKIM и говорит, что делать с неподтверждёнными письмами. Это политика, которая публикуется в DNS и сообщает получателю, как поступать с письмами, не прошедшими SPF или DKIM.

Базовый пример:

_dmarc.example.ru.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]; adkim=s; aspf=s"

Параметры:

• p=none — только мониторинг;
• p=quarantine — подозрительные письма в спам;
• p=reject — отклонять неподтверждённые письма;
• rua= — адрес для отчётов;
• adkim=s, aspf=s — строгая проверка выравнивания доменов.

На старте часто используют p=none, чтобы сначала собрать отчёты и убедиться, что легитимные отправители не ломаются. Но не оставляйте p=none навсегда — это как поставить камеру наблюдения, но не нанять охрану. Собирайте отчёты, проверяйте легитимные потоки, и через пару недель переходите на quarantine или reject. DMARC-отчёты приходят в XML-формате, для их анализа можно использовать специализированные сервисы или простые скрипты.

PTR

PTR-запись делается не в вашем DNS, а у провайдера IP-адреса. Она должна указывать назад на имя сервера. Это так называемый reverse DNS: запрос по IP возвращает имя хоста, которое должно совпадать с тем, что сервер объявляет в EHLO-приветствии SMTP.

Пример:

• IP: 203.0.113.10
• PTR: mail.example.ru

Без PTR многие крупные почтовые системы воспринимают сервер с подозрением. Это один из самых недооценённых факторов доставляемости. На VPS настройка PTR обычно доступна через панель управления провайдера или через тикет в поддержку. Если PTR не совпадает с именем сервера, Gmail и Outlook часто отклоняют письма с кодом 550.

Пошаговая настройка почты на домене

Шаг 1. Подготовьте домен и DNS

Проверьте, что вы управляете DNS-зоной домена и можете быстро вносить изменения. Некоторые регистраторы дают только веб-интерфейс с ограниченным набором записей, что критично для почты. Желательно включить:

• понятную структуру записей;
• отдельный поддомен для почты;
• TTL без крайностей: не слишком высокий, чтобы можно было быстро править записи, и не слишком низкий без необходимости.

Во время настройки рекомендую держать TTL около 300–600 секунд, чтобы изменения применялись быстрее после правок.

Шаг 2. Определите схему отправки и приёма

Ответьте на три вопроса:

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

Если сайт шлёт письма через отдельный сервис, его IP или SPF-include тоже надо учесть в SPF и DMARC. Частая боль: сайтовые уведомления отправляются через PHP mail() без аутентификации, и они попадают в спам, потому что не включены в SPF. Проверьте все сценарии до того, как начнёте настраивать записи.

Шаг 3. Настройте MX и сервер

Добавьте MX-запись на почтовый сервер, проверьте A/AAAA, убедитесь, что порт 25 открыт для входящих соединений, а сервер отвечает корректно. Для собственного сервера обычно нужны:

• Postfix или аналогичный MTA;
• Dovecot или другой IMAP/POP3-сервер;
• SSL-сертификат (можно бесплатный Let’s Encrypt);
• антиспам-фильтр (Rspamd, SpamAssassin и т.п.);
• защита от брутфорса (Fail2ban, ограничение попыток);
• корректная обработка очередей и логов.

Не забывайте, что исходящую почту лучше отправлять через порт 587 (submission), а порт 465 (SMTPS) использовать как fallback. Порт 25 для исходящих часто блокируется провайдерами для конечных серверов, но для приёма он обязателен.

Шаг 4. Включите SPF, DKIM и DMARC

Это не опция, а базовый минимум. Порядок удобнее такой:

1. настроить отправку;
2. сгенерировать DKIM-ключ;
3. добавить SPF;
4. запустить DMARC сначала в режиме мониторинга;
5. проверить отчёты и только потом ужесточать политику.

Не откладывайте DMARC даже в мониторинге: он даёт видимость и позволяет увидеть, какие письма не проходят проверки. Если сразу поставить reject, можно потерять легитимные письма, поэтому сначала соберите статистику.

Шаг 5. Настройте клиентскую почту

Пользователи подключают ящик через:

• IMAP для приёма;
• SMTP для отправки;
• TLS-шифрование;
• правильный логин, чаще всего полный адрес ящика.

Типичные порты:

• IMAPS — 993;
• Submission — 587;
• SMTPS — 465;
• IMAP без шифрования и SMTP без шифрования лучше не использовать вовсе.

Для клиентов можно настроить autoconfig/autodiscover, чтобы не заставлять их вводить параметры вручную. И обязательно отключите POP3 без TLS, если он не нужен — это дыра в безопасности.

Шаг 6. Проверьте доставляемость

Сделайте тестовую отправку на несколько сервисов:

• Gmail;
• Яндекс;
• Mail.ru;
• Outlook.

Смотрите не только факт доставки, но и:

• попало ли письмо во входящие;
• как отработали SPF/DKIM/DMARC;
• нет ли предупреждений о репутации;
• не ломается ли отображение заголовков.

В Gmail и Outlook можно посмотреть оригинал письма и увидеть статусы проверок в заголовках. Также полезно использовать онлайн-тестеры доставляемости, которые анализируют SPF, DKIM, DMARC, PTR и контент.

Что чаще всего ломает доставляемость

Ниже — самые типовые проблемы, которые встречаются в реальных конфигурациях. Большинство из них решаются за полчаса, если знать, куда смотреть.

Антиспам: что нужно сделать обязательно

Антиспам для собственной почты — это не один фильтр, а набор мер. Важно защищать и входящую, и исходящую почту.

Для входящей почты

Полезно включить:

• спам-фильтрацию на сервере (Rspamd, SpamAssassin);
• проверку вложений;
• серые списки или аналоги, если они не мешают рабочей переписке;
• блокировку явных подделок;
• фильтрацию по чёрным спискам, но без слепой зависимости от них.

Серые списки (greylisting) хорошо отсекают тупых спамеров, но могут задерживать письма от новых отправителей на несколько минут. Настраивайте их аккуратно, особенно если у вас много партнёров с автоматическими рассылками.

Для исходящей почты

Нужны:

• корректный SMTP-аутентификатор;
• ограничение отправки с каждого ящика;
• защита от компрометации паролей;
• контроль массовых рассылок;
• отдельный канал для транзакционных писем и маркетинга, если объёмы разные.

Очень частая ошибка — отправлять и служебные письма сайта, и личную переписку, и массовые уведомления через один и тот же ящик без ограничений. Если такой ящик скомпрометируют, пострадают все сценарии сразу. Разделяйте потоки: для сайта используйте отдельные SMTP-credentials или даже отдельный поддомен с отдельным DKIM-селектором.

Как прогревать новый домен и IP

Новый домен без истории редко получает мгновенное доверие. Особенно если с него сразу летят десятки или сотни писем. Почтовые фильтры смотрят на репутацию IP и домена, и резкий всплеск активности с «холодного» адреса почти гарантированно отправляет вас в спам.

Что делать:

• начать с небольших объёмов;
• отправлять письма на реальные, отвечающие ящики;
• использовать понятные темы и нормальную HTML-верстку;
• не вставлять слишком много ссылок;
• избегать резких всплесков активности;
• постепенно увеличивать объём отправки.

Прогрев особенно важен для:

• новых доменов;
• новых IP;
• переезда с одного сервера на другой;
• запуска рассылок после долгого простоя.

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

Безопасность почты: минимум, который нельзя игнорировать

Почта — одна из самых атакуемых сервисных зон. Если закрыть её формально, но оставить слабые пароли и открытый SMTP, проблемы появятся очень быстро.

Обязательный минимум

• сложные уникальные пароли;
• двухфакторная аутентификация там, где она доступна;
• ограничение попыток входа;
• отключение анонимной отправки;
• регулярное обновление почтового ПО;
• резервное копирование ящиков и конфигурации;
• мониторинг логов;
• защита админ-доступа.

Полезные дополнительные меры

• отдельные пароли приложений;
• запрет устаревших протоколов;
• отдельные ящики для системных уведомлений;
• антифишинговые правила для сотрудников;
• проверка вложений и ссылок.

Двухфакторная аутентификация для административных ящиков должна быть обязательной, а не рекомендацией. Мониторинг логов на предмет аномальной активности (несколько неудачных попыток входа с разных IP, резкий рост исходящего трафика) помогает вовремя заметить компрометацию.

Чек-лист перед запуском

• MX-запись указывает на правильный сервер.
• У почтового сервера есть A/AAAA-запись.
• PTR для IP настроен.
• SPF содержит только реальные источники отправки.
• DKIM подписывает письма.
• DMARC добавлен и хотя бы мониторится.
• SMTP работает через TLS.
• IMAP/SMTP-параметры проверены.
• Письма проходят тест на нескольких крупных почтовых сервисах.
• Логи доставки доступны и понятны.
• Есть резервное копирование.
• Настроена защита от брутфорса.

Типовые ошибки при настройке

1. Используют только MX и забывают про SPF/DKIM/DMARC. В 2026 году этого уже недостаточно. Без аутентификации письма либо блокируются, либо падают в спам.
2. Ставят почту на сервер с плохой репутацией IP. Иногда проблема не в конфигурации, а в самом адресе. Проверяйте IP в чёрных списках до установки.
3. Делают один SPF на всё подряд. Потом невозможно понять, кто именно имеет право отправлять письма. Лучше разбить SPF по источникам и держать его компактным.
4. Не проверяют входящие отчёты DMARC. Без отчётов политика вслепую превращается в угадайку. Настройте агрегацию отчётов и просматривайте их хотя бы раз в неделю.
5. Смешивают личную и сервисную почту. Для сайта, биллинга и уведомлений лучше иметь отдельные адреса или даже отдельные потоки отправки. Это упрощает диагностику и изоляцию проблем.
6. Не тестируют доставку после изменений DNS. Ошибка в записи может проявиться не сразу. После каждой правки делайте тестовую отправку и проверяйте заголовки.

Когда лучше не поднимать почту самостоятельно

Свой почтовый сервер оправдан не всегда. Есть ситуации, когда практичнее использовать внешний сервис:

• нет опыта администрирования почты;
• нужен быстрый старт;
• критична доставляемость в Gmail, Outlook и других крупных системах;
• нет времени следить за репутацией IP;
• нет отдельного человека, который будет мониторить логи и очереди.

Если почта — не инфраструктурный проект, а просто рабочий инструмент, сервис часто надёжнее и дешевле по суммарной стоимости владения. Поддерживать собственный MTA, антиспам, обновления и мониторинг — это регулярная работа, а не разовая настройка.

FAQ

Что важнее всего для доставки писем?

Базовый минимум — корректные MX, PTR, SPF, DKIM и DMARC. Без этого письма часто уходят в спам или отклоняются. Также не забывайте про репутацию IP и постепенный разогрев.

Можно ли обойтись без собственного сервера?

Да. Для большинства компаний проще и надёжнее использовать почтовый сервис и подключить свой домен. Вы получаете готовую инфраструктуру с хорошей репутацией, а сами только управляете DNS.

Почему письма попадают в спам, хотя домен новый и всё настроено?

Причин обычно несколько: плохая репутация IP, слабая аутентификация, подозрительный контент, слишком быстрый старт отправки или отсутствие истории домена. Проверьте все факторы по очереди: начните с SPF/DKIM/DMARC, затем посмотрите PTR и репутацию IP.

Нужен ли DMARC, если уже есть SPF и DKIM?

Да. DMARC связывает эти механизмы и задаёт политику обработки неподтверждённых писем. Без него получатели могут игнорировать результаты проверок, и вы не будете получать отчёты о злоупотреблениях.

Что делать, если почта не отправляется с сайта?

Проверить SMTP-логин, порт, TLS, SPF и не блокируется ли исходящая отправка на стороне хостинга или провайдера. Часто проблема в том, что сайт использует порт 25, который закрыт, или IP сайта не включён в SPF.

Как понять, что сервер уже испортил репутацию?

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

Вывод

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

Если сделать всё по уму, доменная почта становится устойчивым рабочим инструментом. Если собрать её «на скорую руку», проблемы с доставкой и спамом почти гарантированы. В почтовой инфраструктуре мелочей нет: здесь важна каждая запись, каждый заголовок и каждый серверный ответ.