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

Если Message Trace говорит Delivered, а человек видит Junk — это политика получателя плюс ваши сигналы аутентификации и репутации, не «сломанный Outlook». Снимите заголовок Authentication-Results: нужны spf=pass, dkim=pass и выравнивание с доменом From: (contoso.example). Потом DMARC. PTR чините только если письмо уходит не с *.mail.protection.outlook.com, а с вашего шлюза, МФУ, CRM или «SMTP провайдера». PTR у shared IP Microsoft вы не перепишете — и не должны.

Не просите контрагента «добавить в белый список» как первое действие. Сначала один валидный SPF, живой DKIM-селектор, DMARC хотя бы p=none с rua, и прекращение рассылки с хоста, которого нет в SPF.

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

Картина «нас все фильтруют» почти всегда локальная:

  • внутри contoso.onmicrosoft.com письма в Inbox, у Gmail — в спаме;
  • один тип писем (счета с billing.contoso.example, сканер, Bitrix) в Junk, обычная переписка Ивана — нет;
  • NDR 5.7.23 / 5.7.26 при отправке на Microsoft 365 — получатель-тенант отверг аутентификацию;
  • заголовок Received: from показывает IP дата-центра или домашний динамический адрес.
СигналСкорееНе путать с
Трейс Failed + 5.7.26их антиспам отверг SPF/DKIM/DMARC«пропало в очереди»
Трейс Delivered + Junkих классификатор, репутация, контентваш MX входящий
Только вложения-PDF с сайтаотдельный отправитель без DKIMполитика всего домена
Внезапно после смены DNSсломали SPF/DKIM TTLкомпрометация ящика

От недоставки отличайте по трейсу: Junk — письмо принято. От DMARC reject — там легитимный поток режется политикой вашего _dmarc, здесь чаще фильтр получателя.

Возможные причины

  1. Нет include:spf.protection.outlook.com или два SPF TXT — см. SPF.
  2. DKIM не включён для contoso.example / CNAME селектора не резолвится — DKIM.
  3. DMARC p=quarantine/reject при fail выравнивания: веб-форма шлёт From: ivan.petrov@contoso.example через хостинг без подписи.
  4. Сторонний SMTP (маркетинг, тикетница) не в SPF и без своего DKIM d=contoso.example.
  5. PTR/rDNS исходящего IP не совпадает с HELO, если это ваш шлюз. Для чистого Exchange Online PTR Microsoft корректный, его не «настраивают» в панели домена.
  6. Компрометация: ящик шлёт спам, репутация тенанта падает, легитимные тоже фильтруют.
  7. Контент: короткие письма с одной ссылкой на новый домен, URL-shortener, вложение .html. Это не лечится SPF.

Диагностика

1. Кто реально отправил

В заголовках смотрите цепочку Received снизу вверх и Authentication-Results. Для письма из Exchange Online типичен хоп *.mail.protection.outlook.com / Outlook. Если первый хоп — 10.0.10.10 или IP хостинга example.net — это не «облачная почта», даже если в From написано @contoso.example.

Resolve-DnsName contoso.example -Type TXT
Resolve-DnsName selector1._domainkey.contoso.example -Type CNAME
Resolve-DnsName _dmarc.contoso.example -Type TXT
nslookup -type=TXT contoso.example
nslookup -type=CNAME selector1._domainkey.contoso.example
nslookup -type=TXT _dmarc.contoso.example

Разбор записей — отдельный чеклист: как проверить SPF DKIM DMARC.

2. Выравнивание (alignment)

DMARC проходит, если SPF или DKIM выровнены с доменом заголовка From. Частый провал: SPF pass на bounces.esp.example, а From — contoso.example. Без DKIM на d=contoso.example DMARC fail, Gmail шлёт в спам.

3. PTR только для своего IP

nslookup 203.0.113.40

Имеет смысл, если этот IP стоит в Received как исходящий шлюз компании. Если IP принадлежит Microsoft — PTR не ваша зона, не создавайте «поддельный» PTR у регистратора: так нельзя указать чужой адрес.

4. Исходящий вердикт Microsoft

Connect-ExchangeOnline -UserPrincipalName admin@contoso.example
Get-HostedOutboundSpamFilterPolicy | Format-List Name, *Forwarding*, NotifyOutboundSpam

При компрометации Microsoft режет исходящие. Тогда «нас считают спамерами» — сначала инцидент ящика, не новые DNS-записи.

