Почта на своём домене: что такое MX, SPF, DKIM и DMARC и как их настроить

Вы зарегистрировали домен, подключили хостинг, запустили сайт. Следующий логичный шаг — завести почту на своём домене: info@вашакомпания.ru, hello@вашакомпания.ru, директор@вашакомпания.ru. Всё выглядит профессионально. Но есть проблема, о которой многие узнают постфактум: письма уходят в спам, не доходят до получателя или вовсе отклоняются почтовыми серверами.

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

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

Все четыре записи прописываются в DNS-зоне домена — там же, где A-запись и NS-серверы. Технически это несложно: большинство операций сводится к добавлению TXT-записи в панели управления хостингом или у регистратора домена. Сложнее — понять, что именно прописывать и почему. Именно этому посвящена данная статья.

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

Раздел 1. Зачем нужны DNS-записи для почты

DNS (Domain Name System) — это не только система перевода доменных имён в IP-адреса для браузеров. Это также база данных, в которой хранится критически важная информация для работы электронной почты. Когда почтовый сервер получает письмо, он обращается к DNS домена отправителя и проверяет несколько вещей: существует ли этот домен, кому разрешено от него отправлять, подлинно ли письмо.

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

Именно для борьбы с этой угрозой и были разработаны стандарты SPF, DKIM и DMARC. Вместе с MX-записью они образуют полноценную систему идентификации почты на домене.

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

Важно понимать: с 2024 года Google и Яндекс ужесточили требования к отправителям. Для массовых рассылок наличие SPF, DKIM и DMARC стало обязательным условием доставки в inbox. Без этих записей письма с вашего домена будут систематически попадать в спам или отклоняться на уровне сервера — вне зависимости от качества самого письма.

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

Раздел 2. Что такое MX-запись и как она работает

MX-запись (Mail Exchange) — это DNS-запись, которая указывает, на какой почтовый сервер нужно доставлять входящие письма для данного домена. Без MX-записи любое письмо, отправленное на адрес @вашдомен.ru, будет отклонено: отправляющий сервер просто не знает, куда его доставлять.

Принцип работы прост. Когда кто‑то отправляет письмо на info@example.ru, сервер отправителя делает DNS-запрос: «Какой MX-сервер обслуживает домен example.ru?» DNS возвращает адрес почтового сервера — например, mail.example.ru или mx.yandex.ru (если используется Яндекс 360). Далее сервер отправителя устанавливает SMTP-соединение именно с этим сервером и доставляет письмо.

MX-запись имеет следующий формат:

Тип: MX Имя: @ (или ваш домен) Значение: 10 mail.example.ru TTL: 3600

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

Пример нескольких MX-записей:

10 mx1.почтовый-сервис.ru (основной, первый приоритет)
20 mx2.почтовый-сервис.ru (резервный)

Когда вы подключаете корпоративную почту через внешний сервис — Яндекс 360, Google Workspace, Mail.ru для бизнеса — провайдер даёт вам готовые значения MX-записей, которые нужно прописать в DNS домена. После этого вся входящая почта начинает поступать на серверы выбранного провайдера.

Важный момент: MX-запись указывает только на имя хоста, не на IP-адрес. У этого хоста должна быть A-запись (или AAAA для IPv6), которая разрешается в конкретный IP. Если A-запись отсутствует или указывает на неправильный адрес — почта всё равно не будет доставляться.

Проверить MX-запись домена можно через сервис MxToolbox.com: вводите домен, выбираете тип проверки MX — и видите текущие настройки. Это первое, что нужно проверить при отладке проблем с входящей почтой.

Раздел 3. Что такое SPF и зачем он нужен

SPF (Sender Policy Framework) — это DNS TXT-запись, которая содержит список серверов, имеющих право отправлять электронную почту от имени вашего домена. Когда принимающий почтовый сервер получает письмо якобы от вашего домена, он проверяет SPF-запись: входит ли IP-адрес отправляющего сервера в разрешённый список? Если да — письмо проходит SPF-проверку. Если нет — это сигнал о возможной подделке.

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

Стандартная SPF-запись выглядит так:

v=spf1 a mx include:_spf.yandex.ru ~all

Разберём каждый элемент:

