Посібник з розгортання DMARC у Microsoft 365: від none до reject без збою пошти

By Mirko Peters · 2026-10-21

Дізнайтеся, як безпечно розгорнути DMARC у Microsoft 365 від моніторингу до суворого відхилення, не порушивши легітимну доставку електронної пошти вашої організації.

Automatically translated with AI from the original post. Read the English original

Розгортання протоколів автентифікації електронної пошти в клієнті Microsoft 365 може нагадувати знешкодження бомби, якщо робити це не в тому порядку. Цей покроковий посібник з розгортання DMARC у Microsoft 365 допоможе ІТ-адміністраторам безпечно перейти від початкового моніторингу до суворої політики відхилення, не втративши випадково легітимні рахунки, маркетингові кампанії чи автоматичні сповіщення.

Головне

• Завжди розгортайте автентифікацію електронної пошти у правильному порядку: спочатку SPF, потім DKIM і наприкінці DMARC.
• Почніть з політики DMARC p=none, щоб відстежувати трафік і визначити всі легітимні та несанкціоновані служби надсилання.
• Уникайте перевищення ліміту з 10 пошукових запитів для SPF, ретельно перевіряючи сторонні служби, зокрема маркетингові платформи та служби підтримки.
• Поступово переходьте через карантин і відсоткові налаштування, перш ніж застосовувати сувору політику reject.
• Налаштуйте сукупні звіти так, щоб вони надходили на спільну поштову скриньку, а не у вхідні окремої людини, щоб забезпечити постійну видимість.

Золоте правило порядку розгортання

Якщо під час проєкту зміцнення безпеки ви запам'ятаєте лише один принцип, зробіть ним порядок розгортання. Організації часто стикаються з проблемами, бо впроваджують стандарти у зворотному порядку. Оскільки система електронної пошти спирається на застарілі протоколи, як-от SMTP, створені на основі довіри, а не перевірки, запровадження суворої політики примусового застосування ще до картографування інфраструктури призведе до того, що легітимна пошта перестане доставлятися.

Правильна послідовність створює страхувальну сітку на кожному етапі. Спочатку потрібно скласти список гостей, накласти захисні печатки, і лише потім додавати арбітра, який усе пов'язує. Пропуск кроків залишає вас у невіданні щодо власних потоків пошти, а невідомість — найшвидший шлях до того, що зовнішні отримувачі блокуватимуть листи вашої компанії.

Крок перший: встановлення SPF і небезпека обмежень на пошукові запити

Ваш перший крок — опублікувати запис Sender Policy Framework (SPF) в корені вашого домену. Уявіть це як список гостей біля входу в ексклюзивний клуб. Він прямо вказує, які сервери мають право надсилати листи з вашим доменним іменем.

Під час написання початкового запису SPF для Microsoft 365 завершіть його м'яким відхиленням (~all), а не жорстким (-all). Це наказує серверам отримувачів ставитися до неавторизованої пошти з підозрою, а не відхиляти її одразу. Такий пільговий період дає змогу виявити служби, які ви могли пропустити.

Уникнення пастки десяти пошукових запитів

Major pitfall в управлінні SPF — суворий ліміт у 10 пошукових запитів. Щоразу, коли сервер отримувача обробляє ваш запис SPF і натрапляє на механізм, який потребує окремого DNS-запиту, — наприклад, стороння платформа маркетингової автоматизації, служба підтримки клієнтів чи обробник зарплатних відомостей, — це з вашого бюджету списується один запит.

Якщо ваша організація додає забагато зовнішніх служб, загальна кількість запитів перевищить десять, і вся перевірка SPF завершиться помилкою. Дослідження мільйонів доменів показують, що дивовижно великий відсоток компаній ненароком ламає власний захист електронної пошти саме так. Регулярно перевіряйте свої служби, щоб тримати відбиток SPF компактним.

Крок другий: активація DKIM у Microsoft 365

Після того як список розсилки опубліковано, потрібен спосіб переконатися, що повідомлення не змінюються під час передачі. DomainKeys Identified Mail (DKIM) працює як цифрова сургучна печатка, що ставиться на кожне вихідне повідомлення. Вона містить криптографічний підпис, який охоплює рядок теми, текст листа та видиму адресу відправника (From).

У Microsoft 365 листи, надіслані з вашого домену за замовчуванням onmicrosoft.com, підписуються автоматично. Однак ваш власний корпоративний домен залишається без підпису, доки ви явно не налаштуєте DKIM у центрі адміністрування. Щоб зробити це правильно, потрібно створити в публічному DNS два селектори (selector1 і selector2). Така конфігурація з двома вказівниками дає змогу Microsoft пізніше без простою ротувати ключі підпису.

