Создание записей на DNS сервере для почтового домена

DNS записи для почтового домена
Коротко: какие DNS записи нужны для почты
Для рабочего почтового сервера нужно минимум пять записей: A (адрес сервера), MX (кто принимает почту), SPF, DKIM и DMARC (TXT записи для антиспама), PTR (обратная зона на стороне хостера). Для автонастройки клиентов добавь SRV записи _imaps._tcp, _submission._tcp и CNAME autodiscover / autoconfig. Apple Mail через DNS не настраивается, туда нужен отдельный .mobileconfig профиль.
Содержание: показать

Поднял mailcow. Почта не приходит. Знакомо?

Ты поднял mailcow, залил сертификаты, открыл порты. Отправил тестовое письмо самому себе на Gmail. Письмо ушло в спам, а то и вообще не дошло. Знакомо.

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

Здесь разберём не только базовый набор A, MX и TXT, который есть в каждой второй статье. Разберём SRV записи для автонастройки почтового клиента на Android, Windows и Apple, покажем какие из них реально работают, а какие давно устарели или никогда не работали как задумано.

Пример домена по тексту: my-domen.ru. Почтовый сервер на mailcow: mail.my-domen.ru. Меняешь на свои значения везде, где встретишь эти строки.

Что получишь на выходе: рабочую доставку почты без попадания в спам, автоматическую настройку почтового клиента на трёх основных платформах без единого клика пользователя (кроме Apple, о нём отдельно), и понимание что именно проверять, когда что-то снова сломается.

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

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

Второй частый косяк — тестирование сразу с боевым доменом без промежуточных проверок. Меняешь SPF, сразу шлёшь письмо в Gmail, получаешь спам, паникуешь, откатываешь изменения. Правильный порядок другой: проверил dig, проверил MXToolbox, проверил mail-tester, и только потом реальная переписка с живыми людьми. Так экономишь себе нервы и чужой почтовый ящик от спама тестовыми письмами.

Причины, почему без полного набора записей почта не работает как надо

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

Причина Почему ломает
Нет MX записи или указывает не туда Отправители не знают, куда доставлять письма для твоего домена. Почта либо не уходит, либо возвращается с ошибкой 5.1.2
Нет SPF записи Любой сервер может представиться отправителем от твоего домена. Получатели видят «неавторизованный источник» и режут в спам
Нет DKIM подписи Письмо нельзя криптографически подтвердить как неизменённое. Gmail и Yandex снижают репутацию отправителя за это в первую очередь
Нет DMARC политики Домен не защищён от подделки писем от твоего имени (фишинг с виду легитимного адреса)
PTR не совпадает с именем сервера Обратная зона на стороне хостинга (не регистратора) должна резолвиться в то же имя, что указано в HELO. Иначе крупные почтовики (mail.ru, Yandex, Gmail) режут сразу на SMTP уровне
Нет SRV записей автонастройки Thunderbird и мобильные клиенты на Android вынуждены запрашивать сервер, порт и протокол у пользователя вручную
Неверный TTL при миграции Старые записи кэшируются у провайдеров ещё сутки после изменения, письма продолжают лететь на старый сервер

Особенности для российских DNS-провайдеров

Большинство инструкций по DNS для почты пишут с оглядкой на Cloudflare и зарубежных регистраторов. У российской аудитории чаще всего зона крутится на Reg.ru, Timeweb, Beget или VK Cloud (бывший Mail.ru Cloud Solutions), и там есть свои мелочи.

В Reg.ru панель DNS не всегда даёт добавить SRV запись через обычную форму — иногда нужен раздел «Расширенное управление DNS» или переключение на NS самого Reg.ru вместо делегирования на хостинг. В Timeweb SRV записи доступны напрямую в разделе «DNS-записи» домена, формат ввода стандартный: приоритет, вес, порт, значение отдельными полями.

Если зона делегирована на Cloudflare (частая история, когда сайт крутится через CDN Cloudflare, а почта — отдельно на своём сервере) — держи все записи, связанные с почтой, в режиме DNS-only (серая тучка), не проксируй. Оранжевая тучка на MX или autodiscover записи ломает SMTP и HTTPS-автонастройку одновременно, потому что Cloudflare подменяет IP на свой edge, а почтовые протоколы через прокси Cloudflare не проходят.

VK Cloud и Yandex Cloud DNS поддерживают SRV записи без ограничений, но интерфейс местами требует вводить имя записи полностью с точкой на конце (_autodiscover._tcp.my-domen.ru.), иначе панель домножает домен дважды и получается кривое имя вроде _autodiscover._tcp.my-domen.ru.my-domen.ru. Всегда проверяй итоговое имя записи через dig сразу после сохранения, а не полагайся на то, что панель показала в форме.

Рецепт: собираем DNS зону для почтового домена по шагам

Подготовка

