Если вы держите почту на собственном VPS, следите за этим внимательно. В начале ноября 2026 года администраторы начали сообщать, что Outlook.com отклоняет сообщения с доменов, у которых вообще нет записи DMARC - не потому, что письма похожи на спам, а потому, что у домена отправителя просто нет DMARC-записи в DNS.[9] Письма возвращались с постоянным отклонением прямо во время SMTP-диалога, а не переездом в папку «Спам». Ваша почта либо приходит, либо исчезает, и чтобы понять, почему, нужно потратить полдня на раскопки в DNS.

Решение не сложное. Нужны три DNS-записи - SPF, DKIM и DMARC - опубликованные правильно, плюс одно правило выравнивания (alignment), в котором ошибается большинство. Это руководство разбирает всё по первичным источникам: по RFC, которые описывают каждую запись, по опубликованным требованиям Microsoft к отправителям и по официальной документации популярных self-hosted стеков (Postfix, docker-mailserver, mailcow). Никаких догадок и «примерных вариантов».

Коротко

Добавьте DMARC-запись для своего домена. Если вы отправляете почту с self-hosted сервера, всего записей будет четыре:

  • v=spf1 mx -all (или похожая) в корне домена - SPF
  • v=DKIM1; k=rsa; p=... на selector._domainkey - DKIM
  • v=DMARC1; p=none; rua=mailto:... на _dmarc - DMARC
  • PTR-запись (обратный DNS) у провайдера вашего IP, указывающая на hostname почтового сервера[1]

Запись DMARC - та самая, которая связывает две другие и говорит получателю, что делать с ошибками. Пока её нет, Outlook.com считает письма с вашего домена непрошедшими аутентификацию, и, по сообщениям сообщества в начале ноября 2026 года, начал отклонять часть таких писем полностью.[9]

Что именно изменилось, а что нет

Будьте точны в этом вопросе, потому что от разницы зависит ваша реакция.

Что официально задокументировано Microsoft: с 5 мая 2025 года Microsoft требует, чтобы домены, отправляющие более 5 000 сообщений в день на аккаунты Outlook.com, полностью проходили SPF, DKIM и DMARC. Почта от несоответствующих высокообъёмных отправителей уходит в папку «Спам», а если проблема не решается, домен может быть отклонён с ошибкой 550; 5.7.515 Access denied, sending domain [domain] does not meet the required authentication level.[1] Это опубликованная официальная политика, нацеленная на массовых отправителей.

Что сообщество начало видеть в ноябре 2026 года: администраторы сообщали о новом отклонении - 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records - которое затрагивает домены без DMARC-записи, включая низкообъёмных отправителей, шлющих несколько писем в день.[9] По состоянию на день написания этой статьи поведение официально не объявлено ни в постмастерской документации Microsoft, ни в политике.[1] Поэтому относитесь к этому как к широко обсуждаемому тренду и раннему сигналу, а не как к цитате из спецификации Microsoft. Безопасное решение одинаково в обоих случаях - опубликуйте все три записи и добейтесь, чтобы DMARC проходил с alignment.

Почему это стоит вашего времени, даже если у вас низкий объём: поведение «reject» - тот самый паттерн, которому следует каждый крупный провайдер - сначала обязательные требования для массовых отправителей, а потом тихое расширение на всех, у кого нет DMARC.[9] Рабочая DMARC-политика также защищает ваш домен от подделки и является единственной записью, благодаря которой получатели могут присылать вам отчёты о том, кто пытается подделать вашу почту.

Почему почта работала годами и вдруг перестала

Аутентификация почты - это три отдельных механизма, и ни один из них в отдельности не говорит получателю «этот домен настоящий». Вместе - говорят. Вот что делает каждый из них, по стандартам, которые их определяют.

SPF (RFC 7208) позволяет домену публиковать список IP, которым разрешено отправлять почту за него.[3] Получатель запрашивает SPF-запись домена из конверта (envelope sender) и проверяет, есть ли IP подключившегося сервера в списке. Он отвечает на вопрос: «разрешено ли этому серверу отправлять почту за этот домен?» И ничего не говорит про адрес From, который виден в почтовом клиенте.