Google та інші великі провайдери рекомендують дати SPF і DKIM стабільно працювати щонайменше 48 годин, перш ніж змінювати DMARC. Цей період налаштування гарантує, що базові перевірки працюють належним чином, перш ніж на сцену вийде арбітр.

Крок третій: розгортання DMARC у режимі моніторингу

Domain-Based Message Authentication, Reporting, and Conformance (DMARC) відіграє роль арбітра. Він не проводить власної перевірки вмісту повідомлення, а дивиться на результати перевірок SPF і DKIM та з’ясовує, чи збігаються вони з видимим доменом у рядку From.

Коли ви вперше публікуєте TXT-запис DMARC для _dmarc.yourdomain.com, параметр політики має бути суворо в режимі моніторингу: p=none. Якщо читати запис зліва направо, він повідомляє серверам-отримувачам: «Це запис DMARC, поки що не вживайте жодних заходів примусового виконання, якщо перевірки не пройдені, і надсилайте сукупні звіти на цю адресу електронної пошти».

Ніколи не пропускайте цей етап моніторингу. Щоденні сукупні звіти (RUA) у форматі XML виявлять кожну службу, легітимну чи зловмисну, яка надсилає пошту від імені вашого домену. Надсилайте ці звіти на контрольовану спільну поштову скриньку, а не на особисту скриньку співробітника, щоб вони не загубилися під час відпусток.

Крок четвертий: перехід від карантину до відхилення

Коли щотижневі перевірки покажуть, що всі легітимні потоки пошти чисто проходять вирівнювання, настає час закрутити гайки. Параметр політики DMARC проходить три окремі операційні стани:

• None (p=none): Сторожова вежа. Чисто спостережний режим, який використовується для аудиту та збору даних сукупних звітів.
• Quarantine (p=quarantine): Попереджувальна мітка. Наказує серверам-отримувачам позначати підозрілі або непройдені листи, як правило, одразу переміщуючи їх до папки «Спам» або «Нežелана пошта» отримувача.
• Reject (p=reject): Замкнені двері. Наказує отримувачам повністю відкидати неавтентифіковані або підроблені повідомлення, перш ніж вони взагалі потраплять до поштової скриньки.

Щоб зробити цей перехід максимально плавним, використовуйте відсоткові регулятори DMARC (pct=). Ви можете застосовувати карантин або відхилення до невеликої частки непройдених листів, наприклад 10%, потім 25%, потім 50%, перш ніж перейти до повного режиму. Таке поетапне масштабування запобігає раптовим збоям у роботі бізнесу, якщо про якийсь інструмент розсилки новин ви забули.

Висновок

Захист поштової інфраструктури організації від Business Email Compromise (BEC) і підміни домену потребує терпіння та методичної стратегії впровадження. Налаштувавши SPF, увімкнувши DKIM і поступово посилюючи політику DMARC від спостереження до суворого відхилення, ви захищаєте репутацію компанії та гарантуєте, що справжні повідомлення завжди доходять до адресатів.

Щоб глибше розібратися в механізмах протоколів автентифікації електронної пошти, послухайте повний епізод з експертними висновками, практичними архітектурними стратегіями та інструкціями для вашого клієнта Microsoft 365.

Поширені запитання

Як довго в Microsoft 365 слід тримати політику DMARC у режимі none?

Google і фахівці з безпеки електронної пошти рекомендують тримати політику DMARC у режимі p=none щонайменше один тиждень. Цей період дає змогу зібрати повні сукупні звіти, що охоплюють щотижневі та циклічні потоки ділової пошти.

Чому потрібно увімкнути DKIM перед увімкненням DMARC?

DKIM криптографічно підписує повідомлення, і цей підпис передається разом із ним, зберігаючись навіть у сценаріях пересилання, які часто ламають SPF. Коли SPF і DKIM налаштовані правильно, вирівнювання DMARC проходить надійно.

Чи надсилає Microsoft 365 судові (forensic) звіти DMARC?

Ні. Хоча Microsoft 365 надсилатиме сукупні звіти (RUA) на вказану вами адресу для звітів, він не формуватиме й не надсилатиме судові звіти (RUF), навіть якщо їх запитано у вашому записі DMARC.

Що станеться, якщо я опублікую два записи DMARC для мого власного домену?

Публікація кількох записів DMARC збиває з пантелику поштові сервери отримувачів, які в результаті взагалі не застосовують жодної політики, і всі ваші зусилля щодо безпеки повністю нівелюються. Завжди стежте за тим, щоб для вашого домену існував рівно один TXT-запис DMARC.