Сразу оговорюсь о жанре: это гайд, а не разбор инцидента. Ничего драматичного здесь не случилось, поэтому и рассказывать буду порядок действий, а не историю. Факт по итогу простой: второй домен работает, пользователи подключаются.

Интересна в этом списке не сама последовательность записей — она описана в любой документации, — а то, что часть шагов нельзя менять местами, и то, что один из них вообще не в вашей власти.

Коротко

  • Домены добавляются в админке mailcow, дальше по каждому — SPF, DKIM, DMARC.
  • DKIM надо сначала сгенерировать в mailcow, иначе публиковать нечего.
  • PTR заказывается у провайдера и делается не вами — планировать заранее.
  • Отдельно: autodiscover, autoconfig и MTA-STS.

Шаг первый: домены в mailcow

Оба домена добавляются в админке. Это чисто внутренняя операция, снаружи пока ничего не меняется — и это удобно: можно подготовить всё, не трогая рабочую почту.

Шаг второй: SPF, DKIM, DMARC — именно в таком порядке

SPF объявляет, с каких серверов вашему домену разрешено отправлять почту. Запись одна, пишется руками.

DKIM — подпись исходящих писем. И вот тут важна очерёдность: ключ сначала генерируется в mailcow, и только потом публикуется запись в DNS. Если пойти наоборот, окажется, что публиковать нечего — открытого ключа ещё не существует. Звучит очевидно, но именно на этом шаге проще всего сработать по привычке «сел и прописал все записи разом».

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

Логика цепочки такая: SPF и DKIM — это утверждения о том, кто имеет право писать от вашего имени. DMARC — правило, что делать с нарушителями. Сначала утверждения, потом правило.

Шаг третий: PTR у провайдера

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

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

Шаг четвёртый: autodiscover, autoconfig, MTA-STS

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

На ста сорока ящиках разница между «само настроилось» и «объясните, что писать в поле сервер IMAP» — это разница между спокойным переездом и неделей звонков.

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

Как это выглядит в зоне целиком

Собранный набор записей для одного домена:

example.com.                 MX  10 mail.example.com.
mail.example.com.            A   203.0.113.25
example.com.                 TXT "v=spf1 mx -all"
dkim._domainkey.example.com. TXT "v=DKIM1;k=rsa;p=MIIBIjAN...(ключ из админки mailcow)"
_dmarc.example.com.          TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
autodiscover.example.com.    CNAME mail.example.com.
autoconfig.example.com.      CNAME mail.example.com.
mta-sts.example.com.         CNAME mail.example.com.
_mta-sts.example.com.        TXT "v=STSv1; id=20260901"
_autodiscover._tcp.example.com. SRV 0 1 443 mail.example.com.

Для второго домена то же самое, и MX указывает на тот же mail.example.com. Это, пожалуй, главное, что стоит понять про «два домена»: почтовый сервер один, имён у него по-прежнему одно, а доменов он обслуживает сколько угодно. Второй домен не получает собственного mail. — он ссылается на существующий.

Исключение — DKIM: ключ у каждого домена свой, и генерируется он отдельно.

Что стоит проверить после

Записи второго домена — то есть того, про который забывают:

dig +short MX example.org
dig +short TXT dkim._domainkey.example.org
dig +short TXT _dmarc.example.org

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

И три вещи, которые дешевле выяснить сразу:

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

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

Итог

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