DKIM (RFC 6376) - это цифровая подпись сообщения. Отправляющий сервер подписывает исходящие письма приватным ключом, а получатель проверяет подпись по публичному ключу, опубликованному в DNS под именем selector._domainkey.[4] Он отвечает на вопрос: «подписано ли тело и заголовки этого сообщения владельцем известного приватного ключа?»

DMARC (RFC 7489) - политика поверх этих двух, и именно её вам не хватает. DMARC говорит получателю, как обращаться с сообщениями, не прошедшими аутентификацию, и требует, чтобы какой-либо из методов - SPF или DKIM - был выровнен (aligned) с доменом в видимом адресе From.[5] Это выравнивание - тот шаг, который пропускают, и именно поэтому у домена может быть идеальный SPF и DKIM, но всё равно не проходить DMARC.

Если ваш сервер годами отправлял почту с рабочими SPF и DKIM, аутентификацию он проходил. Но без DMARC-записи, согласно документации Microsoft по политике, эти сообщения считались не полностью аутентифицированными - именно этот пробел и стоит за ноябрьскими отклонениями.[1][9]

Шаг 1: публикуем SPF-запись

SPF-запись - это TXT-запись в корне домена. Она перечисляет каждый IP и каждый авторизованный сервис, отправляющий почту за ваш домен. Для одного self-hosted почтового сервера типичная форма такая:[6]

MYDOMAIN.TLD.  IN  TXT  "v=spf1 mx -all"

Механизм mx авторизует те хосты, которые обслуживают вашу MX-запись. Если у почтового сервера есть отдельный статический публичный IP, которого нет в MX, используйте ip4:

MYDOMAIN.TLD.  IN  TXT  "v=spf1 ip4:203.0.113.7 -all"

Хвост записи важен. ~all - это softfail (получатель должен считать несанкционированных отправителей подозрительными, но обычно не отклонять); -all - это hard fail (получатель может отклонять). Согласно постмастерской документации Microsoft, SPF обязан проходить для домена отправителя.[1] Для self-hosted сервера, где вы контролируете каждого отправителя, начинайте с -all, как только убедитесь, что ни один сторонний сервис не шлёт письма с адресом вашего домена в конверте - иначе этот сервис тихо перестанет работать.[6]

Одно жёсткое правило: в изначальной конструкции у SPF есть лимит в 10 DNS-запросов на цепочку механизмов, поэтому не добавляйте бесконечные include: от каждого маркетингового сервиса, который когда-либо пробовали. Каждый include может съедать DNS-запросы, а запись, превышающая лимит, даёт permerror, и проверка проваливается целиком.[3]

Шаг 2: настраиваем DKIM

DKIM требует пару ключей. Приватный ключ остаётся на почтовом сервере и подписывает исходящие письма; публичный ключ публикуется в DNS, чтобы получатели могли проверить подпись.

Если у вас docker-mailserver, сгенерируйте ключ встроенным setup-скриптом. Текущий дефолт - RSA-2048, и проект прямо рекомендует его, а не более крупные ключи, ради совместимости:[7]

docker exec -it <container-name> setup config dkim

Скрипт записывает DNS-файл (по умолчанию mail.txt), содержащий публичный ключ. Опубликуйте его как TXT-запись под соответствующим именем селектора - по умолчанию mail._domainkey, т.е. mail._domainkey.MYDOMAIN.TLD, с содержимым вроде:[7]

"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

В mailcow веб-интерфейс сам генерирует публичный ключ DKIM для каждого домена и показывает точную TXT-запись, которую нужно добавить; документация указывает запись на dkim._domainkey для новых стеков и mail._domainkey для других.[6]

После публикации перезапустите или пересоздайте почтовый сервер, чтобы он подхватил ключ, отправьте тест и посмотрите на подписанные заголовки. DKIM работает, только когда подпись покрывает домен из заголовка From - а это пересекается с тем самым выравниванием, которое мы настроим дальше.[7]

Шаг 3: добавляем DMARC-запись - ту самую, которой не хватало

DMARC - это одна TXT-запись на _dmarc. Именно её отсутствие и спровоцировало ноябрьские отклонения.[9] Начните в режиме мониторинга, p=none:

_dmarc.MYDOMAIN.TLD.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@mydomain.tld"

