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

Проверка почтовой аутентификации — это артефакты, не скрин «у нас галочка в мастере». Для contoso.example снимите: (1) MX, (2) единственный SPF TXT, (3) CNAME selector1/selector2._domainkey, (4) TXT _dmarc, (5) сырые заголовки контрольного письма из Outlook/OWA с Authentication-Results и DKIM-Signature. Команды: nslookup / Resolve-DnsName. Интерпретация fail — в статьях SPF, DKIM, DMARC. Онлайн-сканеры можно как второе мнение, не как единственное: они не видят ваш split-DNS и не заменяют заголовок живого письма.

Не меняйте DNS, пока не сохранили текущий вывод в тикет.

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

Задача «как проверить» возникает, когда:

  • готовятся к p=reject;
  • спор «хостер сказал SPF ок», а Gmail fail;
  • после миграции на Microsoft 365 нет чеклиста.

Это не замена Message Trace при пропаже письма — трейс про доставку, DNS про подпись. См. недоставка и спам.

Возможные причины расхождения «вроде настроено»

  1. Кэш TTL, смотрели слишком рано.
  2. Два SPF.
  3. DKIM CNAME с опечаткой дефисов.
  4. Письмо шло не из EO (сканер) — DNS EO идеален, заголовок fail.
  5. Сканер смотрит apex, From поддомена.
  6. _dmarc с синтаксической ошибкой (p= без v=DMARC1).

Диагностика

Рабочий каталог тикета, плейсхолдеры contoso.example, contoso.onmicrosoft.com, ivan.petrov@contoso.example.

1. MX (контекст)

Resolve-DnsName contoso.example -Type MX | Format-Table Name, NameExchange, Priority
nslookup -type=MX contoso.example

Ожидание для EO: contoso-example.mail.protection.outlook.com. MX не SPF, но без понимания контура дальше бессмысленно.

2. SPF

Resolve-DnsName contoso.example -Type TXT |
  ForEach-Object { $_.Strings -join '' } |
  Where-Object { $_ -like 'v=spf1*' }
nslookup -type=TXT contoso.example

Чеклист: ровно одна строка v=spf1; есть include:spf.protection.outlook.com если шлёте из EO; нет +all; примерно укладываетесь в 10 lookups (считать include). Сохраните сырой вывод.

3. DKIM

Имена CNAME возьмите из Get-DkimSigningConfig или портала Defender:

Connect-ExchangeOnline -UserPrincipalName admin@contoso.example
Get-DkimSigningConfig -Identity contoso.example |
  Format-List Enabled, Selector1CNAME, Selector2CNAME
Resolve-DnsName selector1._domainkey.contoso.example -Type CNAME
Resolve-DnsName selector2._domainkey.contoso.example -Type CNAME
nslookup -type=CNAME selector1._domainkey.contoso.example
nslookup -type=CNAME selector2._domainkey.contoso.example

Цель CNAME должна отвечать ключом (TXT на стороне Microsoft). Enabled True только после живого DNS.

4. DMARC

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

Разбор: v=DMARC1, p=, rua=, опционально sp=, pct=, adkim/aspf. Один TXT. rua на ящик, который вы читаете.

5. Живое письмо

Отправьте с ivan.petrov@contoso.example (OWA) на ящик вне тенанта, которым владеете. В Outlook: Файл → Свойства → Заголовки / View source. Ищите:

Authentication-Results: ... spf=pass ... dkim=pass header.d=contoso.example ... dmarc=pass
DKIM-Signature: v=1; a=rsa-sha256; s=selector1; d=contoso.example; ...
Return-Path: ...
From: Ivan Petrov <ivan.petrov@contoso.example>

Таблица интерпретации:

SPFDKIMDMARCВывод
pass alignedpass alignedpassкомплект ок для этого потока
pass чужой domainnonefailESP без вашего DKIM
failpass d=contosopassSPF дыра, DMARC спас DKIM
permerror*fail/noneчинить SPF синтаксис/lookups

