Настройка SPF, DKIM и DMARC в Microsoft 365

Microsoft 365 начинает отправлять почту от вашего домена сразу после подключения — но аутентифицировать её так, как этого требует DMARC, он не станет, пока вы не сделаете три вещи руками. И спотыкаются почти все на DKIM: M365 подписывает вашу почту по умолчанию, просто не от вашего домена. Получается настройка, которая выглядит завершённой и при этом не проходит согласование.

Что Microsoft 365 аутентифицирует сам

Когда вы добавляли домен в Microsoft 365, вы создали MX-запись на Exchange Online Protection и, скорее всего, запись SPF. Почта пошла. Остаются две дыры:

• DKIM для вашего домена. M365 подписывает исходящие письма автоматически — но ключом на домене вашего тенанта yourtenant.onmicrosoft.com. Для DMARC подписывающий домен должен согласовываться с видимым полем From:, а onmicrosoft.com с ним не согласуется. DKIM для своего домена нужно включать явно.
• Политика DMARC. M365 не публикует её за вас никогда. Без неё получатель не знает, что делать с письмом, не прошедшим проверку.

Лечится тремя записями в DNS и одним переключателем в портале. Заложите час плюс время на распространение DNS.

Шаг 1 — SPF для Exchange Online

Опубликуйте на корневом домене одну TXT-запись SPF, разрешающую серверы Microsoft:

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

Два правила:

• Только одна запись SPF. Если запись уже есть для другого отправителя, добавьте include:spf.protection.outlook.com в неё — никогда не публикуйте вторую v=spf1.
• Следите за лимитом в 10 DNS-запросов. Каждый include: идёт в зачёт. Если почта идёт через несколько сервисов, лимит легко превысить и обнулить SPF целиком. Посчитать и собрать корректную запись поможет бесплатный генератор SPF.

-all (жёсткий отказ) ставьте, когда уверены, что перечислили всех отправителей; ~all — безопасный промежуточный вариант.

Шаг 2 — включите подписывание DKIM для своего домена

Именно этот шаг чаще всего оставляют недоделанным. M365 использует DKIM на основе CNAME: вы публикуете две записи CNAME, указывающие на Microsoft, а ключами за ними — включая ротацию — управляет сам Microsoft.

Опубликуйте две записи, подставив свой GUID и имя тенанта (GUID совпадает с тем, что в вашей MX-записи):

selector1._domainkey   CNAME   selector1-<domainGUID>._domainkey.<tenant>.onmicrosoft.com
selector2._domainkey   CNAME   selector2-<domainGUID>._domainkey.<tenant>.onmicrosoft.com

Затем включите подписывание:

1. Откройте портал Microsoft Defender (security.microsoft.com).
2. Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM.
3. Выберите свой домен и переведите переключатель Sign messages for this domain with DKIM signatures в положение Enabled.

Ловушка вот в чём: переключатель не сработает, если обе CNAME ещё не опубликованы — портал выдаст ошибку «CNAME record doesn't exist». Сначала записи, потом время на распространение DNS, и только затем включение. Пока переключатель выключен, ваша почта продолжает подписываться как onmicrosoft.com и продолжает не проходить согласование.

Шаг 3 — опубликуйте DMARC

Добавьте TXT-запись на хосте _dmarc корневого домена, начиная с режима наблюдения:

v=DMARC1; p=none; rua=mailto:reports@yourdomain.com

p=none ничего не меняет в доставке — запись просит получателей присылать сводные отчёты, чтобы вы увидели, кто отправляет почту от вашего имени, ещё до того, как включите применение политики. Собрать полную запись можно в генераторе DMARC. Указывайте в rua= адрес или сервис, который кто-то действительно читает.

Проверьте согласование, прежде чем ужесточать

Пройденный SPF или DKIM — это ещё не пройденный DMARC: домен, по которому прошла аутентификация, должен согласовываться с вашим From:. Как только заработает DKIM на вашем домене, почта самого M365 будет согласована. А вот сторонние отправители, которые ходят через M365 или рядом с ним — CRM, тикет-система, маркетинговая платформа, — обычно не согласуются, пока каждого не настроить отдельно.

Поэтому перед ужесточением следите за сводными отчётами, пока все легитимные источники не начнут проходить проверку с согласованием. Дальше двигайтесь поэтапно: p=none → p=quarantine → p=reject. Если всё сделано правильно, день перехода к применению политики пройдёт незаметно. Как разбирать сами отчёты — в статье «Как читать сводные отчёты DMARC».

Типичные ошибки в Microsoft 365

• DKIM включают раньше, чем публикуют CNAME. Переключатель выдаёт ошибку — сначала обе записи, потом включение.
• Почта всё ещё подписывается как onmicrosoft.com. Значит, DKIM для своего домена так и не включили. Проверьте переключатель в Defender.
• Гибридная схема и локальные серверы. Если вы отправляете ещё и с локальных серверов, добавьте их IP-адреса в SPF: одного include Exchange Online для них мало.
• Сторонние сервисы, отправляющие через M365. Приложения, которые пишут «от имени» вашего домена, нужно согласовывать отдельно — настройка M365 не аутентифицирует их за вас.
• Ранний переход на p=reject. Без чистых отчётов вы заблокируете собственную почту. Право на применение политики зарабатывается доказательствами.

Когда SPF, DKIM на своём домене и DMARC настроены, а отчёты чистые, работа переходит в режим наблюдения: важно поймать следующий сервис, который кто-нибудь подключит к M365, до того как он начнёт тихо не проходить проверку. Для этого и нужен DDMARC — читаемые отчёты вместо сырого XML и оповещение, когда появляется новый отправитель.