Составные части, по стандарту DMARC и документации Microsoft:[2][5]

  • v=DMARC1 - обязательный тег версии.
  • p= - политика для писем, проваливших проверку: none (только мониторинг), quarantine (отправлять ошибки в спам) или reject (просить получателей отбрасывать такие письма). Рекомендация Microsoft - как минимум p=none, лучше p=reject.[1]
  • rua= - адрес, на который приходят агрегированные DMARC-отчёты, чтобы вы видели, какие легитимные источники проваливаются.

Сначала используйте p=none, соберите отчёты за неделю-две и только потом ужесточайте до quarantine, а затем reject, когда убедитесь, что все ваши легитимные отправители проходят с alignment. Microsoft прямо маршрутизирует исходящую почту доменов с собственной DMARC-политикой p=reject или p=quarantine через высокорисковый пул доставки, если она не проходит DMARC - то есть строгая политика на неработающей конфигурации ухудшает доставляемость, а не улучшает.[2]

Правило выравнивания, в котором ошибается большинство

Вот та часть, которая отделяет «я добавил три записи» от «это действительно проходит». DMARC требует большего, чем просто прохождения SPF или DKIM по отдельности. Прошедший метод должен ещё и совпадать (align) с доменом в видимом адресе From.[2][5]

Для каждого механизма есть два режима выравнивания, и задаются они независимо тегами aspf и adkim:

  • Relaxed (по умолчанию) - домен SPF или DKIM должен иметь общий организационный домен (регистрируемая часть после публичного суффикса) с адресом From. То есть DKIM, подписанный с d=m.mail.mydomain.tld, выравнивается с From user@mydomain.tld, потому что оба находятся под mydomain.tld.
  • Strict - контактирующий домен должен совпадать с доменом From один в один (по семантике тегов aspf=[r|s] / adkim=[r|s] из RFC 7489).[5]

На практике именно поэтому self-hosted сервер может проходить SPF и DKIM, но всё равно проваливать DMARC: если ваши веб-формы или сторонние релеи отправляют с доменом конверта или подписи, не совпадающим с вашим доменом From, проверка выравнивания проваливается. DKIM должен быть подписан с d=, равным вашему домену From (или его поддомену при relaxed-правилах), а SPF должен покрывать фактический подключающийся сервер для домена From.

Типичная мониторинговая политика с явным relaxed-выравниванием и запросом отчётов:[2]

_dmarc.MYDOMAIN.TLD.  IN  TXT  "v=DMARC1; p=none; aspf=r; adkim=r; pct=100; rua=mailto:dmarc@mydomain.tld; ruf=mailto:dmarc@mydomain.tld"

pct=100 применяет политику ко всем сообщениям; снижайте его только во время пробного периода. ruf - URI для форензик-отчётов об ошибках (необязательно). Эта запись говорит: «просто монитори всё, relaxed-выравнивание по обоим механизмам и присылай мне отчёты».

Проверяем всё через dig

Не доверяйте «зелёному статусу» в панели DNS - проверяйте извне. Эти три команды, запущенные с машины, отличной от вашего почтового сервера, подтвердят, что каждая запись резолвится и выглядит правильно.

Проверяем SPF (корень домена), DMARC (_dmarc) и DKIM (ваш селектор):

dig +short TXT mydomain.tld
dig +short TXT _dmarc.mydomain.tld
dig +short TXT mail._domainkey.mydomain.tld

Ищите: SPF-запись, начинающуюся с "v=spf1, DMARC-запись с "v=DMARC1; p=, и DKIM-запись с "v=DKIM1; k=rsa; p=.... Если dig не возвращает ничего для _dmarc - это ровно то состояние, на которое и были нацелены ноябрьские отклонения.[9]

Проверьте также обратный DNS. Microsoft требует валидную PTR-запись, совпадающую с вашим отправляющим hostname, а почта с IP из динамических диапазонов может быть отклонена вовсе.[1] PTR задаётся у провайдера IP, а не у регистратора DNS:

dig +short -x 203.0.113.7

Результат должен быть FQDN (например mail.mydomain.tld), которое ваш сервер сообщает в HELO/EHLO-приветствии.

Затем отправьте реальное тестовое письмо на адрес Outlook.com / Hotmail / Live и посмотрите заголовки. В строках Authentication-Results вы хотите увидеть spf=pass, dkim=pass и dmarc=pass (p=NONE) с правильными выравниваниями. Если что-то показывает fail или bestguesspass - чините эту запись, прежде чем доверять настройке.

