Microsoft 365: MX-записи, SPF, DKIM, autodiscover и DMARC

Шаги

1. Добавьте и подтвердите домен. В центре администрирования Microsoft 365 добавьте домен и опубликуйте TXT-запись для подтверждения, которую он покажет (она начинается с MS=).
2. Создайте ящики и назначьте лицензии. Каждому адресу, который должен принимать почту, до переноса MX нужен ящик, общий ящик, группа или псевдоним.
3. Опубликуйте MX-запись. Скопируйте MX-хост из центра администрирования. Он образуется из имени вашего домена и оканчивается на mail.protection.outlook.com, а для доменов с входящей почтой, защищённой DNSSEC, — на mx.microsoft. Приоритет 0, других MX-записей быть не должно.
4. Опубликуйте SPF. Добавьте одну TXT-запись на самом домене: v=spf1 include:spf.protection.outlook.com -all. Других отправителей добавляйте в ту же запись.
5. Включите DKIM. Опубликуйте две CNAME-записи selector1._domainkey и selector2._domainkey с целями, которые портал Defender показывает для вашего домена, дождитесь, пока они начнут разрешаться, затем включите подпись для домена.
6. Добавьте autodiscover, DMARC и проверьте. Опубликуйте CNAME-запись autodiscover, чтобы Outlook находил ящик, добавьте DMARC-запись с p=none, затем запустите проверки на этой странице.

DMARC

DMARC одинаков для всех провайдеров: одна TXT-запись по имени _dmarc.example.com. Начните с p=none и адреса для отчётов: так вы будете получать отчёты, не влияя на доставку.

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

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Дополнительно: MTA-STS, TLS-RPT и BIMI

MTA-STS сообщает отправляющим серверам, что при доставке вам нужно требовать TLS. Нужны TXT-запись и файл политики, который отдаётся по HTTPS с mta-sts.example.com; в политике должны быть точно перечислены MX-хосты вашего провайдера.

TLS-RPT просит отправителей сообщать о сбоях TLS при доставке на выбранный вами адрес. Одна TXT-запись, на доставку не влияет.

BIMI позволяет некоторым почтовым сервисам показывать ваш логотип. Для него нужен DMARC с политикой quarantine или reject, а большинство сервисов требует ещё и сертификат подтверждённого знака.

_mta-sts.example.com.  3600  IN  TXT  "v=STSv1; id=20260921T000000"
_smtp._tls.example.com.  3600  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"
default._bimi.example.com.  3600  IN  TXT  "v=BIMI1; l=https://example.com/logo.svg"

Почтовые программы: autodiscover и autoconfig

Outlook находит ящик по CNAME-записи autodiscover.example.com → autodiscover.outlook.com. Без неё настольный Outlook может запросить параметры сервера или подключиться к старому локальному серверу, который всё ещё отвечает под этим именем.

Советы по TTL

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

Когда новая настройка проработает несколько дней, снова поднимите TTL: часто используют 3600 секунд. Записи SPF, DKIM и DMARC меняются редко, для них 3600 вполне подходит.

Сколько времени занимают изменения?

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

Момента, когда изменение оказывается сразу везде, не существует. Инструмент проверки распространения показывает, что отвечает фиксированный набор публичных резолверов в момент проверки, в виде счёта, например «9 из 12 резолверов», и ничего сверх этого.

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

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

• MX-хост или цели DKIM составлены вручную. Расхождения в один символ достаточно, чтобы подтверждение не прошло.
• DKIM включают раньше, чем обе CNAME-записи начали разрешаться: портал отказывает, и письма по-прежнему подписываются доменом onmicrosoft.com, который не выравнивается для DMARC.
• Две SPF-записи. У домена может быть только одна TXT-запись, начинающаяся с v=spf1; вторая приводит к постоянной ошибке SPF. Объедините механизмы include: в одной записи.
• MX-записи старого провайдера оставлены рядом с новыми. Тогда почта попадает то к одному, то к другому — в зависимости от приоритета и случая.
• Полное имя введено в поле хоста, которое само дописывает домен: получается google._domainkey.example.com.example.com. После сохранения проверьте запись запросом.
• DKIM-ключ, обрезанный посередине. Длинные TXT-значения нужно делить на строки в кавычках длиной не более 255 символов; большинство DNS-хостингов делает это за вас, но не все.
• Больше десяти DNS-запросов в SPF после добавления нескольких механизмов include:. Инструмент «Проверка SPF» их считает.
• MX-запись, указывающая на CNAME или на IP-адрес. Она должна указывать на имя хоста, у которого есть записи A или AAAA.