v=spf1 — обязательный идентификатор версии SPF. Всегда именно так.

a — разрешает отправку с IP-адреса, указанного в A-записи домена. Используется, если почта отправляется с того же сервера, где хостится сайт.

mx — разрешает отправку с серверов, указанных в MX-записях домена. Логично: если MX-сервер принимает почту, он же может её и отправлять.

include:_spf.yandex.ru — подключает SPF-запись Яндекса. Если вы отправляете почту через Яндекс 360, нужно включить их серверы в свой SPF. Для Google Workspace это будет include:_spf.google.com, для других провайдеров — свои значения.

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

Критическое ограничение SPF, о котором часто забывают: максимум 10 DNS-запросов при обработке записи. Каждый include, a, mx — это один DNS-запрос. Если цепочка include вложенная (include ссылается на другой include), запросы суммируются. При превышении лимита SPF-проверка завершается ошибкой PermError, и письмо может быть расценено как не прошедшее SPF — даже если сервер легитимный. Решение: использовать ip4: и ip6: с прямым указанием адресов вместо include там, где это возможно.

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

v=spf1 include:_spf.yandex.ru include:_spf.google.com ip4:93.184.216.34 ~all

Раздел 4. Что такое DKIM и как устроена цифровая подпись

DKIM (DomainKeys Identified Mail) — это механизм цифровой подписи электронных писем. Каждое исходящее письмо подписывается криптографическим ключом; принимающий сервер проверяет подпись по публичному ключу, опубликованному в DNS домена. Если подпись совпадает — письмо действительно отправлено тем, кем представляется, и не было изменено в процессе передачи.

В отличие от SPF, который проверяет IP-адрес отправляющего сервера, DKIM проверяет само содержимое письма. Даже если злоумышленник отправит письмо с «правильного» IP — без приватного ключа он не сможет создать корректную DKIM-подпись.

Как работает DKIM на практике:

Почтовый сервер при отправке письма создаёт цифровую подпись на основе содержимого письма (заголовков и тела) с использованием приватного ключа. Эта подпись добавляется в заголовок письма в поле DKIM-Signature. Принимающий сервер читает заголовок, извлекает из него selector (идентификатор ключа) и домен, делает DNS-запрос вида selector._domainkey.example.ru, получает публичный ключ и проверяет подпись.

В DNS DKIM-запись выглядит как TXT-запись вида:

Имя: mail._domainkey.example.ru Тип: TXT Значение: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA...

Здесь mail — это selector, произвольный идентификатор, который позволяет иметь несколько DKIM-ключей для одного домена (например, если почта отправляется через несколько разных сервисов). p= — это публичный ключ в формате Base64.

Приватный ключ хранится на почтовом сервере и никуда не публикуется. Публичный ключ публикуется в DNS — именно он позволяет принимающим серверам проверить подпись.

Длина ключа имеет значение: минимально допустимая — 1024 бита, рекомендуемая с 2024 года — 2048 бит. Google и Microsoft снижают доверие к письмам с 1024-битными ключами. При настройке DKIM через внешний почтовый сервис (Яндекс 360, Google Workspace) ключи генерируются автоматически — вам просто даётся готовая TXT-запись для добавления в DNS. При настройке на собственном почтовом сервере ключи нужно генерировать самостоятельно с помощью OpenDKIM или аналогичных инструментов.

После добавления DKIM-записи в DNS нужно подождать, пока изменения распространятся по сети (обычно от 15 минут до нескольких часов), и затем проверить корректность настройки через MxToolbox или DKIM Core.

Раздел 5. Что такое DMARC и как он объединяет всё вместе

DMARC (Domain-based Message Authentication, Reporting and Conformance) — это DNS TXT-запись, которая устанавливает политику обработки писем, не прошедших проверку SPF и/или DKIM, и позволяет получать отчёты о работе почтовой аутентификации домена.

DMARC — финальный уровень защиты. SPF проверяет, с какого сервера отправлено письмо. DKIM проверяет подлинность подписи. Но даже если оба механизма работают, остаётся вопрос: что делать, если письмо их не прошло? Именно DMARC даёт на него ответ.