Про PTR и репутацию IP, которые нельзя пропустить

DNS-записей недостаточно. Даже с идеальными SPF, DKIM и DMARC почта может отскакивать, если у отправляющего IP плохая репутация или он в динамическом диапазоне. Постмастерская страница Microsoft прямо говорит: соединения с IP из динамических диапазонов могут не приниматься, а у почтовых серверов обязан быть валидный обратный DNS.[1] Поэтому потратьте две минуты на правильную PTR-запись - её не видно в вашей DNS-зоне, но видно каждому получателю.

Для свежего IP на VPS прогрев всё ещё нужен: начинайте с низкого объёма, держите отправку стабильной и следите за DMARC-отчётами: легитимные источники, проваливающиеся в них, нужно добавлять в SPF/DKIM до ужесточения политики.

Итог

Ноябрьские отклонения 2026 года - резкое напоминание, что аутентификация почты больше не опция для self-hosted почты. Решение - это три DNS-записи и одно правило корректности:

  1. SPF в корне со списком всех авторизованных отправителей - для типичного сервера v=spf1 mx -all.[1][3]
  2. DKIM на вашем селекторе - сгенерируйте ключ, опубликуйте публичный ключ в TXT, подпишите с d=, совпадающим с вашим доменом From.[4][7]
  3. DMARC на _dmarc в режиме мониторинга с rua=, а после подтверждения, что alignment проходит, ужесточайте до quarantine/reject.[2][5]

Запустите dig, чтобы подтвердить, что все три резолвятся, задайте PTR, отправьте тестовое письмо на @outlook.com и прочитайте заголовок Authentication-Results. Как только появится dmarc=pass для вашего реального домена From, ваш домен перестанет быть той лёгкой целью, которую Microsoft тихо отклоняет - и заодно вы закроете дверь для спуферов, использующих ваш домен в фишинге.

Источники

  1. Microsoft - Outlook.com Postmaster: Policies, Practices, and Guidelines (требования к высокообъёмным отправителям с 05.05.2025; SPF должен проходить; DMARC минимум p=none; требования к PTR и динамическим IP). https://substrate.office.com/ip-domain-management-snds/Postmaster/Policies - проверено 2026-11-09
  2. Microsoft Learn - Set up DMARC to validate email (синтаксис DMARC TXT, p=none/quarantine/reject, высокорисковый пул, alignment). https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/email-authentication-dmarc-configure - проверено 2026-11-09
  3. RFC 7208 - Sender Policy Framework (SPF): https://datatracker.ietf.org/doc/html/rfc7208 - проверено 2026-11-09
  4. RFC 6376 - DomainKeys Identified Mail (DKIM): https://datatracker.ietf.org/doc/html/rfc6376 - проверено 2026-11-09
  5. RFC 7489 - DMARC: Domain-based Message Authentication, Reporting, and Conformance (alignment, aspf/adkim relaxed vs strict, pct, rua/ruf). https://datatracker.ietf.org/doc/html/rfc7489 - проверено 2026-11-09
  6. mailcow: dockerized documentation - DNS setup (записи SPF, DKIM, DMARC, PTR). https://docs.mailcow.email/getstarted/prerequisite-dns/ - проверено 2026-11-09
  7. docker-mailserver - DKIM, DMARC & SPF (генерация ключей, дефолт RSA-2048, имена DNS-записей). https://docker-mailserver.github.io/docker-mailserver/latest/config/best-practices/dkim_dmarc_spf/ - проверено 2026-11-09
  8. Microsoft TechCommunity - Strengthening Email Ecosystem: Outlook’s New Requirements for High-Volume Senders (блог Defender, лежащий за политикой 5.7.515). https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730 - проверено 2026-11-09
  9. MailRoute blog - “Outlook.com Is Quietly Rejecting Email From Domains Without DMARC” (сообщения администраторов о 550 5.7.1 “Message lacks SPF/DKIM/DMARC Auth Records” у низкообъёмных доменов без DMARC с начала ноя 2026). Сигнал тренда, не первичный источник фактов. https://mailroute.net/blog/outlook-rejecting-email-without-dmarc - проверено 2026-11-09