Прежде чем лезть в панель регистратора, собери три вещи под рукой: доступ к DNS зоне домена, доступ к панели хостинга или VPS (для PTR записи), и доступ в веб-интерфейс mailcow с правами администратора домена.

Компонент Актуальная версия на момент публикации
mailcow: dockerized 2026-06 (актуальный тег в репозитории, проверь свежий релиз перед установкой)
Docker Engine 27.x
Docker Compose plugin 2.29+
ОС хоста Ubuntu 24.04 LTS / Debian 12

На момент публикации актуальна указанная версия. Перед установкой проверь свежие релизы на GitHub mailcow-dockerized.

Шаг 1. A запись — адрес почтового сервера

Первое, что должен резолвить любой почтовый клиент или другой сервер — это IP адрес твоего mail-хоста. Без A записи всё остальное бессмысленно.


Тип: A
Хост: mail.my-domen.ru
Значение: 203.0.113.10
TTL: 3600

Результат: dig mail.my-domen.ru A +short должен вернуть тот же IP, что указан в панели хостинга у твоего сервера.

Если сервер работает и по IPv6, добавь AAAA запись с тем же именем хоста. Некоторые почтовики (в первую очередь Gmail) при наличии AAAA начинают предпочитать IPv6 канал, и там своя репутация IP, отдельная от IPv4.

Шаг 2. PTR запись — обратная зона

Вот тут важно не перепутать: PTR запись не создаётся у регистратора домена. Она создаётся на стороне хостинг-провайдера или VPS панели, потому что обратная зона привязана к владельцу блока IP адресов, а не к домену.

Без PTR почту не примут
Mail.ru, Yandex и Gmail проверяют совпадение PTR записи с именем, которое сервер называет в HELO при SMTP соединении. Если PTR отсутствует или указывает на généric-имя хостера вместо mail.my-domen.ru — письма будут отклоняться на уровне приветствия, ещё до проверки содержимого.

Как проверить и где искать: в Hetzner Cloud это раздел сервера «Networking» — «Reverse DNS. В OVHcloud и Vultr — аналогичный пункт в настройках сети сервера. Указываешь там mail.my-domen.ru, ждёшь применения (обычно до часа).


dig -x 203.0.113.10 +short

Результат должен быть строго mail.my-domen.ru. — с точкой на конце, это нормально для DNS ответов, не баг.

Шаг 3. MX запись


Тип: MX
Хост: my-domen.ru
Приоритет: 10
Значение: mail.my-domen.ru
TTL: 3600

Приоритет ниже — значит предпочтительнее. Если у тебя один почтовый сервер, приоритет можно оставить 10, второй резервный сервер (если появится) ставь с приоритетом 20 или выше.

Шаг 4. SPF запись

SPF (Sender Policy Framework) — это TXT запись, которая перечисляет, каким серверам разрешено слать почту от имени твоего домена.


Тип: TXT
Хост: my-domen.ru
Значение: "v=spf1 mx a -all"
TTL: 3600

mx и a означают «доверяй серверам, указанным в MX и A записях этого домена». Финальный модификатор -all означает жёсткий отказ всем остальным. Мягкий вариант ~all используют на переходный период, но для боевого домена держи -all, иначе SPF работает больше как рекомендация, а не правило.

Шаг 5. DKIM запись

DKIM ключ не пишешь руками. Он генерируется в mailcow: Configuration > Configuration & Details > ARC/DKIM keys, выбираешь домен, копируешь готовую TXT запись.


Тип: TXT
Хост: dkim._domainkey.my-domen.ru
Значение: "v=DKIM1; k=rsa; t=s; s=email; p=MIIBIjANBgkqh..."
TTL: 3600

Селектор dkim в примере выше — это дефолт mailcow, но его можно сменить в конфиге. Если меняешь селектор, не забудь что имя TXT записи в DNS должно точно совпадать с ним.

Шаг 6. DMARC запись


Тип: TXT
Хост: _dmarc.my-domen.ru
Значение: "v=DMARC1; p=quarantine; rua=mailto:dmarc@my-domen.ru; pct=100"
TTL: 3600

Начни с p=quarantine (подозрительные письма в спам, не отбраковка), понаблюдай отчёты пару недель, и только потом переключайся на p=reject, если уверен что SPF и DKIM настроены без ошибок у всех твоих легитимных источников отправки (включая, например, CRM или рассылочные сервисы, если они шлют от имени домена).

Шаг 6.1. MTA-STS и TLS-RPT — для тех, кто хочет закрыть тему шифрования транспорта

DMARC защищает от подделки писем, но не гарантирует, что письмо между серверами шло по зашифрованному каналу. Для этого существует MTA-STS — политика, которая запрещает отправителям падать на незашифрованный SMTP, если TLS недоступен.

Настройка состоит из TXT записи и HTTPS файла политики на отдельном поддомене:


Тип: TXT
Хост: _mta-sts.my-domen.ru
Значение: "v=STSv1; id=20260714120000"
TTL: 3600

Дальше нужен файл /.well-known/mta-sts.txt на https://mta-sts.my-domen.ru с содержимым вида version: STSv1, mode: enforce, mx: mail.my-domen.ru, max_age: 604800. Для одного почтового сервера в mailcow проще всего отдать этот файл через тот же nginx, что обслуживает основной домен, отдельным location блоком.

TLS-RPT добавляет отчётность о том, как часто соединения с TLS проваливаются:


Тип: TXT
Хост: _smtp._tls.my-domen.ru
Значение: "v=TLSRPTv1; rua=mailto:tls-reports@my-domen.ru"
TTL: 3600

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

Шаг 7. SRV записи для автонастройки IMAP / POP3 / SMTP (RFC 6186)

Вот тут начинается то, чего нет в девяти статьях из десяти. RFC 6186 описывает стандарт, по которому почтовый клиент может узнать настройки сервера через SRV записи, без единого клика пользователя. Thunderbird и Android клиент K-9 Mail поддерживают этот механизм из коробки.

Имя Тип Приоритет Вес Порт Значение
_imap._tcp.my-domen.ru SRV 0 1 143 mail.my-domen.ru.
_imaps._tcp.my-domen.ru SRV 0 1 993 mail.my-domen.ru.
_pop3._tcp.my-domen.ru SRV 0 1 110 mail.my-domen.ru.
_pop3s._tcp.my-domen.ru SRV 0 1 995 mail.my-domen.ru.
_submission._tcp.my-domen.ru SRV 0 1 587 mail.my-domen.ru.
_submissions._tcp.my-domen.ru SRV 0 1 465 mail.my-domen.ru.
_sieve._tcp.my-domen.ru SRV 0 1 4190 mail.my-domen.ru.

По факту большинство клиентов проверяют записи в таком порядке: сперва TLS-варианты (993, 587, 465), и только если их нет — переходят на STARTTLS (143, 110). Поэтому даже если у тебя весь трафик идёт через TLS-порты, оставь и STARTTLS-записи тоже: часть корпоративных прокси и старых клиентов на Android не умеет напрямую в TLS-обёртку и ждёт именно STARTTLS согласование.

Приоритет и вес в SRV записи имеют смысл только если у тебя несколько серверов, обслуживающих один и тот же протокол — например, основной и резервный IMAP. Для одиночного сервера mailcow всегда ставь приоритет 0 и вес 1, они ни на что не влияют, кроме случая балансировки между несколькими хостами.

Если POP3 у тебя отключён на сервере (а в 2026 году отключать POP3 — разумное решение, IMAP давно стандарт), объяви это явно записью с точкой вместо имени сервера. Так клиенты не будут пытаться достучаться до порта, которого нет.


Тип: SRV
Хост: _pop3._tcp.my-domen.ru
Значение: 0 0 0 .

Шаг 8. Autodiscover для Outlook и Windows

Microsoft использует свой протокол Autodiscover, не RFC 6186. Нужны два элемента: CNAME запись и SRV запись, указывающая на сервер autodiscover.


Тип: CNAME
Хост: autodiscover.my-domen.ru
Значение: mail.my-domen.ru.
TTL: 3600

Тип: SRV
Хост: _autodiscover._tcp.my-domen.ru
Приоритет: 0
Вес: 1
Порт: 443
Значение: mail.my-domen.ru.

Outlook при добавлении почтового ящика обратится по адресу https://autodiscover.my-domen.ru/autodiscover/autodiscover.xml, mailcow ответит на этот запрос сам — файл autodiscover.php уже встроен в поставку и работает из коробки, никаких дополнительных действий на сервере не требуется.

Свежие версии Outlook хитрят
Новые клиенты Outlook, особенно те, что идут в комплекте с подпиской Microsoft 365, иногда игнорируют самостоятельный Autodiscover и пытаются достучаться до серверов Microsoft напрямую. Если автонастройка не срабатывает с первого раза, попробуй добавить ящик через «Дополнительные параметры — Настроить учётную запись вручную» один раз, дальше профиль сохранится.

Шаг 9. Autoconfig для Thunderbird и Android (K-9 Mail, FairEmail)

Mozilla придумала свой механизм чуть раньше официального RFC, и он всё ещё жив. Нужна CNAME запись на поддомен autoconfig.


Тип: CNAME
Хост: autoconfig.my-domen.ru
Значение: mail.my-domen.ru.
TTL: 3600

Thunderbird обратится к https://autoconfig.my-domen.ru/mail/config-v1.1.xml, mailcow отдаст готовый XML со всеми параметрами IMAP и SMTP. Android почтовые клиенты, которые уважают Mozilla ISP database (K-9 Mail, FairEmail) — используют тот же путь.

