Outlook спам: почему письма не доходят и как выйти из спама
Если письма попадают в спам Outlook, обычно не пройдена аутентификация SPF, DKIM и DMARC, IP-адрес попал в списки блокировки Microsoft либо жалоб пользователей на рассылку стало слишком много. Диагноз ставится за несколько минут по заголовкам письма и данным портала SNDS. Ниже: дерево диагностики, разбор реального набора заголовков, команды проверки DNS, типовые коды ошибок Microsoft и порядок снятия блокировки IP.
1. Как Outlook решает, куда положить письмо
Входящую почту для Outlook.com, Hotmail, Live.com и корпоративных ящиков Microsoft 365 фильтрует Exchange Online Protection (EOP). Письмо проходит несколько ступеней: проверку IP-адреса отправителя по спискам блокировки, аутентификацию SPF, DKIM и DMARC, затем контентную фильтрацию. По итогам письмо получает вердикты SCL (Spam Confidence Level) и BCL (Bulk Complaint Level) и попадает либо во входящие, либо в папку нежелательной почты, либо в карантин, где получатель его не увидит вовсе.
Отдельно Microsoft считает композитную аутентификацию (compauth): это итоговая оценка SPF, DKIM и DMARC с учетом выравнивания доменов. Она может быть fail даже при формальном spf=pass, если домен в конверте MAIL FROM и адрес From относятся к разным доменам. Именно compauth чаще всего решает судьбу писем крупных отправителей.
| Фактор фильтрации | Где проверять |
|---|---|
| Репутация IP и списки блокировки | Портал SNDS, логи SMTP вашей ESP |
| SPF, DKIM, DMARC | Заголовок Authentication-Results в письме |
| Композитная аутентификация | Поле compauth в Authentication-Results |
| Спам-вердикт контента | Заголовок X-Forefront-Antispam-Report, поля SFV и CAT |
| Жалобы на массовую рассылку | Поле BCL в X-Microsoft-Antispam, данные SNDS и JMRP |
- •Outlook.com и корпоративные ящики Microsoft 365 используют одну платформу фильтрации, но администратор аренды может ужесточить политики, поэтому один и тот же адресат на разных доменах получает письмо по-разному.
- •В корпоративных арендах письмо может уйти в карантин: его не видно ни во входящих, ни в спаме. Получатель узнает о нем из автоматического уведомления о карантине, которое Microsoft 365 рассылает по расписанию, либо может открыть карантин самостоятельно в Defender-портале, если это разрешено политикой карантина.
2. Дерево диагностики: читаем заголовки письма
Попросите получателя скопировать исходный текст сообщения: в веб-интерфейсе Outlook.com он открывается из меню письма, в классическом Outlook заголовки видны в свойствах письма. Быстрее держать два-три собственных тестовых ящика на outlook.com и hotmail.com и проверять доставку на них перед каждой крупной рассылкой.
Типичный фрагмент заголовков письма, которое попало в спам, выглядит так:
Authentication-Results: spf=fail (sender IP is 203.0.113.25) smtp.mailfrom=news.shop-example.ru; dkim=none (message not signed); dmarc=fail action=oreject header.from=shop-example.ru; compauth=fail reason=000 X-Forefront-Antispam-Report: CIP:203.0.113.25; SCL:5; SFV:SPM; CAT:SPOOF; X-Microsoft-Antispam: BCL:7
Такой набор читается как приговор сразу по трем пунктам: отправляющий IP не покрыт SPF, DKIM-подписи нет, DMARC не прошел из-за отсутствия выравнивания, а фильтр пометил письмо как подделку (CAT:SPOOF). Дальше работает таблица ниже.
| Наблюдение в заголовках | Вероятная причина и действие |
|---|---|
| spf=fail | IP рассылки не входит в SPF-запись домена: сверьте include у ESP и покройте новый сервис |
| dkim=none или dkim=fail | DKIM не настроен либо подпись битая: проверьте селектор и TXT-запись |
| dmarc=fail | Домен From не выровнен с d= подписи или MAIL FROM: проверьте выравнивание |
| compauth=fail и CAT:SPOOF | Фильтр считает письмо подделкой: добейтесь pass по всем трем проверкам |
| SFV:SPM при SCL:5 | Контентный вердикт спама: проверьте ссылки, редиректы и структуру письма |
| BCL на верхней части шкалы (например 7 из 9) | Высокий уровень жалоб на массовую рассылку: чистите базу и упрощайте отписку |
- ✕Ручной перенос писем из спама лечит симптом, но не причину: сначала добейтесь pass по SPF, DKIM и DMARC, иначе каждый новый выпуск начнется с той же позиции.
- ✕Отметка "не спам" реальными получателями со временем улучшает положение, но не снимает блокировку IP и не чинит аутентификацию.
3. Пошаговый план исправления
Шаг 1. Зафиксируйте состояние. Соберите письмо из папки нежелательной почты, коды ответов из логов ESP и текущие DNS-записи домена. Приостановите активные волны рассылки, пока идет разбор: отправка через проблемный ресурс усугубляет репутацию.
Шаг 2. Проверьте DNS из командной строки, а не по памяти:
dig TXT shop-example.ru +short dig TXT s1._domainkey.shop-example.ru +short dig TXT _dmarc.shop-example.ru +short nslookup -type=TXT shop-example.ru 8.8.8.8
Первая команда покажет SPF, вторая проверит публичный ключ DKIM-селектора, третья вернет DMARC-политику. SPF-запись должна быть одна на домен, а суммарное число DNS-запросов при ее вычислении не должно превышать десяти, иначе проверка завершится permerror. DMARC начните с p=none и мониторинга агрегированных отчетов, затем повышайте политику до quarantine и reject.
Шаг 3. Проверьте IP в публичных черных списках. EOP в том числе отклоняет почту с адресов из внешних DNSBL: в логах это код 550 5.7.1 с текстом blocked using Spamhaus. Быструю проверку по основным спискам можно сделать инструментом проверки черных списков PostmastersTool, а снятие проходить в кабинете самого оператора списка.
Шаг 4. Регистрируйтесь в SNDS и JMRP. SNDS показывает по каждому IP статистику доставки, уровень жалоб пользователей и срабатывания фильтров, JMRP пересылает копии жалоб. Эти два кабинета дают то, чего нет в Google Postmaster Tools и Mail.ru Postmaster, и подключать их стоит до падения доставляемости, а не после.
Шаг 5. Внесите исправления и возвращайте объем малыми партиями: тестовые ящики, затем малый сегмент, затем полная волна. Так вы увидите момент, на котором вердикты снова портятся.
4. Блокировка IP и коды ошибок Microsoft
Различайте два вида проблем. Блок IP: Microsoft перестает принимать соединения с адреса, в логах ESP появляются постоянные ошибки 5xx. Деградация домена: соединения принимаются, но письма стабильно ложатся в спам из-за репутации и аутентификации. SNDS агрегирует данные по IP-адресам, поэтому по домену напрямую там цифр не будет.
| Код или симптом в логах | Что означает и что делать |
|---|---|
| 451 4.7.500 Server busy, please try again later | Временная блокировка или троттлинг: проверьте политику повторных попыток у ESP |
| 550 5.7.511 Access denied, banned sender | IP внесен в список блокировки Microsoft: проверьте SNDS и подайте запрос на удаление |
| 550 5.7.1 Service unavailable, Client host blocked using Spamhaus | Адрес в публичном DNSBL: запросите удаление у оператора списка |
| 250 OK, но письма не видно даже в спаме | Карантин или правило аренды получателя: попросите администратора сделать трассировку сообщения |
Форма запроса удаления IP находится в портале поддержки отправителей Microsoft. Перед подачей убедитесь, что жалобы в SNDS снижаются и аутентификация исправлена, иначе блокировка вернется. Если отправка идет с общего IP, на котором работают другие клиенты ESP, проблема может быть не в вашем трафике: в этом случае обсуждают выделенный адрес или смену инфраструктуры.
5. Требования Microsoft к отправителю
Microsoft описывает ожидания от отправителей в документации Exchange Online Protection и Defender for Office 365: проходить SPF, DKIM и DMARC с выравниванием домена From, отправлять только на согласованные адреса, обрабатывать отписку и поддерживать корректные PTR и HELO для отправляющих хостов. Для сравнения: требования Google для массовых отправителей (от 5000 писем в день на Gmail) явно фиксируют порог жалоб ниже 0.1%, обязательные SPF, DKIM и DMARC и однокликовую отписку. У Microsoft ориентиром служат complaint level в SNDS и жалобы в JMRP.
| Проверка перед рассылкой | Как убедиться |
|---|---|
| SPF pass | dig TXT домена: одна запись, сумма DNS-запросов в пределах десяти |
| DKIM pass | dig TXT селектора, домен d= в подписи совпадает с From |
| DMARC с выравниванием | Политика опубликована, агрегированные отчеты без неожиданных источников |
| PTR и HELO у IP | Обратная зона указывает на отправляющий хост |
| Отписка | Заголовки List-Unsubscribe и List-Unsubscribe-Post в письме |
| Контроль жалоб | SNDS и JMRP подключены, тренды жалоб под наблюдением |
6. Как проверить результат
После исправлений проверяйте доставку на собственные адреса outlook.com, hotmail.com и на тестовый ящик в корпоративной Microsoft 365. В заголовках доставленных писем должны появиться compauth=pass, SFV:NSPM вместо SFV:SPM и отсутствие CAT:SPOOF. BCL должен снижаться по мере того, как база очищается, а жалобы перестают накапливаться.
Дальше задача состоит в том, чтобы исправления не сломались снова. PostmastersTool периодически проверяет DNS домена (SPF, DKIM, DMARC, MX) и публичные черные списки, присылает уведомления при пересечении порогов и хранит историю по дням, а DMARC-отчеты показывают, кто и чем отправляет от вашего домена. Данные SNDS проверяются вручную в кабинете Microsoft: держите эту проверку в регламенте.
Поскольку база рассылки одна и та же для всех провайдеров, следите за жалобами комплексно: доли SPF, DKIM и DMARC и уровень жалоб в Google Postmaster Tools и Mail.ru Postmaster видны в мониторинге PostmastersTool и хорошо дополняют картину по Microsoft.
- •Заведите еженедельную проверку заголовков на тестовых ящиках Outlook: пять минут рутинной проверки вместо недели разбора инцидента.
- •Сохраните пример битых заголовков до исправления: он пригодится для сравнения и для отчета руководству.
7. Ограничения и когда нужен аудит
Самостоятельный разбор не всегда доводит до конца. Типовые тупики: общий IP, на котором репутация портится чужим трафиком; смешение транзакционных и маркетинговых писем в одном домене без разделения потоков; смена ESP с переносом подписи DKIM и обнулением истории; противоречие между кодами SMTP (соединение принято) и вердиктами в заголовках (письмо в спаме). В этих случаях нужен разбор конфигурации целиком: DNS, потоки, инфраструктура отправки и репутация адресов.
Если письма в спаме у Microsoft стоят вам сделок или транзакций, выгоднее один раз пройти аудит доставляемости с командой, которая регулярно разбирает блокировки Outlook.com и Exchange Online, чем итерировать вслепую.
Что сделать дальше
Три инструмента и одна услуга, с которых начинают разбор проблем с Outlook.
- 1Разобрать заголовки письма
Вставьте заголовки из письма в спаме и получите разбор полей аутентификации и вердиктов Microsoft в браузере.
Анализатор заголовков - 2Проверить домен и IP
Автоматическая проверка SPF, DKIM, DMARC и публичных черных списков по вашему домену.
Проверить домен - 3Передать исправление спама
Если разбор затянулся дольше пары дней, имеет смысл передать его команде с практикой разблокировок.
Исправление спама - 4Обсудить аудит
Полный аудит доставляемости: DNS, потоки писем, репутация IP и план работ по Microsoft.
Обсудить аудит