DMARC-запись добавляется в DNS как TXT-запись с именем _dmarc.вашдомен.ru:

Тип: TXT Имя: _dmarc.example.ru Значение: v=DMARC1; p=none; rua=mailto:dmarc@example.ru

Разберём параметры:

v=DMARC1 — обязательный идентификатор версии. Всегда именно так.

p= — политика (policy). Три возможных значения:

• none — только мониторинг. Письма, не прошедшие проверку, доставляются как обычно, но вы получаете отчёты. Это стартовая точка: сначала смотрим, что происходит.
• quarantine — подозрительные письма помещаются в папку «Спам». Жёстче, но ещё не отклоняются.
• reject — письма, не прошедшие проверку, отклоняются на уровне сервера и не доставляются вовсе. Максимальная защита.

rua=mailto: — адрес для получения агрегированных отчётов DMARC. На этот адрес будут приходить XML-файлы с информацией о том, сколько писем прошло и не прошло проверку, с каких IP они отправлялись. Это ценные данные для мониторинга и отладки.

Дополнительные параметры:

pct= — процент писем, к которым применяется политика. Например, pct=20 означает, что политика применяется только к 20 % писем, не прошедших проверку. Удобно для плавного ужесточения.

aspf= и adkim= — строгость выравнивания (r — relaxed, s — strict). Определяет, насколько точно должны совпадать домены в SPF/DKIM с доменом в поле From. По умолчанию relaxed — подходит для большинства случаев.

sp= — отдельная политика для поддоменов.

Правильная стратегия внедрения DMARC — поэтапная. Начните с p=none и адресом для отчётов. Через 2–4 недели изучите отчёты, убедитесь, что все легитимные источники почты прошли SPF и DKIM. Затем переходите на p=quarantine с pct=10 и постепенно повышайте процент. После стабилизации — переходите на p=reject. Такой подход исключает риск случайной блокировки легитимной почты.

Раздел 6. Как проверить почтовые записи домена

После того как вы добавили MX, SPF, DKIM и DMARC в DNS, нужно убедиться, что всё настроено корректно. Изменения DNS вступают в силу не мгновенно — нужно время на распространение (от 15 минут до 48 часов, обычно в течение часа). После этого проводите проверку.

MxToolbox (mxtoolbox.com) — главный инструмент для диагностики DNS почты. Бесплатный, не требует регистрации. Позволяет проверить MX-записи, SPF, DKIM, DMARC, blacklist-статус домена и IP. Просто вводите домен, выбираете нужный тип проверки и получаете детальный отчёт с расшифровкой каждого элемента.

Как проверять по шагам:

Для MX: на главной странице MxToolbox введите домен и нажмите «MX Lookup». Вы увидите список MX-серверов с их приоритетами и A-записями. Убедитесь, что серверы совпадают с теми, что указал ваш почтовый провайдер.

Для SPF: в выпадающем меню выберите «SPF Record Lookup», введите домен. Сервис покажет содержимое вашей SPF-записи и проверит синтаксис. Наличие ошибок будет выделено красным. Также покажет количество DNS-запросов — убедитесь, что оно не превышает 10.

Для DKIM: выберите «DKIM Lookup». Потребуется ввести домен и selector (идентификатор ключа, который вам дал почтовый провайдер — например, «mail» или «dkim»). Сервис проверит наличие и корректность публичного ключа.

Для DMARC: выберите «DMARC Lookup». Сервис покажет вашу DMARC-запись и разберёт каждый параметр. Если записи нет — выдаст предупреждение.

Mail-tester.com — ещё один полезный инструмент. Он даёт уникальный email-адрес; вы отправляете на него тестовое письмо со своего домена, и сервис показывает детальный отчёт: прошло ли письмо SPF, DKIM, DMARC, какой у него «спам–балл», что нужно улучшить. Итоговая оценка — по шкале от 1 до 10. Результат 9–10 означает, что почта настроена отлично.

Google Postmaster Tools — если значительная часть вашей аудитории пользуется Gmail, зарегистрируйтесь в Google Postmaster Tools. Сервис показывает репутацию домена и IP у Google, процент писем, попадающих в спам, статус аутентификации (DKIM/SPF). Данные появляются только при достаточном объёме отправки.

