Как изменить MX-записи домена и настроить SPF, DKIM, DMARC при переезде почты без потери писем

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

Свой домен — ваш, почта тоже должна быть вашей

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

Сделать это нужно аккуратно: от порядка изменений в DNS зависит, заметят ли переезд клиенты. Ниже — порядок, проверенный на стенде.

Пять строк в DNS, которые возвращают вам компанию

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

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

Какие записи меняются при переезде почты и зачем

Почта домена держится на нескольких DNS-записях. При смене провайдера меняются почти все, и у каждой своя роль.

Ошибка в любой из них проявляется по-разному: неправильный MX — письма не доходят, неполный SPF или отсутствующий DKIM — ваши письма попадают в спам или отклоняются, слишком строгий DMARC — получатели отвергают письма легитимных отправителей вроде 1С или сайта. Поэтому порядок изменений важнее самих записей. Общий план переезда, в который встраивается переключение DNS, — в руководстве по переносу почты с Яндекс 360.

TTL: почему его снижают заранее

TTL — время в секундах, на которое другие DNS-серверы запоминают ответ. Если у MX-записи TTL 3600, то после её изменения часть отправителей ещё до часа будет видеть старое значение и слать письма на старый сервер. Если TTL 86400 — до суток.

Поэтому за сутки-двое до переключения TTL записей MX и SPF снижают, например до 300 секунд. Важно: снижение TTL само действует только после того, как истечёт старый TTL — именно поэтому его меняют заранее, а не в момент переключения.

На нашем DNS-стенде (bind9, тестовая зона) это выглядит так. До изменения:

company.test.  3600  IN  MX  10 mx.old-provider.test.

После снижения TTL (серийный номер зоны увеличен, зона перезагружена):

company.test.  300  IN  MX  10 mx.old-provider.test.

Если зоной управляет панель регистратора или DNS-хостинга, серийный номер обычно меняется автоматически. Если вы ведёте зону сами в bind, не забудьте увеличить серийный номер в SOA — иначе вторичные DNS-серверы не заберут изменения.

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

MX: переключение приёма почты

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

После переключения проверьте запись с нескольких публичных DNS-серверов:

dig +noall +answer company.ru MX
dig +noall +answer company.ru MX @8.8.8.8
dig +noall +answer company.ru MX @77.88.8.8

На стенде после переключения ответ стал таким:

company.test.  300  IN  MX  10 mail.company.test.

Имя в MX должно указывать на A-запись (имя сервера), а не на IP-адрес и не на CNAME — так требует RFC 5321 в части обработки MX: значение MX — доменное имя хоста.

SPF: разрешить отправку и старому, и новому серверу

SPF описан в RFC 7208. Запись одна на домен и начинается с v=spf1. Если записей SPF две, проверка заканчивается ошибкой — частая проблема, когда новую запись добавляют рядом со старой вместо того, чтобы отредактировать существующую.

Яндекс 360 в справке рекомендует запись v=spf1 redirect=_spf.yandex.net, а если почту отправляют и другие серверы — формат с перечислением адресов и include: v=spf1 ip4:IP-1 ip4:IP-2 include:_spf.yandex.net ~all. На время переезда удобно именно так: новый сервер плюс Яндекс.

v=spf1 ip4:203.0.113.25 include:_spf.yandex.net ~all

Здесь 203.0.113.25 — адрес из документационного диапазона, подставьте IP вашего нового сервера. Вместо ip4: можно использовать механизм mx — тогда разрешены серверы, указанные в MX домена; на стенде переходная запись выглядела так: v=spf1 mx include:_spf.old-provider.test ~all.

Не забудьте остальных отправителей: сайт, 1С, CRM, сервис рассылок. Их адреса или include-записи должны остаться в SPF. Учтите ограничение RFC 7208: при проверке SPF допускается не более 10 DNS-запросов (механизмы include, a, mx, redirect и другие) — при длинной цепочке include запись перестаёт проверяться.

Когда через Яндекс больше никто не отправляет — сотрудники перешли, сканеры и 1С перенастроены, — include:_spf.yandex.net из записи убирают.

DKIM: опубликовать ключ нового сервера заранее

DKIM (RFC 6376) — подпись каждого письма ключом домена. Публичная часть ключа публикуется в DNS в TXT-записи <селектор>._domainkey.<домен>. У Яндекс 360, по справке, это селектор mail; у нового сервера будет свой селектор — тот, что задан в его настройках.

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

На стенде мы сгенерировали RSA-ключ 2048 бит и опубликовали его с селектором mail2026. Длинный ключ не помещается в одну строку TXT (ограничение 255 символов на строку), поэтому он разбит на части в кавычках — DNS-серверы склеивают их при ответе:

mail2026._domainkey  300  IN  TXT  ( "v=DKIM1; k=rsa; " "p=MIIBIjANBgkqh..." "...IDAQAB" )

В почтовых сборках (mailcow, iRedMail, Carbonio) ключ генерирует сама система, а вам остаётся скопировать готовое значение в DNS. Проверка — тем же dig: Как это делается вручную в Postfix с OpenDKIM, мы разбирали в статье «Настройка DKIM в Postfix».

dig +short mail2026._domainkey.company.ru TXT

DMARC: режим наблюдения на время переезда

DMARC (RFC 7489) публикуется в TXT-записи _dmarc.<домен> и говорит получателям, что делать с письмами, которые не прошли SPF и DKIM с выравниванием по домену отправителя, и куда слать сводные отчёты.

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