5. Message Trace vs Junk

Трейс Delivered + пользовательский Junk = работайте с заголовками и отправителями. Трейс FilteredAsSpam на исходе из вашего тенанта = политика вашего Defender, письмо могло не выйти.

Решение

Сценарий A. Чистый Exchange Online, SPF/DKIM дырявые

Соберите один SPF с include:spf.protection.outlook.com и -all, включите DKIM для домена в Defender / EAC, опубликуйте CNAME selector1/selector2. Подождите TTL. Проверочное письмо на внешний ящик, который вы читаете, сверьте dkim=pass.

Сценарий B. Сайт/CRM шлёт как пользователь домена

Либо добавьте include/ip4 ESP в SPF уложив 10 lookups, либо (лучше) ESP подписывает DKIM селектором, который вы делегировали, и From выровнен. Третий вариант: From на notify.contoso.example с отдельным DMARC. Не ставьте +all.

Сценарий C. МФУ/сканер через smtp.office365.com

Нужна SMTP AUTH (лучше клиентская отправка с современной аутентификацией, где поддерживается) или коннектор по сертификату. Сканер, который шлёт напрямую на порт 25 получателя с динамического IP офиса, будет в спаме всегда: нет PTR, нет SPF match, серый IP.

Сценарий D. Свой шлюз (pfsense, on-prem IIS SMTP)

Исходящий IP на A-записи HELO, PTR у провайдера на это же имя, IP в SPF ip4:, DKIM на шлюзе либо relay в Exchange Online. Без PTR от провайдера DNS-зона компании бесполезна.

Сценарий E. Репутация после взлома

Сброс сессий, пароль, MFA, удаление inbox rules, смена секретов SMTP. Потом уже DNS. Иначе вы подпишете DKIM на исходящий спам.

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

Отправьте контрольное письмо с ivan.petrov@contoso.example на три контура, которыми владеете (другой Microsoft 365, Gmail, любой с доступом к заголовкам). Во всех:

  • spf=pass, dkim=pass;
  • dmarc=pass если _dmarc уже есть;
  • письмо во Inbox без ручного «это не спам».

Повторите для каждого легитимного отправителя: сайт, сканер, рассылка. Один починенный Outlook ничего не доказывает для CRM.

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

  • Pass по SPF/DKIM, всё равно Junk: контент, новые домены в ссылках, жалобы пользователей (FBL), совпадение шаблона с фишингом. Меняйте шаблон и частоту, не -all на +all.
  • Только один получатель-тенант фильтрует: их политика ATP/антиспуфинг к вашему домену. Дайте им заголовки, не «белый IP Microsoft» — shared IP.
  • Поддомен mail.contoso.example в From, DMARC на корне с sp=reject — читайте DMARC.
  • Список подавления у ESP: это не DNS.

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

  • Перед p=reject недели p=none и разбор rua.
  • Инвентарь всех, кто имеет право ставить From @contoso.example.
  • Запрет прямого SMTP с пользовательских ПК наружу (порт 25).
  • Мониторинг всплеска исходящих и алерты outbound spam.
  • Не делегировать SPF партнёру без лимита lookups.

FAQ

Нужно ли покупать «выделенный IP» у Microsoft 365?

У стандартного Exchange Online исходящие IP общие и управляются Microsoft. Выделенный IP — не настройка DNS в админке домена. Для большинства SMB правильные SPF/DKIM/DMARC важнее мифа про «свой IP».

PTR в панели регистратора не меняет спам. Почему?

PTR привязан к владельцу IP (хостинг/провайдер канала), не к зоне contoso.example. Запись у регистратора домена — это не rDNS.

Помогает ли SPF +all, чтобы «все принимали»?

Наоборот: +all кричит «любой хост легитимен». Фильтры это наказывают. Нужен -all после инвентаря.

Почему внутри компании не спам, а снаружи да?

Внутренние письма часто не проходят публичную проверку SPF на границе. Внешние MX проверяют строго.

Стоит ли слать одно и то же письмо повторно «пока не дойдёт»?

Нет. Повтор с того же шаблона усиливает жалобы. Сначала заголовки, потом один контрольный тест.

Gmail просит зарегистрировать домен в Postmaster. Это обязательно?

Инструменты получателя полезны для репутации их контура, но не заменяют SPF/DKIM. Сначала DNS и alignment, потом кабинеты получателей.