После прохождения всех проверок отправьте тестовое письмо самому себе на Gmail или Яндекс-почту и откройте заголовки письма (в Gmail — три точки → «Показать оригинал»). Вы увидите строки Authentication-Results с результатами проверок SPF, DKIM, DMARC — все три должны быть «pass».

Раздел 7. Пошаговая настройка MX, SPF, DKIM и DMARC

Порядок действий при настройке почты на домене с нуля. Пример — подключение Яндекс 360 (Яндекс.Почта для домена), один из самых популярных вариантов для российского бизнеса. Логика та же для любого другого провайдера — меняются только конкретные значения записей.

Шаг 1. Зарегистрируйтесь и подтвердите домен у почтового провайдера.

Зайдите на 360.yandex.ru, создайте организацию, добавьте ваш домен. Яндекс попросит подтвердить владение доменом — обычно через добавление TXT-записи в DNS или через meta-тег на сайте. После подтверждения провайдер выдаст вам все необходимые значения для DNS-записей.

Шаг 2. Добавьте MX-запись.

Зайдите в панель управления DNS вашего домена (у регистратора или в панели хостинга). Найдите раздел DNS-записей. Добавьте MX-запись:

Тип: MX Имя: @ (корень домена) Значение: 10 mx.yandex.ru. TTL: 3600

Точка в конце значения — часть стандарта FQDN (Fully Qualified Domain Name). Некоторые панели управления добавляют её автоматически, в других нужно указать вручную.

Если ранее у домена уже были MX-записи (например, от старого провайдера) — удалите их перед добавлением новых. Конфликт MX-записей нарушает маршрутизацию почты.

Шаг 3. Добавьте SPF-запись.

Добавьте TXT-запись:

Тип: TXT Имя: @ (корень домена) Значение: v=spf1 include:_spf.yandex.ru ~all

Если вы одновременно используете несколько сервисов для отправки — добавьте все include в одну строку. Помните: SPF-запись должна быть только одна.

Шаг 4. Добавьте DKIM-запись.

В панели Яндекс 360 найдите раздел DKIM — там будет готовая TXT-запись с публичным ключом. Скопируйте её точно, без изменений. Добавьте в DNS:

Тип: TXT Имя: mail._domainkey.вашдомен.ru Значение: v=DKIM1; k=rsa; p=[длинная строка публичного ключа]

Будьте внимательны: значение ключа длинное, и панели управления иногда разбивают его на несколько строк. Убедитесь, что ключ добавлен как единая строка без разрывов.

Шаг 5. Добавьте DMARC-запись.

Тип: TXT Имя: _dmarc.вашдомен.ru Значение: v=DMARC1; p=none; rua=mailto:dmarc@вашдомен.ru

На старте используйте p=none — это мониторинговый режим без блокировок. Через месяц проверьте отчёты и переходите к более строгой политике.

Шаг 6. Подождите и проверьте.

Подождите от 30 минут до нескольких часов. Затем проверьте каждую запись через MxToolbox и отправьте тестовое письмо через mail-tester.com. Убедитесь, что все четыре записи работают корректно.

Раздел 8. Почему письма попадают в спам и как это исправить

Даже при наличии MX, SPF, DKIM и DMARC письма иногда попадают в папку «Спам». Причины бывают разные, и DNS-записи — лишь один из факторов доставляемости. Разберём самые распространённые.

Проблема 1: SPF настроен, но не включает все источники отправки.

Классическая ситуация: вы прописали SPF для Яндекса, но забыли добавить CRM-систему, через которую тоже отправляете письма клиентам. Или сервис email-рассылок. Письма с этих источников не проходят SPF-проверку и идут в спам. Решение: перечислите все сервисы, с которых уходит почта от вашего домена, и добавьте их в SPF-запись.

Проблема 2: Репутация IP-адреса отправляющего сервера.

Почтовые серверы смотрят не только на DNS-записи, но и на историю IP-адреса. Если ваш IP раньше использовался для спам–рассылок — это серьёзная проблема независимо от SPF и DKIM. Проверить репутацию IP можно через MxToolbox Blacklist Check. Если IP в чёрном списке — обратитесь к провайдеру хостинга или смените IP.

