Домен в Microsoft 365: TXT владения, MX, почтовые подписи и Autodiscover до cutover

Короткий ответ

Подготовка contoso.example к корпоративной почте в Microsoft 365 — это порядок DNS, не «подключить домен в мастере и уйти». Шаги: (1) TXT проверки владения, (2) принять домен в тенанте contoso.onmicrosoft.com, (3) создать ящики/алиасы до смены MX, (4) SPF с include:spf.protection.outlook.com, (5) DKIM CNAME + enable, (6) DMARC p=none + rua, (7) Autodiscover CNAME, (8) понизить TTL, (9) cutover MX на contoso-example.mail.protection.outlook.com, (10) проверка трейсом и заголовками. Не меняйте MX, пока пользователи не существуют в Entra. Не копируйте MX с чужого тенанта. Не ставьте p=reject в день cutover.

Откат: снимок всех записей зоны до правок.

Симптомы и как отличить

Это runbook «ещё не почта / миграция», не ремонт одного Ивана. Если домен давно в EO и «вдруг не доходит» — MX или очередь, не полный чеклист с нуля.

Возможные причины провала cutover

1. MX сменили за неделю до миграции ящиков.
2. Split-DNS на DC не обновили Autodiscover.
3. Два SPF после мастера хостера.
4. TTL 86400, «не доходит» сутки.
5. Старый forwarding регистратора перехватил MX.
6. Гибрид без плана SCP.

Диагностика «до» (базовая линия)

Снимите as-is:

Resolve-DnsName contoso.example -Type MX
Resolve-DnsName contoso.example -Type TXT
Resolve-DnsName autodiscover.contoso.example -Type CNAME,A
Resolve-DnsName _dmarc.contoso.example -Type TXT

nslookup -type=MX contoso.example
nslookup -type=TXT contoso.example
nslookup autodiscover.contoso.example

Кто принимает почту сейчас? Есть ли сайт на apex? Есть ли ESP? Список отправителей — вход в SPF.

Microsoft 365 admin → Domains: статус contoso.example (Setup needed vs Healthy).

Решение (порядок работ)

Шаг 1. Владение и Accepted Domain

Добавьте домен в admin center, опубликуйте TXT проверки (не MX). Дождитесь Verify. Get-AcceptedDomain должен видеть contoso.example.

Не удаляйте TXT проверки сразу, если мастер просит оставить.

Шаг 2. Идентичности

Создайте пользователей/синхронизацию, UPN @contoso.example, лицензии EO. Проверьте OWA по contoso.onmicrosoft.com до MX. Почта внутри тенанта должна жить.

Шаг 3. Autodiscover (можно до MX)

Публично: CNAME autodiscover.contoso.example → autodiscover.outlook.com. Внутренний split — то же, не A на старый IIS. Подробности: Autodiscover.

Шаг 4. SPF

Один TXT, минимум:

v=spf1 include:spf.protection.outlook.com -all

На переход с ESP добавьте их include, не превышая lookups — SPF. На время миграции допустим ~all, к стабилизации -all.

Шаг 5. DKIM

Опубликуйте обе CNAME из портала, Set-DkimSigningConfig -Enabled $true. Проверка: DKIM.

Шаг 6. DMARC

v=DMARC1; p=none; rua=mailto:dmarc@contoso.example

Не reject до инвентаря отправителей (DMARC). Ящик dmarc@ должен существовать.

Шаг 7. TTL вниз

За 24–48 ч до cutover снизьте TTL MX (и связанных) до 300–600, если провайдер позволяет.

Шаг 8. Cutover MX

В окне: MX только на имя из мастера Microsoft (contoso-example.mail.protection.outlook.com). Удалите MX регистратора/старого сервера. Выключите «email forwarding» в панели NIC.

Снимок зоны, ответственный на связи, откат = вернуть старый MX (TTL уже низкий).

Шаг 9. Проверки после

Пакет из проверки SPF/DKIM/DMARC. Плюс:

Connect-ExchangeOnline -UserPrincipalName admin@contoso.example
Get-MessageTrace -RecipientAddress ivan.petrov@contoso.example `
  -StartDate (Get-Date).AddHours(-2) -EndDate (Get-Date)

Внешнее тестовое письмо → Inbox. Outlook новый профиль на пилоте. Исходящее → заголовки pass.

Шаг 10. Зачистка

Старый сервер не должен тихо принимать (MX нет, но кто-то шлёт на A mail.). Мониторьте его лог. Поднимите TTL. План p=quarantine через недели чистых rua.

Пилот после cutover: три человека, включая ivan.petrov@contoso.example. Новый профиль Outlook, входящее с Gmail/другого тенанта, исходящее с проверкой заголовков, OWA, мобильный Outlook. Не объявляйте миграцию закрытой по зелёному мастеру доменов в admin center — мастер не проверяет сканер и CRM.

В тенанте contoso.onmicrosoft.com сверьте Accepted Domains = все SMTP, которые печатают на визитках. Часто забывают contoso.ru рядом с contoso.example: MX старый, люди думают «Microsoft 365 не работает». Повторите MX/SPF/DKIM/Autodiscover на каждый Accepted Domain.

ESP: либо include в SPF до cutover исходящих маркетинговых писем, либо временно From на их домен. Иначе в день MX вы получите и недоставку входящих (если ошиблись), и спам-классификацию исходящих рассылок.

Как проверить, что проблема устранена

Чеклист подписан:

• Domain Healthy в M365;
• публичный MX = protection.outlook.com;
• один SPF, DKIM Enabled, DMARC p=none;
• Autodiscover CNAME;
• трейс входящий Delivered;
• пилот Outlook;
• список ESP/сканеров покрыт или From изменён.

Если не помогло

• Входящие частично: кэш MX у крупных отправителей — ждите TTL, не прыгайте MX.
• Исходящие в спам: заголовки, не «ещё раз мастер домена».
• Только LAN Outlook: split Autodiscover/SCP.
• Поддомен info.contoso.example: свои MX/SPF, если отдельный контур.

Профилактика

• Шаблон зоны для следующего домена (вторая фирма холдинга).
• Запрет хостеру «оптимизировать почтовые записи».
• Мониторинг MX/expiry домена (WHOIS/registrar), отдельно от этой статьи.
• Документ гибрида, если он есть, рядом, чтобы не применили cloud-only runbook.

FAQ

Можно ли MX и Autodiscover в один день с TXT verify?

Verify — сразу. MX — когда ящики готовы. Autodiscover раньше MX полезен для пилотных профилей на onmicrosoft и кастомных адресах, но входящий SMTP определит MX.

Нужен ли SRV Autodiscover?

Нет как обязательный, если CNAME есть.

Старый сайт на apex сломается от MX?

MX не A apex. Сайт на A/AAAA/CNAME www не обязан умереть. Не удаляйте A apex, думая что это почта, если веб там.

SPF на onmicrosoft обязателен руками?

Нет, Microsoft держит свою зону. Вы готовите кастомный домен.

Сколько ждать DKIM Enabled после CNAME?

Минуты–часы плюс TTL. Не cutover MX в ту же минуту, что создали пустые CNAME, если исходящие критичны — подписи ещё нет.

Два тенанта, один домен

Нельзя. Сначала перенос домена между тенантами по процедуре Microsoft, потом этот чеклист.