Встроенный Gmail-клиент на Android для сторонних доменов автонастройку не поддерживает вообще, точка. Придётся вводить сервер, порт и протокол руками при первом добавлении ящика — это ограничение самого приложения, а не твоей DNS зоны.

Шаг 10. Apple Mail — зачем DNS тут бессилен

А вот здесь пора развеять миф, который кочует из статьи в статью: Apple Mail не читает ни SRV записи по RFC 6186, ни autodiscover, ни autoconfig. Никак. iOS и macOS Mail ожидают либо ручной ввод настроек, либо готовый профиль конфигурации .mobileconfig, подписанный и установленный на устройство.

mailcow умеет генерировать такой профиль сам — раздел SOGo webmail > Настройки > Mail > Mobile config отдаёт готовый файл, который пользователь скачивает через Safari на iPhone и устанавливает как профиль. Внутри уже прописаны сервер, порты, протоколы TLS — руками вводить ничего не нужно, но это не DNS-автонастройка, это отдельный офлайн-механизм.

Если у тебя корпоративный парк Apple устройств, профиль можно раздавать через MDM (Apple Business Manager, Jamf, Mosyle) вместо ручной установки каждым сотрудником. Для одного-двух ящиков проще просто прислать ссылку на mobileconfig.

Архитектура: как клиент находит настройки автоматически

%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#ffffff',
    'primaryTextColor': '#1e293b',
    'primaryBorderColor': '#94a3b8',
    'lineColor': '#64748b',
    'fontSize': '15px',
    'fontFamily': 'ui-sans-serif, system-ui, sans-serif'
  },
  'flowchart': {'curve': 'linear', 'nodeSpacing': 50, 'rankSpacing': 50}
}}%%
flowchart TD
    A["Windows Outlook"] --> B["Autodiscover CNAME plus SRV 443"]
    C["Thunderbird и Android K9"] --> D["Autoconfig CNAME"]
    E["Apple Mail iOS macOS"] --> F["Ручной ввод или mobileconfig"]
    B --> G["mailcow отдает XML настройки"]
    D --> G
    F --> H["Профиль устанавливается локально"]
    G --> I["Клиент настроен IMAP SMTP"]
    H --> I
    style A fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
    style C fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
    style E fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
    style G fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d
    style I fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d
    style F fill:#f8fafc,stroke:#f97316,stroke-width:2px,color:#9a3412

Таблица портов почтового сервера

Порт Протокол Назначение Доступен снаружи
25 SMTP Приём почты от других серверов Да
465 SMTPS Отправка почты клиентом (TLS сразу) Да
587 Submission Отправка почты клиентом (STARTTLS) Да
143 IMAP Чтение почты (STARTTLS) Да, лучше закрыть в пользу 993
993 IMAPS Чтение почты (TLS сразу) Да
110 / 995 POP3 / POP3S Устаревший протокол, оставлен для совместимости Опционально
4190 ManageSieve Управление фильтрами почты Опционально, для клиентов с поддержкой Sieve
443 HTTPS Webmail SOGo, autodiscover, autoconfig, mobileconfig Да

Проверка: убеждаемся что всё резолвится и работает


dig mail.my-domen.ru A +short
dig my-domen.ru MX +short
dig my-domen.ru TXT +short
dig dkim._domainkey.my-domen.ru TXT +short
dig _dmarc.my-domen.ru TXT +short
dig -x 203.0.113.10 +short
dig _autodiscover._tcp.my-domen.ru SRV +short
dig _imaps._tcp.my-domen.ru SRV +short

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

Для полной проверки не полагайся только на dig. Прогони домен через MXToolbox — он одним запросом проверит MX, SPF, DKIM, DMARC, PTR и покажет расхождения человеческим языком. Отдельно проверь итоговую доставку через mail-tester.com — пришли туда тестовое письмо, получишь оценку от 0 до 10 и список конкретных проблем.

Команда Что показывает
postqueue -p Очередь исходящей почты на сервере (если письма зависли)
tail -f /var/log/mail.log Живые логи приёма и отправки (путь зависит от дистрибутива, в mailcow смотри логи контейнера postfix-mailcow)
docker logs postfix-mailcow --tail 100 Логи Postfix внутри контейнера mailcow

Отдельно стоит проверять заголовки самого письма после доставки, а не только факт «дошло или нет». Открой полученное письмо в Gmail через «Показать оригинал» или в любом другом клиенте через просмотр исходного кода сообщения, и найди строки Authentication-Results. Там прямым текстом будет написано spf=pass или spf=fail, dkim=pass или dkim=fail, dmarc=pass или dmarc=fail. Это самый быстрый способ понять, какое именно звено подвело, не гадая по косвенным признакам вроде «письмо просто не пришло».

