Outlook отклоняет почту без DMARC. Модератор Microsoft говорит о сбое

С 5 ноября 2026 года почтовые ящики Microsoft на outlook.com, hotmail.com, live.com и msn.com отклоняют часть писем с доменов, у которых в DNS нет записи DMARC, в том числе от небольших отправителей с рабочими SPF и DKIM. Подробно это описал 6 ноября Томас Джонсон, основатель и глава почтового сервиса MailRoute; 8 ноября его заметка попала на Hacker News и собрала больше 520 очков и около 350 комментариев. Отправителю возвращается отказ с текстом 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records.

Нового правила Microsoft не объявляла. 9 ноября в 11:24 мск модератор со статусом Microsoft External Staff сообщил на официальном форуме Microsoft Q&A, что это сбой сервиса с классификацией «service degradation» и что причина расследуется. Останется ли такая проверка постоянной или её откатят как ошибку, на вечер 9 ноября неизвестно.

Касается это каждого, чей домен отправляет почту: подтверждения регистрации, счета, уведомления сервиса, личная переписка с адреса на своём домене. Если получатель пользуется Outlook или Hotmail, часть писем могла не дойти. Проверка занимает минуту, исправление сводится к одной TXT-записи, и она пригодится при любом исходе: от массовых отправителей DMARC уже требуют Google, Yahoo и сама Microsoft.

Ключевые выводы

• Отказы начались около 5 ноября 2026 года. Текст ошибки: 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519); встречается и связка с кодом 550 5.7.23.
• Отклоняется часть писем: одно доходит, следующее возвращается, повторная отправка может пройти.
• Опубликованные требования Microsoft действуют с 5 мая 2025 года и относятся к доменам, которые отправляют больше 5 000 писем в день.
• 9 ноября модератор форума Microsoft назвал происходящее сбоем сервиса. В тот же день в 18:20 мск один из отправителей написал, что отказы прекратились.
• Проверка домена: dig +short TXT _dmarc.example.com. Минимальная запись: v=DMARC1; p=none. По сообщениям отправителей, после её добавления письма снова доходят; есть и сообщения об отказах при настроенных SPF, DKIM и DMARC.

Что происходит с письмами на Outlook и Hotmail?

Сервер Microsoft отвечает отказом с кодом 550, и отправитель получает сообщение о недоставке. По данным MailRoute, компания увидела такие отказы в собственных журналах исходящей почты 5 ноября, и в тот же день о них начали писать другие администраторы. В первый день ответ приходил без кода в скобках, затем к нему добавился (AS9031519).

У большинства доменов, которым отказали, SPF работал, а у многих был настроен и DKIM, пишет Джонсон. Не хватало третьей записи, DMARC: она связывает результаты SPF и DKIM с адресом в поле From.

Only some messages bounce, so "my mail is getting through" doesn't mean your domain is safe.

Наблюдения MailRoute подтверждают независимые источники. 6 ноября в 12:05 мск на форуме Microsoft Q&A появилась тема «SPF Validation Error»; к 9 ноября отметку «тот же вопрос» под ней поставили больше 100 человек. В тот же день в 15:29 мск о росте отказов написал хостинг-провайдер Mythic Beasts.

We've seen a dramatic increase in rejects from Microsoft with 'Message lacks SPF/DKIM/DMARC' even on domains with correct SPF + DKIM.

У части отправителей перед этим текстом стоит код 550 5.7.23 с упоминанием нарушения SPF. Для него у Microsoft есть страница справки об ошибке 5.7.23 с советом проверить SPF. Страницы об ошибке 5.7.1 с кодом AS9031519 мы в документации Microsoft не нашли.

Microsoft ввела новое правило или это сбой?

Неизвестно: объявления о новом правиле нет, а единственный ответ со стороны компании называет происходящее сбоем. Опубликованные требования Microsoft старше и уже: в анонсе от 2 апреля 2025 года компания обязала домены, которые отправляют на Outlook.com больше 5 000 писем в день, проходить SPF и DKIM и опубликовать DMARC с политикой не слабее p=none и выравниванием хотя бы по одному из двух механизмов. В обновлении от 29 апреля Microsoft написала, что с 5 мая 2025 года будет отклонять письма нарушителей с ошибкой 550 5.7.515.

Нынешние отказы, по описанию MailRoute, отличаются тремя признаками:

• доходят до небольших отправителей: вернуться может обычный ответ из маленького офиса;
• о них никто не предупреждал: на 6 ноября у Microsoft не было ни уведомления для почтовых администраторов, ни записи в блоге, ни сообщения о состоянии сервисов;
• ошибка 5.7.515 перечисляет результаты проверок SPF, DKIM и DMARC, а новая только утверждает, что записей нет.

