Мониторинг репутации на Microsoft: SNDS и JMRP от настройки до алертов
Microsoft — единственный крупный провайдер, который показывает отправителю его репутацию изнутри. Инженерный playbook по SNDS и JMRP: доступ на весь /24, автоматическая выгрузка CSV по ключу, чтение цвета фильтра и полос жалоб в терминах порога 0.1%, и связка ARF-жалоб с конкретной рассылкой.
EvilMail Team14 июля 2026 г.13 мин чтения
Письма на outlook.com и hotmail.com вдруг начали падать в «Нежелательные». В логах Postfix при этом идеально чисто: 250 2.6.0 <...> Queued mail for delivery. Никакого reject, никакого 550, никакой временной 4xx-задержки. Сервер Microsoft принял письмо, сказал спасибо — и молча положил его в Junk. Это фирменный почерк Microsoft: они почти не отбивают почту и крайне редко объясняют причину прямо в SMTP-сессии. Репутация решается тихо, на уровне фильтра, уже после того как соединение закрыто.
Ни один внешний blacklist-чекер этого не покажет. Вы можете быть чисты во всех DNSBL и всё равно уходить в Junk на Outlook, потому что Microsoft ведёт собственную, приватную оценку ваших IP. И единственный способ увидеть эту оценку изнутри — два бесплатных инструмента, которые Microsoft отдаёт отправителям: SNDS и JMRP. Никакой другой крупный провайдер не даёт такого прямого рентгена своей фильтрации. Беда в том, что большинство администраторов либо о них не знают, либо регистрируются один раз и больше никогда не заглядывают.
Два разных инструмента, которые все путают
SNDS и JMRP живут на одном портале postmaster.live.com, регистрируются раздельно и решают совершенно разные задачи. Их постоянно смешивают в кучу — зря.
SNDS (Smart Network Data Services) — это агрегированная телеметрия по вашим IP. Microsoft раз в сутки отдаёт сводку: сколько было RCPT- и DATA-команд, сколько получателей, какая доля жалоб (полосами), попадали ли вы в спам-ловушки и какого цвета сейчас фильтр для этого IP. Это инструмент тренда и «здоровья» IP. SNDS не скажет, кто именно пожаловался — он скажет, что доля жалоб на вашем /24 за вчера перевалила через 0.1%.
JMRP (Junk Mail Reporting Program, он же FBL — Feedback Loop) — это поток отдельных жалоб. Как только пользователь Outlook нажимает «Это спам», Microsoft формирует ARF-письмо (Abuse Reporting Format) и присылает его вам почти в реальном времени. Это инструмент атрибуции: JMRP даёт «кто и на какое письмо» пожаловался, чтобы вы могли выпилить адрес из списка немедленно.
Ограничение, которое надо усвоить сразу: оба инструмента покрывают только потребительские домены Microsoft — outlook.com, hotmail.com, live.com, msn.com и старые passport-домены. Корпоративный Microsoft 365 / Exchange Online это НЕ покрывает. Для тенантов M365 нет ни SNDS, ни FBL — там репутация оценивается отдельно, и обратной связи такого уровня Microsoft не даёт. Если ваша боль в доставке на корпоративные ящики @company.com на M365 — SNDS вам не поможет, там другой разговор.
Предусловия, без которых заявку отклонят
SNDS не выдаст доступ IP, который выглядит как случайный спамерский хост. Прежде чем подавать заявку, приведите инфраструктуру в порядок:
Forward-confirmed PTR (rDNS) на каждом отправляющем IP.203.0.113.10 должен резолвиться в mail-out.evilmail.pro, а тот A-записью — обратно в этот же IP. Проверяется в одну строку: dig -x 203.0.113.10 +short и затем dig +short mail-out.evilmail.pro — должны сойтись.
Валидный SPF, DKIM-подпись на исходящих, DMARC-политика.
Живые почтовые ящики `postmaster@` и `abuse@` на домене — Microsoft (и не только) проверяет их наличие.
Право на IP-диапазон. Вы должны либо владеть /24 (запись в RIPE/ARIN на ваше юрлицо), либо уметь подтвердить контроль над диапазоном. SNDS проверяет это, отправляя подтверждение на административный контакт сети из whois.
Практический момент: заявку подают на весь `/24` одним запросом, а не по одному IP. Даже если вы сейчас шлёте только с двух адресов, регистрируйте весь блок — потом не придётся возвращаться.
Регистрация SNDS и получение доступа
Идём на postmaster.live.com, входим под Microsoft-аккаунтом, открываем раздел SNDS → Request Access. Вводим IP или CIDR (212.22.69.0/24), выбираем способ подтверждения. Обычно это письмо на административный контакт сети из whois.
Если вы арендуете IP у хостера и контакт в whois — не вы, а провайдер, вариантов два: попросить хостера переслать вам письмо-подтверждение либо запросить у него право авторизации через TXT-запись в DNS. Многие приличные хостеры делают это по тикету за час.
Активация занимает от нескольких часов до суток. После одобрения данные доступны двумя путями: через веб-интерфейс View Data (годится посмотреть глазами) и — что нам действительно нужно — через Automated Data Access.
Автоматизация: тянем CSV по ключу
Ручной заход на портал раз в неделю — это не мониторинг, это самообман. Включаем Automated Data Access, Microsoft генерирует GUID-ключ, и дальше два эндпоинта отдают CSV вообще без иной авторизации — только по ключу в URL:
https://postmaster.live.com/snds/data.aspx?key=GUID — суточная статистика по каждому IP;
https://postmaster.live.com/snds/ipstatus.aspx?key=GUID — список заблокированных IP (пустой ответ = ни один IP не заблокирован).
Заводим ежедневный cron, который складывает выгрузку в файл с датой:
Проверка блокировок и мгновенный алерт на RED — отдельным шагом:
bash
#!/usr/bin/env bash
set -euo pipefail
SNDS_KEY=$(cat /etc/snds/key)
CSV=/var/lib/snds/$(date +%F).csv
# 1) Заблокированные IP: непустой ответ = проблема
blocked=$(curl -fsS "https://postmaster.live.com/snds/ipstatus.aspx?key=$SNDS_KEY")
[ -n "$blocked" ] && notify "SNDS: IP заблокирован Microsoft: $blocked"
# 2) Красный фильтр в свежей выгрузке (Filter result = 7-я колонка, band = 8-я, traps = 11-я)
awk -F',' 'toupper($7)=="RED"{print $1" RED band="$8" traps="$11}' "$CSV" \
| while read -r line; do notify "SNDS RED: $line"; done
Ключ — это секрет. Любой, у кого он есть, видит вашу телеметрию без пароля. Держите его в secret-store (Vault, docker secret, права 600 на файл), не коммитьте в git и не пихайте в переменную окружения PM2-процесса, которую видно в pm2 env.
Читаем SNDS: что означает каждая колонка
Строка data.aspx CSV содержит эти поля по порядку: IP, начало и конец окна активности (ActivityStart / ActivityEnd), число RCPT-команд, число DATA-команд, число получателей (message recipients), Filter result, Complaint rate, период спам-ловушки (Trap message period start/end), Trap hits, Sample HELO и Sample MAIL FROM.
Три поля, на которые смотрят в первую очередь:
Filter result — цвет фильтра. GREEN — норма, письма идут в Inbox. YELLOW — часть писем фильтруется в Junk. RED — большинство уходит в Junk или блокируется. Это агрегат по вашему поведению за окно.
Complaint rate — доля жалоб, и вот здесь важная деталь: Microsoft не отдаёт точное число. Только полосы: < 0.1%, 0.1% to < 1%, 1% to < 2% и так далее. Ваша красная линия — 0.1%. Всё, что попадает в полосу 0.1% to < 1% и выше, — это уже риск Junk-фильтрации. Для сравнения: у большинства FBL-провайдеров порог тревоги — те же 0.1%, так что цифра универсальна. Если ваш IP переполз из < 0.1% в следующую полосу — это событие для алерта, не для «посмотрим на следующей неделе».
Trap hits — попадания в спам-ловушки Microsoft. Любое значение > 0 — почти всегда индикатор старых или покупных списков: ловушка — это адрес, который никогда никому не давал согласия, значит вы шлёте туда, куда не должны. Реагировать надо сразу: искать, откуда в базе взялся этот сегмент.
Отдельно про warmup: новый холодный `/24` в SNDS сначала пустой. Данные появляются только после того, как IP наберёт объём — Microsoft не показывает статистику по адресам, с которых почти ничего не шло. Так что не пугайтесь пустого CSV на свежем блоке, это нормально.
JMRP: жалобы как поток ARF
JMRP регистрируется отдельно, на том же портале, на те же IP. Ключевой параметр — mailbox для доставки отчётов. Заводите под это отдельный ящик на отдельном поддомене, не на том домене, с которого рассылаете. Причина простая: поток ARF бывает плотным, и мешать его с рабочей почтой postmaster — плохая идея. Условно [email protected].
Каждая жалоба приходит письмом в формате ARF (RFC 5965): MIME-структура с частью message/feedback-report (машиночитаемые метаданные — тип abuse, source-IP, дата) и вложенным message/rfc822 — оригиналом вашего письма.
Здесь у Microsoft-FBL есть противная особенность: они часто вырезают или редактируют заголовки `To` / `Original-Rcpt-To` в возвращаемой копии, чтобы не раскрывать адрес жалобщика. То есть вы получаете жалобу, но по стандартным полям не понимаете, кто именно пожаловался и на какую рассылку. Решение — не полагаться на To, а вшивать в каждое письмо собственный заголовок для атрибуции: X-EM-Campaign и X-EM-Recipient-Hash (или VERP в конверте, или уникальный одноразовый токен в List-Unsubscribe). Этот заголовок уезжает вместе с телом письма и возвращается в ARF нетронутым.
Минимальный парсер, вытаскивающий свой заголовок из вложенного оригинала:
python
import email, sys
from email import policy
msg = email.message_from_binary_file(sys.stdin.buffer, policy=policy.default)
for part in msg.walk():
if part.get_content_type() == "message/rfc822":
original = part.get_payload(0) # вложенное письмо
camp = original["X-EM-Campaign"]
rcpt = original["X-EM-Recipient-Hash"]
print(f"complaint campaign={camp} recipient={rcpt}")
suppress(rcpt) # мгновенный unsubscribe
Дальше — прямая дорога: suppress() кладёт адрес в suppression-list, и на этот hash вы больше никогда не шлёте. Жалоба, обработанная за минуты, стоит на порядок меньше, чем та же жалоба, докатившаяся до полосы 0.1% в SNDS через сутки.
Как связать SNDS и JMRP на практике
Инструменты дополняют друг друга: SNDS даёт тренд (полоса жалоб растёт, IP пожелтел), JMRP даёт точечную атрибуцию (кто и на что). Рабочий цикл:
1.SNDS-алерт — фильтр стал YELLOW или complaint band перевалил за 0.1%.
2.Открываем JMRP за тот же суточный период, группируем жалобы по X-EM-Campaign.
3.Почти всегда всплывает одна проблемная кампания или сегмент — старый импорт, реактивированная база, ошибка в сегментации.
4.Чистим список, тормозим рассылку на этот сегмент, проверяем trap hits.
5.Ждём восстановления цвета. Оно не мгновенное — обычно нужно несколько суток чистого трафика, чтобы Microsoft переоценил IP обратно в GREEN. Резких движений в этот период не делаем.
Чеклист внедрения
Forward-confirmed PTR на каждом отправляющем IP (dig -x ↔ dig +short сходятся).
SPF + DKIM + DMARC настроены и проходят.
Заявка в SNDS подана на весь `/24`, не по одному IP.
Включён Automated Data Access, GUID-ключ лежит в secret-store с правами 600, не в git.
Cron ежедневно тянет data.aspx и ipstatus.aspx, складывает CSV с датой.
Алерт срабатывает на Filter result = REDи на complaint band ≥ 0.1%.
JMRP зарегистрирован, ARF-отчёты идут на отдельный ящик/поддомен.
В каждом письме есть собственный tracking-заголовок (X-EM-Campaign / X-EM-Recipient-Hash) для атрибуции жалоб.
ARF-парсер делает авто-suppress по каждой жалобе в минуты.
Ревью trap hits — раз в неделю, любой ненулевой хит расследуется.
Оба инструмента бесплатны и почти наверняка уже доступны на вашем /24 — вопрос только в том, настроен ли алерт на RED. Если у вас нет графика complaint rate за последние 30 дней и уведомления на красный фильтр, о проблемах с доставкой в Outlook вы узнаёте последним — от клиентов.