Если spf=pass, но dmarc=fail — почти всегда это про алигмент доменов. DMARC требует, чтобы домен в SPF (return-path) и домен в заголовке From совпадали с доменом организации, а не просто проходили проверку сами по себе. Если рассылка идёт через стороннего провайдера (например, транзакционные письма через SendGrid или Mailgun от имени твоего домена) — убедись что там настроен кастомный return-path на твоём домене, а не на домене провайдера рассылки.

Осложнения: что чаще всего идёт не так

Ошибка Причина Решение
Письма уходят в спам у Gmail Нет DKIM подписи или подпись не совпадает с телом письма Проверь dig dkim._domainkey.my-domen.ru TXT, убедись что ключ совпадает с тем, что показывает mailcow в интерфейсе
Ошибка 5.7.1 relay access denied Postfix не считает отправителя авторизованным для этого домена Проверь что домен добавлен в mailcow как «Domain», а не просто существует в DNS
Письма не доходят до mail.ru и Yandex PTR запись не совпадает или отсутствует dig -x IP, сверь с HELO именем сервера, поправь reverse DNS в панели хостинга
Outlook не находит настройки сам Нет CNAME autodiscover или SRV _autodiscover._tcp, либо TTL старой записи ещё не истёк Пересоздай записи, подожди TTL, попробуй ручной ввод один раз как обходной путь
Thunderbird предлагает ручную настройку вместо автоматической Нет CNAME autoconfig или сертификат на этом поддомене не валиден Проверь сертификат Let’s Encrypt в mailcow, он должен покрывать все поддомены autoconfig и autodiscover
Apple Mail просит логин каждый раз заново mobileconfig профиль не был установлен, используется обычный IMAP аккаунт Сгенерируй и установи .mobileconfig через SOGo, это устраняет большинство мелких сбоев синхронизации
SPF проверка не проходит, хотя запись есть В зоне случайно две TXT записи с v=spf1 (например, старая от прошлого хостинга) Оставь ровно одну SPF запись на домен, DNS не умеет объединять две политики корректно
DMARC отчёты показывают fail при валидных письмах Письмо прошло через пересылку (forwarding) и потеряло исходный конверт SPF Это ожидаемое поведение SPF при форвардинге, DKIM должен спасти алигмент, если DKIM тоже валится — проверяй подпись
Автонастройка работает в офисе, но не из дома Локальный DNS резолвер кэширует старые записи или блокирует нестандартные SRV запросы Проверь с телефона через мобильную сеть, если там работает — дело в локальном роутере или DNS сервере офиса
После смены IP сервера письма ещё сутки летят на старый адрес Не снижен TTL заранее перед миграцией За 24-48 часов до планового переезда снижай TTL записей до 300 секунд, переключай IP, возвращай TTL обратно после стабилизации
MTA-STS policy не подхватывается получателем Файл mta-sts.txt отдаётся без корректного Content-Type или сертификат на поддомене mta-sts не совпадает с основным доменом Проверь через curl -I https://mta-sts.my-domen.ru/.well-known/mta-sts.txt, убедись что ответ 200 и заголовок Content-Type: text/plain
DKIM подпись валидна, но письма всё равно в спаме Домен слишком новый, либо IP ещё не наработал репутацию у конкретного получателя Прогрей IP постепенно: первые недели небольшой объём писем, постепенно наращивая, вместо разовой массовой рассылки с нового сервера

Всё не так плохо как кажется после этого списка. Всё намного проще, если делать по порядку и не смешивать шаги миграции с шагами первичной настройки.

Частые заблуждения о DNS для почты

Раз уж собрались развенчивать миф про Apple и SRV, пройдёмся ещё по нескольким, которые кочуют из статьи в статью годами.

«SPF работает как whitelist по IP, этого достаточно без DKIM.» Нет. SPF проверяет, с какого IP пришло письмо, но ничего не говорит о том, изменилось ли содержимое по дороге, и не защищает от подмены заголовка From при пересылке через промежуточный сервер. DKIM подписывает содержимое криптографически, DMARC связывает оба механизма в единую политику. По отдельности каждый закрывает только часть проблемы.

«Чем длиннее TTL, тем стабильнее домен.» Длинный TTL снижает нагрузку на DNS серверы, но удлиняет любую миграцию и откат в случае ошибки. Для боевой зоны, которая не меняется месяцами, TTL 3600-86400 секунд нормален. Перед плановыми изменениями его стоит заранее снижать, а не держать вечно на минимуме «про запас».

«Если добавить все SRV записи, автонастройка точно заработает у всех клиентов.» Нет. Outlook игнорирует RFC 6186 SRV записи полностью и смотрит только на свой Autodiscover механизм. Apple Mail не смотрит ни на что из перечисленного. SRV записи по RFC 6186 полезны только для Thunderbird, K-9 Mail, FairEmail и похожих клиентов, которые explicitly реализуют этот стандарт.