_dmarc  300  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@company.ru"

Через две-три недели, когда отчёты показывают, что все легитимные источники писем проходят проверки, политику ужесточают: сначала p=quarantine, затем p=reject. Если до переезда у вас уже стояла строгая политика, на время переключения её разумно ослабить — иначе письма сервера, ещё не добавленного в SPF и без опубликованного DKIM, будут отклоняться. Подробнее о том, что означают SPF, DKIM, DMARC и BIMI, — в отдельной статье.

PTR и имя сервера: без них письма уходят в спам

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

Имя в PTR должно совпадать с именем, которым сервер представляется в SMTP-приветствии (HELO/EHLO), и иметь A-запись на тот же адрес. Проверка:

dig +short -x 203.0.113.25
dig +short mail.company.ru A

Если вы переезжаете в облачный сервис, PTR — забота провайдера. Если на свой сервер — проверьте до переключения MX.

Порядок действий по часам

Сведём всё в одну последовательность. Время «Ч» — момент смены MX. Сам перенос писем и финальный проход описаны в инструкции по imapsync.

• Ч − 2 суток: TTL записей MX и SPF снижен до 300; ключ DKIM нового сервера опубликован; PTR нового IP настроен
• Ч − 2 суток: в SPF добавлен новый сервер рядом с Яндексом (ip4 или mx); DMARC в режиме p=none
• Ч − 1 сутки: основной перенос писем завершён, повторные проходы короткие
• Ч: MX заменён на новый сервер одним изменением
• Ч + TTL: проверка MX с публичных DNS, тестовые письма туда и обратно, в заголовках spf=pass, dkim=pass, dmarc=pass
• Ч + TTL: финальный проход imapsync с --maxage, чтобы забрать письма из старых ящиков
• Ч + 1 неделя: из SPF убран include старого провайдера, если через него никто не отправляет
• Ч + 2–3 недели: по отчётам DMARC политика ужесточается до quarantine, затем reject; старый DKIM-ключ удалён

Как проверить результат по заголовкам письма

Самая надёжная проверка — реальное письмо. Отправьте письмо с нового сервера на ящик у внешнего почтового сервиса и откройте его заголовки (в веб-интерфейсе это обычно пункт «Свойства письма» или «Показать оригинал»). Ищите заголовок Authentication-Results:

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

Это пример формата заголовка; точный вид зависит от сервиса-получателя. Важно, чтобы для вашего домена все три проверки были pass, а в header.s был селектор нового сервера.

Отдельно проверьте письма от всех автоматических отправителей: 1С, сайта, сканеров. Если они уходят через новый сервер — их адреса уже покрыты SPF; если отправляют напрямую — их адреса должны быть в SPF явно.

Автонастройка почтовых программ

Почтовые программы умеют сами находить параметры сервера по адресу ящика. Для этого используются разные механизмы: SRV-записи по RFC 6186 (_imaps._tcp, _submission._tcp), файлы автонастройки Thunderbird (поддомен autoconfig) и служба Autodiscover для Outlook (поддомен autodiscover).

Если у старого провайдера такие записи были, после переезда они будут отправлять программы сотрудников на старый сервер. Проверьте, какие из них есть в зоне, и либо замените на записи нового сервера (если он их поддерживает — mailcow, например, публикует autoconfig и Autodiscover), либо удалите.

dig +short _imaps._tcp.company.ru SRV
dig +short _submission._tcp.company.ru SRV
dig +short autoconfig.company.ru
dig +short autodiscover.company.ru

Outlook особенно настойчиво кэширует найденные настройки, поэтому после переезда профиль Outlook часто проще создать заново, чем исправлять. О связке mailcow и Outlook — в статье «Autodiscover mailcow и Outlook 365».

Если что-то пошло не так: откат

Низкий TTL нужен не только для быстрого переключения, но и для быстрого отката. Если после смены MX выяснилось, что новый сервер не принимает почту (ошибка в настройках домена, закрыт порт 25, неверный сертификат), верните прежние MX — при TTL 300 отправители увидят их за минуты.

Письма, которые за это время успели прийти на новый сервер, не пропадут: после исправления их можно перенести обратно в старые ящики тем же imapsync, поменяв местами host1 и host2, или просто дождаться повторного переключения.

Чтобы откат не понадобился, проверьте новый сервер до переключения: отправьте на него письмо напрямую (например, указав сервер в почтовом клиенте или командой swaks, если она установлена), убедитесь, что порт 25 доступен извне, а сертификат действителен для имени из MX. И не меняйте в одно окно сразу всё — DNS-провайдера, почту и сайт.

Если DNS домена тоже у Яндекса

Если домен делегирован на DNS-серверы Яндекса, записи редактируются в интерфейсе Яндекс 360 до тех пор, пока вы не перенесёте зону. Перед переездом почты зону часто переносят к другому DNS-провайдеру — регистратору или специализированному сервису, — чтобы почта и DNS не зависели от одного поставщика.

Порядок: выгрузить или переписать все записи зоны (не только почтовые — записи сайта, поддоменов, подтверждений сервисов), создать такую же зону у нового DNS-провайдера, проверить её ответы dig-запросами к новым серверам, и только потом сменить NS-записи у регистратора. Смену NS и смену MX лучше разносить по времени: сначала DNS, убедились, что всё работает, — потом почта. Подробно — в статье серии о переносе домена с Яндекса.

Частые ошибки

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