Позиция Microsoft на форуме менялась. 6 ноября в 13:33 мск модератор Daniel-Vo ответил автору темы, что код 5.7.23 обычно означает проблему с SPF у отправителя. 7 ноября модератор-волонтёр EmilyS_726 предположила, что проблема на стороне Microsoft. 9 ноября Daniel-Vo написал новый ответ.

Based on the information available to me, there is currently an ongoing Exchange service issue messages to Outlook.com, Hotmail.com, or Live.com addresses. [...] This advisory is currently active and classified as a service degradation.

В пропущенной части ответа названы ошибки 550 5.7.1 и 550 5.7.23, связанные с проверкой SPF. DMARC не упомянут, причина и срок исправления не названы; модератор пообещал обновлять тему. Участники обсуждения возражают, что записи о сбое в панели состояния Microsoft 365 не находят. Автор сводного ответа в той же теме под ником Hornblower409 уточняет, что отсутствие DMARC объясняет не все случаи: есть сообщения об отказах доменам, у которых настроены все три механизма.

9 ноября в 18:20 мск участник темы Billy Collins написал, что в последние два-три часа письма его компании на адреса Hotmail, Live и Outlook снова проходят. Подтверждения от Microsoft, что проблема устранена, на вечер 9 ноября нет.

Чем требования Microsoft отличаются от правил Google и Yahoo?

По опубликованным документам различий почти нет: справка Google для отправителей, требования Yahoo Sender Hub и анонс Microsoft обязывают публиковать DMARC только массовых отправителей и довольствуются политикой p=none. Различие появилось в ноябре, когда отказы Outlook.com стали получать домены с любым объёмом почты. Это наблюдение администраторов, в документах Microsoft его нет.

У российских почтовых сервисов требования сформулированы для рассылок. Технические требования Mail для рассылок предписывают убедиться, что для домена «настроены SPF/DKIM/DMARC», а письма проходят проверку каждым из этих механизмов. «Яндекс» в требованиях к честным рассылкам называет обязательными подпись DKIM и SPF-запись, а DMARC рекомендует настроить. О похожих отказах со стороны этих сервисов нам неизвестно.

Как за минуту проверить свой домен?

Запросите TXT-запись с именем _dmarc перед вашим доменом. Команда приведена и в заметке MailRoute, и в приложении B.2.1 к RFC 7489, первой спецификации DMARC; вместо example.com подставьте домен из адреса отправителя:

        dig +short TXT _dmarc.example.com
    

Если запись есть, ответ начинается с "v=DMARC1. В примере из RFC 7489 он выглядит так:

        "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com"
    

Пустой ответ означает, что у этого имени записи нет; о таких доменах и сообщают отправители. Для поддомена проверьте и родительский домен: по документации Microsoft, его запись DMARC распространяется на поддомены без собственной. В Windows, где dig обычно не установлен, подойдёт команда из документации Microsoft о настройке DMARC:

        nslookup -type=TXT _dmarc.domain.com
    

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

Какую запись добавить и что должно работать вместе с ней?

Добавьте в DNS-зону домена TXT-запись. MailRoute приводит минимальный вариант:

        Name:  _dmarc
Value: v=DMARC1; p=none
    

Политика p=none объявляет, что домен использует DMARC, и не просит получателей применять меры к письмам, не прошедшим проверку. На то, как с вашей почтой обращаются Gmail и Yahoo, она не влияет, пишет Джонсон. Чтобы получать сводные отчёты от почтовых сервисов, добавьте адрес в тег rua, как в примере зоны из RFC 7489:

        _dmarc  IN TXT ( "v=DMARC1; p=none; "
                 "rua=mailto:dmarc-feedback@example.com" )
    

Если запись у домена уже есть, менять её ради этой ошибки не нужно. Одной записи мало в другом случае: DMARC проходит, только когда SPF или DKIM проходят для домена из поля From. Проверьте оба механизма у сервиса, который отправляет вашу почту.

• SPF: TXT-запись на самом домене со списком серверов, которым разрешено отправлять его почту. Для почты через Microsoft 365 документация Microsoft по SPF приводит значение v=spf1 include:spf.protection.outlook.com -all; у других сервисов оно своё.
• DKIM: подпись каждого письма ключом, открытая часть которого лежит в DNS. В Microsoft 365 для своего домена создают две CNAME-записи, selector1._domainkey и selector2._domainkey; их значения описаны в инструкции Microsoft по DKIM.