«DMARC с p=reject сразу после настройки — это правильно и безопасно.» На практике это частая причина потери легитимной почты в первую неделю после запуска. Пока не увидел в отчётах DMARC (rua) стабильно нулевой процент провалов от своих же легитимных источников на протяжении хотя бы двух недель — держи p=quarantine, а лучше начинай вообще с p=none.

Сводная зона: все записи в одном месте

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


; A и AAAA
mail.my-domen.ru.               IN A     203.0.113.10

; MX
my-domen.ru.                    IN MX 10 mail.my-domen.ru.

; SPF
my-domen.ru.                    IN TXT   "v=spf1 mx a -all"

; DKIM (значение сокращено, бери реальное из mailcow)
dkim._domainkey.my-domen.ru.    IN TXT   "v=DKIM1; k=rsa; t=s; s=email; p=..."

; DMARC
_dmarc.my-domen.ru.             IN TXT   "v=DMARC1; p=quarantine; rua=mailto:dmarc@my-domen.ru; pct=100"

; MTA-STS и TLS-RPT
_mta-sts.my-domen.ru.           IN TXT   "v=STSv1; id=20260714120000"
_smtp._tls.my-domen.ru.         IN TXT   "v=TLSRPTv1; rua=mailto:tls-reports@my-domen.ru"

; Autodiscover (Outlook)
autodiscover.my-domen.ru.       IN CNAME mail.my-domen.ru.
_autodiscover._tcp.my-domen.ru. IN SRV   0 1 443 mail.my-domen.ru.

; Autoconfig (Thunderbird)
autoconfig.my-domen.ru.         IN CNAME mail.my-domen.ru.

; SRV для RFC 6186 (Thunderbird, K-9 Mail, FairEmail)
_imap._tcp.my-domen.ru.         IN SRV   0 1 143 mail.my-domen.ru.
_imaps._tcp.my-domen.ru.        IN SRV   0 1 993 mail.my-domen.ru.
_submission._tcp.my-domen.ru.   IN SRV   0 1 587 mail.my-domen.ru.
_submissions._tcp.my-domen.ru.  IN SRV   0 1 465 mail.my-domen.ru.
_sieve._tcp.my-domen.ru.        IN SRV   0 1 4190 mail.my-domen.ru.

; CAA
my-domen.ru.                    IN CAA   0 issue "letsencrypt.org"

; PTR задаётся отдельно, в панели хостинга сервера, не здесь

Держи такой файл в системе контроля версий (даже простой git репозиторий с одним файлом подойдёт) и коммить каждое изменение с понятным сообщением. Через полгода, когда придётся разбираться почему что-то снова сломалось, история изменений с датами скажет больше, чем память о том, «кажется, я что-то трогал в DNS в прошлом квартале».

Альтернативы: когда самому городить DNS зону не стоит

Если задача — просто иметь корпоративную почту на своём домене без возни с автонастройкой руками, посмотри в сторону готовых сервисов: Яндекс 360 для бизнеса и Mail.ru для бизнеса дают почтовые ящики на своём домене, автонастройку на всех платформах включая Apple через собственные механизмы, и не требуют от тебя вообще ничего кроме пары MX и TXT записей при подключении.

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

Есть и промежуточный вариант — взять готовый почтовый хостинг вроде Yandex Mail для домена (бесплатный тариф для небольших команд) или Zoho Mail, где инфраструктуру и репутацию IP держит провайдер, а ты управляешь только пользователями и алиасами. Для проектов, где почта не основной продукт, а просто нужный сервис для команды из пяти-десяти человек, это часто разумнее самостоятельного mailcow: меньше точек отказа, меньше вещей, которые могут сломаться в 3 часа ночи и разбудить именно тебя.

Для Apple устройств в корпоративном парке альтернатива ручной установке mobileconfig — MDM решение (Apple Business Manager с Jamf или Mosyle), которое раздаёт профиль автоматически при активации устройства, без участия пользователя.

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

Безопасность

  • Закрой firewall’ом (UFW или встроенный в mailcow) всё кроме реально используемых портов из таблицы выше
  • Включи fail2ban для Postfix и Dovecot — в mailcow это уже встроенный компонент, проверь что он активен в панели
  • SSH на сервере — только по ключу, отключи вход по паролю для root
  • DMARC начинай с p=none для сбора статистики, потом переходи на quarantine, и только затем на reject
  • Ограничь доступ к веб-интерфейсу mailcow по IP, если админка не нужна из любой точки мира
  • Добавь CAA запись, ограничивающую какие удостоверяющие центры могут выпускать сертификаты для домена: my-domen.ru. IN CAA 0 issue "letsencrypt.org". Это не остановит целенаправленную атаку, но отсекает случайный выпуск сертификата через скомпрометированный аккаунт в чужом CA
  • Держи отдельного пользователя базы данных для mailcow, не переиспользуй root доступ MySQL от других сервисов на том же хосте

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