Проблема 3: Отсутствие PTR-записи (обратный DNS).

PTR-запись (Pointer Record) — это обратный DNS: она связывает IP-адрес сервера с именем хоста. Многие почтовые серверы проверяют PTR при приёме письма: совпадает ли имя хоста, с которого пришло письмо, с PTR-записью его IP. Если PTR не настроена или не совпадает — письмо вызывает подозрения. PTR настраивается не в DNS домена, а у провайдера хостинга — через панель управления сервером или по заявке в поддержку.

Проблема 4: Содержимое письма.

Спам-фильтры анализируют не только технические параметры, но и содержимое: наличие стоп–слов («бесплатно», «акция», «кликни сюда»), соотношение текста и изображений, наличие битых ссылок, слишком большое количество ссылок. Письма, написанные только в виде изображения без текста, почти всегда попадают в спам.

Проблема 5: Низкая вовлечённость получателей.

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

Проблема 6: DMARC в режиме none, но SPF или DKIM нарушены.

Некоторые провайдеры (особенно Gmail) уже при нарушении SPF или DKIM отправляют письма в спам — независимо от политики DMARC. Если отчёты DMARC показывают, что значительная часть писем не проходит SPF или DKIM, нужно устранять причину, а не оставлять всё на «потом».

Раздел 9. Типичные ошибки при настройке почтовых записей

Большинство проблем с почтой на домене вызваны несколькими типовыми ошибками. Зная их заранее, вы сэкономите часы отладки.

Ошибка 1: Две SPF-записи для одного домена.

Добавили SPF для Яндекса, потом подключили ещё один сервис и добавили вторую SPF-запись. Теперь у домена две TXT-записи, начинающиеся с v=spf1, — и SPF-проверка ломается: RFC прямо запрещает более одной SPF-записи. Принимающий сервер получает неоднозначный ответ и возвращает ошибку PermError. Решение: объединить всё в одну запись.

Ошибка 2: Превышение лимита DNS-запросов в SPF.

Цепочка include может незаметно перейти лимит в 10 запросов. Это не очевидно, потому что каждый include сам по себе может ссылаться на другие include. Проверить количество запросов можно через MxToolbox SPF Check — он показывает «lookup count». Если больше 10 — нужно упрощать запись, заменяя include на прямые ip4: или ip6:.

Ошибка 3: Неправильный selector в DKIM.

При добавлении DKIM-записи имя записи должно быть строго вида selector._domainkey.домен. Если вы используете selector «mail», запись называется mail._domainkey.example.ru. Типичная ошибка — добавить запись с неверным именем или вовсе пропустить часть _domainkey. Принимающий сервер не найдёт публичный ключ и DKIM-проверка провалится.

Ошибка 4: Разрыв в значении DKIM-ключа.

Публичный DKIM-ключ — длинная строка. Некоторые панели управления DNS ограничивают длину TXT-записи и автоматически разбивают её на несколько строк или кусков. В результате ключ добавляется с разрывами, и подпись не проверяется. Решение: убедитесь, что значение записи добавлено как единая строка. Если панель ограничивает длину — используйте формат с кавычками: «часть1» «часть2» — это стандартный способ добавления длинных TXT-записей.

Ошибка 5: Переход на p=reject без предварительной проверки.

Желание «сделать всё сразу правильно» приводит к тому, что DMARC сразу выставляется с p=reject. Если при этом не все легитимные источники настроены корректно — часть вашей собственной почты начинает отклоняться. Всегда начинайте с p=none, изучайте отчёты минимум 2–4 недели, и только потом ужесточайте политику поэтапно.

Ошибка 6: Не добавлен адрес для DMARC-отчётов.

Если в DMARC-записи нет параметра rua= — отчёты не будут приходить. Вы не увидите, что происходит с вашей почтой: сколько писем проходит проверку, с каких IP приходят подозрительные отправления. Отчёты — это ценная информация для мониторинга. Всегда указывайте адрес для rua=.

Ошибка 7: Забыть обновить SPF при смене или добавлении почтового провайдера.

Бизнес подключил новый сервис рассылок, а SPF-запись не обновил. Письма из нового сервиса не проходят SPF. Всякий раз, когда меняется инфраструктура отправки почты — SPF нужно пересматривать.

