AUT-0300· Безпека та відповідність
Контроль автентифікації пошти корпоративного домену
Звіти перевірок пошти звіряють із дозволеними сервісами надсилання перед погодженим посиленням політики домену.
Чернетка · Оцінка потребує перевірки
01 / Проблема
Компанія посилила захист домену, не перевіривши сервіс рахунків або розсилок, і почала блокувати власні листи.
02 / Результат
Домен має пояснений перелік сервісів надсилання, результати перевірок і погоджене рішення щодо політики з перевіреним впливом на власну пошту.
03 / Процес
ТригерОтримано нові звіти перевірок пошти, підключено сервіс надсилання або запропоновано змінити політику домену.
Зафіксувати домен, редакцію поштової політики й перелік дозволених сервісів із відповідальними; DMARC є механізмом перевірки домену відправника та звітності.
Отримати доступні агреговані звіти за погоджений період; записати джерело й ID, не враховуючи один звіт повторно.
Зіставити джерела надсилання з дозволеним переліком і фактичними результатами SPF, DKIM та DMARC; успішний окремий тест не вважати автоматично успішним DMARC.
Невідомі джерела передати фахівцю на класифікацію; збій перевірки не доводить атаки без розгляду контексту.
Для дозволеного сервісу з помилками погодити виправлення налаштувань та перевірити наступні листи й звіти; не видаляти сервіс із дозволених лише за відсотком помилок.
Підготувати рішення про збереження або посилення політики з охопленням поштових потоків, ризиками й планом відновлення; неперевірені потоки лишити явними прогалинами.
Зміну DNS або налаштувань виконує уповноважений фахівець за погодженим порядком; статус погоджено не підтверджує опублікований запис.
Перевірити чинний запис і доступні результати після зміни; підтвердити власні сервіси надсилання, зберегти відкриті проблеми та історію рішення.
04 / Реалізація1 варіант
Приклад · Розбір звітів і погодження поштової політики
Корпоративна пошта проходить DMARC, але сервіс рахунків — ні. Попри високий загальний відсоток успіху, політику блокування не посилили до перевірки цього потоку. Власник сервісу виправив налаштування; нові результати перевірили окремо. Невідоме джерело отримало розгляд фахівця, а не автоматичний висновок про атаку.
Спосіб реалізації
- Проєктна модель PlanFix: домен, редакція політики, дозволені сервіси, агреговані результати, задачі виправлення й рішення; приймання звітів та технічні зміни проєктують окремо.
Що потрібно для реалізації
- Є власник домену, перелік дозволених поштових сервісів і доступ до звітів.
- Погоджено період перевірки, правила змін та відповідальних за сервіси.
- Є доступ до результатів перевірки та власники сервісів.
Обмеження
- Не гарантує доставку до вхідних повідомлень, прочитання листів або відсутність фішингу.
- Звіти не є повним реєстром усіх листів; відсутність звіту не доводить відсутності надсилання.
- Не задає універсального строку спостереження, відсотка застосування або автоматичного переходу до блокування.
- Агрегований звіт не замінює перевірку конкретного збою доставки; нові сервіси потребують повторного перегляду охоплення.
- Приватні ключі DKIM, паролі та вміст листів не зберігають у загальних задачах.
- Години попередні; міграція пошти, керування репутацією розсилок і вартість зовнішнього аналізатора не включені.
- Не змінює DNS автоматично за агрегованим показником.
- Не прирівнює успішну автентифікацію до доставки листа.
Що потрібно уточнити (2)
- Чи потрібно автоматично отримувати й розбирати агреговані звіти?
Перевірте дозволене джерело, формати, ID та обмеження доступу; відсутні звіти лишаються прогалиною.
- Чи потрібно окремо контролювати кілька зовнішніх сервісів надсилання?
Для кожного сервісу визначте власника, тестові потоки й докази виправлення.