Мониторинг DNS и репутации домена

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

Что мониторить Чем Как часто
MX, SPF, DKIM, DMARC записи не изменились Простой cron скрипт с dig и сравнением хэша вывода, либо сервис вроде UptimeRobot с DNS проверкой Каждые 15-30 минут
Репутация IP сервера в чёрных списках MXToolbox Blacklist Check или встроенный RBL монитор в mailcow Ежедневно
DMARC агрегированные отчёты Парсинг XML отчётов, которые приходят на rua адрес, вручную или через сервис вроде dmarcian Раз в неделю на старте, потом раз в месяц
Срок действия сертификата TLS Встроенный acme в mailcow обновляет сам, но стоит проверять раз в квартал что автообновление реально сработало Ежеквартально

Простой скрипт для проверки MX записи, который можно повесить в cron и получать уведомление в Telegram при расхождении:


#!/bin/bash
EXPECTED="mail.my-domen.ru."
CURRENT=$(dig my-domen.ru MX +short | awk '{print $2}')
if [ "$CURRENT" != "$EXPECTED" ]; then
  echo "MX запись изменилась: $CURRENT" | \
  curl -s -X POST "https://api.telegram.org/bot/sendMessage" \
       -d chat_id= -d text="ALERT: MX для my-domen.ru теперь $CURRENT"
fi

Резервное копирование

Бэкапь три вещи: конфигурацию mailcow (папка mailcow-dockerized целиком, включая .env), почтовые данные (том vmail-vol-1), и отдельно саму DNS зону — экспортируй файл зоны у регистратора после каждого изменения.

Что бэкапить Как часто Где хранить
Конфигурация и данные mailcow Ежедневно, встроенным helper-scripts/backup_and_restore.sh Отдельный сервер или S3-совместимое хранилище, не тот же диск
Экспорт DNS зоны После каждого изменения записей Git репозиторий или просто текстовый файл с датой в названии
DKIM приватный ключ Один раз при генерации, потом при ротации Зашифрованное хранилище, не в открытом виде на диске сервера

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

Обновление

Перед обновлением mailcow всегда смотри changelog на предмет изменений в DNS требованиях — иногда добавляют новые обязательные записи (например, при переходе на новую версию DKIM или добавлении MTA-STS). Обновляй через штатный update.sh, не руками через docker compose pull, скрипт сам проверяет совместимость версий compose-файла.

Если обновление меняет порты или добавляет сервисы — сначала проверь на staging копии (или хотя бы прочитай issues на GitHub за последнюю неделю перед релизом), потом только на проде. Откат делается тем же helper-скриптом restore на бэкап, снятый непосредственно перед обновлением.

Чеклист перед сдачей клиенту

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

  • A запись mail-хоста резолвится в правильный IP, проверено через dig с внешнего резолвера (не с самого сервера)
  • PTR запись установлена на стороне хостинга и совпадает с HELO именем сервера
  • MX запись указывает на mail-хост, приоритет корректен
  • SPF содержит ровно одну запись на домен, без дублей от старого хостинга
  • DKIM ключ в DNS совпадает с тем, что показывает mailcow
  • DMARC настроен минимум на p=none с рабочим адресом для rua отчётов
  • SRV записи для RFC 6186 добавлены, POP3 явно отключён записью с точкой, если не используется
  • Autodiscover CNAME и SRV на месте, проверено реальным добавлением ящика в тестовый Outlook
  • Autoconfig CNAME на месте, проверено в Thunderbird
  • Mobileconfig профиль сгенерирован и протестирован хотя бы на одном iPhone
  • Тестовое письмо прогнано через mail-tester.com, оценка не ниже 8 из 10
  • Клиенту передана сводная таблица записей и объяснение зачем каждая нужна (не только список, а именно объяснение, иначе через год никто не поймёт что можно трогать, а что нет)

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

FAQ

Почему почта не работает после настройки MX записи?

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

Как проверить что SRV записи для автонастройки работают правильно?

Выполни dig _autodiscover._tcp.my-domen.ru SRV +short и аналогично для остальных сервисов. Если команда возвращает строку с приоритетом, весом, портом и именем сервера — запись видна публичному DNS. Дальше проверяй уже в самом клиенте: удали учётную запись и добавь заново, указав только email и пароль, без ручного ввода сервера.

Что делать если Apple Mail не настраивается автоматически?

Это ожидаемое поведение, не баг твоей DNS зоны. Apple Mail не поддерживает ни RFC 6186 SRV записи, ни Microsoft Autodiscover, ни Mozilla Autoconfig. Нужен файл .mobileconfig, который mailcow генерирует в веб-интерфейсе SOGo, или ручной ввод настроек IMAP и SMTP.

Чем SRV записи автонастройки отличаются от Autodiscover у Microsoft?