Message Trace не содержит эти строки — заголовок обязателен.

Get-MessageTrace -SenderAddress ivan.petrov@contoso.example `
  -StartDate (Get-Date).AddHours(-2) -EndDate (Get-Date)

Трейс только подтверждает, что письмо вышло.

Решение

Это статья проверки: «решение» = собрать пакет и передать в работу узким статьям.

  1. Если SPF ≠ 1 запись / lookups — статья SPF.
  2. Если CNAME/Enabled — статья DKIM.
  3. Если p=reject режет неучтённых — статья DMARC.
  4. Если DNS ок, заголовок fail — искать другой отправитель (МФУ, сайт), не «ещё раз нажать Publish в мастере».
  5. Если DNS ок, заголовок pass, Junk — репутация/контент, статья спам.

Для тенанта contoso.onmicrosoft.com отдельная проверка: письмо с ivan.petrov@contoso.example (кастомный From) vs тестовое с user@contoso.onmicrosoft.com. Второе не доказывает SPF вашей зоны. Всегда тестируйте тот From, который видит контрагент.

Сканер с From: ivan.petrov@contoso.example через порт 25 офиса: DNS может быть идеальным для EO, заголовок spf=fail с IP NAT. Это не «сломанный чеклист», а неучтённый поток — его чинят relay/коннектор, не второй TXT.

Сохраняйте .eml в заявке, не скрин Gmail. Пересланное письмо ломает DKIM: просите «переслать как вложение». Публичный резолвер:

nslookup -type=TXT contoso.example 1.1.1.1
nslookup -type=CNAME selector1._domainkey.contoso.example 1.1.1.1

Если 1.1.1.1 видит новую запись, а DC — старую, split-DNS. Правьте зону на DC, не «подождём TTL интернета».

Откат DNS: вернуть сохранённые TXT/CNAME из тикета, TTL.

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

Пакет в тикете:

  • timestamp UTC;
  • вывод Resolve-DnsName MX/TXT/CNAME/DMARC с публичного DNS;
  • Get-DkimSigningConfig;
  • вложение .eml или полные заголовки;
  • для каждого класса отправителей (OWA, CRM, сканер) своё Authentication-Results.

Повтор через 2×TTL после правок.

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

  • Сканер в интернете pass, заголовок fail: письмо не то (пересланное ломает DKIM) — просите оригинал Forward as attachment.
  • IPv6 vs IPv4 SPF: редко, но ip4 без ip6 при исходящем v6. EO обычно закрыт include Microsoft.
  • DNSSEC SERVFAIL на _dmarc: чинить цепочку, не удалять DNSSEC «навсегда».
  • Хостер GUI показывает SPF, nslookup нет: не опубликовали, или другая зона (contoso.example vs www).

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

  • Чеклист подготовки домена включает этот же набор.
  • Контрольное письмо раз в квартал, архив заголовков.
  • Запрет менять TXT без тикета и снимка.
  • Инвентарь отправителей рядом с SPF.

FAQ

Обязательно ли MXToolbox?

Нет. nslookup и заголовок достаточны. Сканер — опция, данные могут отличаться из-за anycast/кэша.

Где в новом Outlook заголовки?

Через веб OWA «View message details» / классический Outlook Properties. Если UI спрятал — скачайте .eml.

SPF pass в DNS-чекере, в письме fail

Другой IP отправителя, не тот, что в include. DNS «валиден» ≠ этот поток покрыт.

Нужно ли проверять contoso.onmicrosoft.com?

Кастомный From проверяется в зоне From. onmicrosoft имеет свои записи Microsoft; ваши CNAME указывают туда для DKIM.

Можно ли доверять только порталу «DKIM Enabled»?

Нет. Enabled без публичного CNAME = ложное чувство. Всегда Resolve-DnsName.

Что писать в rua?

Ящик, который видят админы почты, не общая «info@». Объём XML может быть большим.