Отдельная ловушка для клиентов Microsoft 365: подпись доменом onmicrosoft.com для DMARC вашего домена не засчитывается, предупреждает MailRoute. По инструкции Microsoft, автоматически подписывается только почта с адресов вида contoso.onmicrosoft.com; для своего домена DKIM нужно настроить самостоятельно.

Как дальше ужесточать политику DMARC?

Постепенно и глядя в отчёты: сначала p=none, затем p=quarantine, затем p=reject. Такой порядок описан в документации Microsoft, примеры записей взяты оттуда:

1. Начните с p=none и наблюдайте за отчётами: v=DMARC1; p=none; pct=100; rua=mailto:rua@marketing.contoso.com; ruf=mailto:ruf@marketing.contoso.com. По ним видно, какая часть настоящей почты проходит DMARC и кто ещё отправляет письма от имени домена.
2. Замените политику на p=quarantine: владелец домена просит помещать не прошедшие проверку письма в спам. Долю писем, к которым она применяется, документация предлагает поднимать ступенями: pct=10, pct=25, pct=50, pct=75, pct=100.
3. Замените политику на p=reject: владелец просит такие письма отклонять. Как поступить на деле, решает принимающий сервис.

Microsoft советует двигаться медленно и разбирать каждую проблему из отчётов. Для домена, с которого почта не отправляется вовсе, документация предлагает сразу опубликовать v=DMARC1; p=reject;.

Две оговорки. Microsoft 365 не отправляет отчёты о сбоях по адресу из тега ruf, даже если он указан. А в мае 2026 года IETF выпустил обновлённую спецификацию DMARC, RFC 9989, которая заменила RFC 7489: тег pct в ней переведён в исторические, вместо него появился тег режима тестирования t. Причина названа в приложении A.6: промежуточные значения pct получатели применяли неточно, так что ступени вроде pct=25 не гарантируют заявленной доли. Документация Microsoft по-прежнему описывает pct.

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

Что такое DMARC простыми словами?

Это TXT-запись в DNS, которой владелец домена сообщает почтовым сервисам две вещи: что его письма подтверждаются через SPF или DKIM и что делать с письмом, которое проверку не прошло. Письмо проходит DMARC, если хотя бы одна из двух проверок успешна и её домен выровнен с доменом в поле From: при строгом режиме совпадает точно, при мягком (relaxed) достаточно общего организационного домена.

Что значит ошибка 550 5.7.1 Message lacks SPF/DKIM/DMARC Auth Records?

Сервер Microsoft отказался принять письмо для адреса на outlook.com, hotmail.com, live.com или msn.com. По наблюдениям MailRoute и участников форума Microsoft Q&A, с 5 ноября 2026 года чаще всего её получают домены без DMARC-записи, даже с рабочим SPF.

Достаточно ли политики p=none?

Чтобы письма перестали возвращаться, части отправителей, по их сообщениям, этого хватило. От подделки адреса p=none не защищает: владелец домена не просит ни отклонять, ни отправлять в спам письма, не прошедшие проверку. Собственную фильтрацию получателя политика не отменяет.

Нужно ли что-то делать, если я пишу с адреса на gmail.com или другом общем сервисе?

Нет, запись публикует владелец домена. У gmail.com она есть: 9 ноября команда dig +short TXT _dmarc.gmail.com возвращала "v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com". Действовать нужно тем, у кого адрес отправителя на собственном домене.

DMARC настроен, а письма на Outlook всё равно возвращаются. Что делать?

Такие случаи на форуме Microsoft описаны. Участники темы советуют сообщить о проблеме через форму поддержки отправителей Microsoft; модератор Daniel-Vo просит клиентов Microsoft 365 открыть обращение в поддержку и приложить журналы и образцы возвращённых писем в формате .eml.

Что будет дальше и за чем следить?

Главный сигнал: обновление в теме на Microsoft Q&A либо запись в блоге Microsoft, через который компания в 2025 году обещала объявлять сроки начала отказов. В начале ноября мы писали о форс-мажоре у хостинга Beget после кибератаки; здесь письма теряются при исправной инфраструктуре отправителя. Для Outlook.com это не первый случай необъяснённых отказов за год: в марте 2026 года издание The Register писало о письмах, которые сервис отклонял из-за сбоя или слишком строгих правил блокировки.

Каким бы ни оказался итог расследования, запись v=DMARC1; p=none, у части отправителей, по их сообщениям, уже сняла такие отказы, а отчёты по тегу rua покажут, готов ли домен к более строгой политике. Тем, кто на этой неделе проверяет серверы, пригодится и наш разбор уязвимости OpenSSH с длинными паролями.