Ошибка 8: Проверять настройки сразу после изменения.

DNS-изменения распространяются не мгновенно. Если вы только что добавили запись и сразу проверяете — MxToolbox может показать старые данные из кэша. Подождите минимум 15–30 минут после изменения, а лучше час, прежде чем делать выводы о результате.

Раздел 10. Корпоративная почта: сервисы и рекомендации

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

Яндекс 360 (бывший Яндекс.Почта для домена) — самый популярный выбор для малого и среднего бизнеса в России. Базовый тариф включает корпоративную почту, облачное хранилище, календарь и ряд других инструментов. DKIM-ключи генерируются автоматически, готовые значения DNS-записей доступны прямо в панели управления. Техническая поддержка на русском языке. Для большинства небольших компаний этот вариант оптимален по соотношению цены и возможностей.

Google Workspace (бывший G Suite) — профессиональный вариант с корпоративным Gmail, Google Диском, Документами, Meet и другими инструментами. Более дорогой, чем Яндекс 360, но предпочтителен для компаний, работающих с международными партнёрами или уже использующих экосистему Google. SPF-запись: include:_spf.google.com, MX-записи — стандартные серверы Google.

Mail.ru для бизнеса — ещё один российский вариант с хорошей интеграцией в экосистему VK. Подходит для тех, кто уже использует другие сервисы Mail.ru/VK.

Собственный почтовый сервер — вариант для тех, кто хочет полный контроль над инфраструктурой или имеет специфические требования безопасности. Популярные решения: Postfix + Dovecot (для Linux), iRedMail (готовая сборка), Zimbra. Требует опытного системного администратора: самостоятельная настройка DKIM (через OpenDKIM), SPF, DMARC, PTR-записи, мониторинг репутации IP и регулярное обслуживание.

Отдельный сервис для транзакционной почты. Если с домена уходят не только личные письма, но и автоматические сообщения — подтверждения регистрации, уведомления о заказах, письма восстановления пароля — рассмотрите выделенный сервис транзакционной почты: SendGrid, Postmark, Unisender, Sendsay. Эти сервисы имеют хорошую репутацию IP и встроенные инструменты мониторинга доставляемости. Для них в SPF добавляется отдельный include, а DKIM может настраиваться через их панель управления.

Несколько практических рекомендаций:

Используйте разные субдомены для транзакционной и маркетинговой почты. Например, уведомления отправляйте с no-reply@mail.example.ru, а рассылки — с newsletter@promo.example.ru. Это защищает репутацию основного домена: если маркетинговые рассылки получат жалобы на спам, это не затронет транзакционную почту.

Настройте мониторинг DMARC-отчётов. XML-файлы, которые приходят на rua-адрес, сложно читать вручную. Существуют специализированные сервисы для их обработки: Dmarcian, Postmark DMARC, parsedmarc (бесплатный open-source инструмент). Они визуализируют данные и сигнализируют о проблемах.

Периодически проверяйте, не попал ли ваш домен или IP в чёрные списки. Это может произойти из‑за взлома аккаунта или компрометации сервера. MxToolbox Blacklist Check проверяет сразу по десяткам баз данных.

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

Заключение

Настройка MX, SPF, DKIM и DMARC — это не сложная магия и не задача исключительно для системных администраторов. Это последовательность понятных шагов, которую нужно пройти один раз при запуске корпоративной почты на домене. После правильной настройки система работает сама, надёжно защищая ваш домен от подделки и обеспечивая доставку писем в inbox получателей.

MX направляет входящую почту на нужный сервер. SPF ограничивает круг разрешённых отправителей. DKIM подписывает каждое письмо цифровой подписью. DMARC объединяет всё вместе и даёт инструменты для мониторинга и управления политикой.

Начните с добавления всех четырёх записей. Проверьте их через MxToolbox и mail-tester.com. Настройте DMARC в режиме p=none и изучайте отчёты в течение месяца. Затем поэтапно переходите на p=quarantine и p=reject. Это займёт несколько часов работы — но избавит от проблем со спамом, фишингом и недоставкой писем на годы вперёд.