SRV записи по RFC 6186 (_imap._tcp, _submission._tcp и другие) — открытый стандарт, который читают Thunderbird и некоторые Android клиенты напрямую из DNS. Autodiscover от Microsoft — собственный протокол Outlook, который использует CNAME на поддомен autodiscover плюс запрос HTTPS XML файла с этого адреса, а не только DNS запись.

Нужна ли AAAA запись, если сервер работает только по IPv4?

Нет, и добавлять её «на всякий случай» не стоит. Пустая или неверная AAAA запись хуже её отсутствия — почтовые серверы попробуют достучаться по IPv6, получат таймаут, и только потом откатятся на IPv4, теряя время на каждое соединение.

Сколько ждать, пока новые DNS записи заработают?

Зависит от TTL записи и того, как быстро твой регистратор публикует изменения в авторитетных серверах. Обычно от 15 минут до нескольких часов. Полное распространение по всем кэширующим резолверам мира может занять до 24-48 часов, особенно если менял TTL непосредственно перед изменением записи, а не заранее.

Обязательно ли настраивать MTA-STS для маленького домена?

Нет, для одного-двух почтовых ящиков это не критично. MTA-STS становится нужен, когда с доменом работают корпоративные партнёры с жёсткими требованиями к шифрованию транспорта, либо когда домен уже сталкивался с попытками downgrade атаки на TLS соединение.

Почему в Cloudflare почта перестала ходить после включения прокси?

Оранжевая тучка Cloudflare проксирует HTTP и HTTPS трафик через edge-серверы Cloudflare, подменяя реальный IP сервера. MX запись и записи, связанные с почтой (A запись для mail-хоста, autodiscover, autoconfig), должны оставаться в режиме DNS-only, серая тучка, иначе почтовые протоколы просто не достучатся до твоего сервера.

Можно ли использовать один и тот же почтовый сервер для нескольких доменов?

Да, mailcow поддерживает мультидоменную настройку без проблем. Но каждому домену нужен свой полный набор записей: своя SPF, свой DKIM селектор (или общий селектор с разными ключами на каждый домен), своя DMARC политика. Общий у доменов остаётся только IP сервера в A записи и, соответственно, PTR запись, которая привязана именно к этому IP, а не к конкретному домену. Если один из доменов на сервере начнёт слать спам или попадёт в чёрный список, репутация IP пострадает у всех доменов сразу, поэтому для важных клиентских проектов иногда имеет смысл разносить домены по разным исходящим IP.

Что в итоге

Полный набор DNS записей для почтового домена — это не только MX и пара TXT записей для галочки. Это A и PTR для базовой доставки, SPF, DKIM и DMARC для репутации и защиты от подделки, и отдельный слой SRV плюс CNAME записей для автонастройки клиентов — причём для Windows и Thunderbird этот слой реально работает через DNS, а для Apple придётся смириться с ручным профилем.

После того как вся зона собрана и прошла проверку через dig и MXToolbox, имеет смысл вернуться к ней через неделю и посмотреть DMARC отчёты (rua). Именно там видно реальную картину: какие серверы шлют письма от имени домена, проходят ли они SPF и DKIM, и нет ли легитимных источников, которые ты забыл включить в SPF при первой настройке (частая ситуация — забытый CRM или сервис email-рассылок, который до сих пор шлёт от имени основного домена в обход mailcow).

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

Отдельно вынеси для себя главный вывод из всей этой возни: DNS для почты — это не разовая настройка, а живая система, за которой нужно приглядывать. Домены меняют владельцев, регистраторы меняют интерфейсы панелей, стандарты вроде MTA-STS появляются и постепенно становятся ожидаемыми у крупных получателей. То, что работало без нареканий два года, может однажды перестать работать не потому что ты что-то сломал, а потому что требования на другой стороне тихо ужесточились.

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

Андрей А.
Author: Андрей А.

Руководитель ИТ / Кризис-менеджер 25 лет в IT: от инженера в МегаФоне до руководителя отдела. Знаю, как выглядит бардак: нестабильные сети, устаревшая инфраструктура, конфликты в команде, раздутые сроки. Помогаю бизнесу выходить из кризиса: навожу порядок в легаси, стабилизирую то, что разваливается, выстраиваю прогнозируемые процессы. Не раз возвращал к жизни ИТ-структуры — знаю цену хаосу. 📍 Ищу проект для полной реорганизации / стабилизации. 📬 Telegram: @over_dude ✉️ mail@it-apteka.com

Оставайтесь на связи

Рецепты от IT-боли. Без воды, без рекламы, без маркетинговой шелухи.

Подписаться на IT-Аптеку →

Мы ВКонтакте

IT-Аптека — советы, новости и помощь рядом.

Вступить в группу ВКонтакте →
Поделитесь:

Похожие записи

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Прокрутить вверх