Налаштування SPF, DKIM і DMARC у Microsoft 365

Microsoft 365 почне надсилати пошту від вашого домену одразу після підключення — але автентифікувати її так, як цього вимагає DMARC, він не буде, доки ви не зробите три речі вручну. І найчастіше все спотикається саме на DKIM: M365 підписує вашу пошту типово, просто не як ваш домен. У результаті налаштування виглядає завершеним і все одно провалює узгодження.

Нижче — точні записи в потрібному порядку і той крок у порталі, який справді вмикає DKIM.

Що Microsoft 365 автентифікує від початку

Коли ви додавали домен до Microsoft 365, ви створили MX-запис на Exchange Online Protection і, найімовірніше, запис SPF. Пошта пішла. Лишилися два розриви:

• DKIM для вашого домену. M365 підписує вихідну пошту автоматично, але ключем на домені вашого тенанта yourtenant.onmicrosoft.com. Для DMARC домен підпису має узгоджуватися з видимим From:, а onmicrosoft.com не узгоджується. Підписування власним доменом треба вмикати явно.
• Політика DMARC. M365 не публікує її за вас ніколи. Без неї отримувачі не мають інструкції на випадок провалу автентифікації.

Виправляється це трьома DNS-записами й одним перемикачем у порталі. Закладіть годину плюс час на поширення змін у DNS.

Крок 1 — SPF для Exchange Online

Опублікуйте на кореневому домені єдиний TXT-запис SPF, який авторизує поштові сервери Microsoft:

v=spf1 include:spf.protection.outlook.com -all

Два правила:

• Тільки один запис SPF. Якщо він у вас уже є для іншого відправника, додайте include:spf.protection.outlook.com до нього — і ніколи не публікуйте другий v=spf1.
• Стежте за лімітом у 10 DNS-запитів. Кожен include рахується. Якщо пошта йде через кілька сервісів, ліміт легко перевищити й знецінити SPF; безкоштовний генератор DMARC і перевірка SPF це підсвітять.

Ставте -all (жорсткий провал), коли впевнені, що всі відправники перелічені; ~all — безпечний проміжний варіант.

Крок 2 — увімкніть підписування DKIM для свого домену

Ось крок, який найлегше лишити напівзробленим. M365 використовує DKIM на основі CNAME: ви публікуєте два записи CNAME, що вказують на Microsoft, а Microsoft керує ключами за ними, включно з ротацією.

Опублікуйте ці два записи, підставивши свої GUID і тенант (GUID той самий, що й у вашому MX-записі):

selector1._domainkey   CNAME   selector1-<domainGUID>._domainkey.<tenant>.onmicrosoft.com
selector2._domainkey   CNAME   selector2-<domainGUID>._domainkey.<tenant>.onmicrosoft.com

Тепер увімкніть підписування:

1. Відкрийте портал Microsoft Defender (security.microsoft.com).
2. Перейдіть до Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM.
3. Виберіть свій домен і переведіть перемикач Sign messages for this domain with DKIM signatures у стан Enabled.

Пастка ось у чому: перемикач не спрацює, якщо обидва CNAME ще не опубліковані — ви отримаєте помилку CNAME record doesn't exist. Спершу записи, потім час на поширення DNS, і лише тоді вмикайте. Доки перемикач не переведено, ваша пошта підписується як onmicrosoft.com і провалює узгодження.

Крок 3 — опублікуйте DMARC

Додайте TXT-запис на хості _dmarc кореневого домену, почавши з режиму спостереження:

v=DMARC1; p=none; rua=mailto:reports@yourdomain.com

p=none нічого не змінює в доставці — він просить отримувачів надсилати зведені звіти, щоб ви побачили, хто шле пошту від вашого домену, ще до примусового застосування політики. В rua= вкажіть адресу або сервіс, який хтось справді читає.

Перевірте узгодження, перш ніж посилювати політику

Пройдений SPF або DKIM — це ще не пройдений DMARC: автентифікований домен має узгоджуватися з вашим From:. Щойно DKIM почне підписувати вашим доменом, пошта M365 узгодиться. А от сторонні відправники, що працюють через M365 або поруч із ним — CRM, сервіс підтримки, платформа розсилок, — зазвичай не узгодяться, доки ви не налаштуєте кожен окремо. Як побачити це у звітах, розібрано в матеріалі про зведені звіти DMARC.

Тож перш ніж закручувати гайки, стежте за звітами, доки кожне легітимне джерело не автентифікуватиметься й не узгоджуватиметься. Далі рухайтеся поетапно: p=none → p=quarantine → p=reject. Зроблено правильно — і день переходу до примусового застосування мине непомітно.

Граблі Microsoft 365

• DKIM вмикають, а CNAME немає. Перемикач видає помилку — спершу опублікуйте обидва записи, потім вмикайте.
• Пошта досі підписується як onmicrosoft.com. Означає, що DKIM для власного домену так і не увімкнули. Перевірте перемикач у Defender.
• Гібридна або локальна пошта. Якщо ви надсилаєте ще й з локальних серверів, додайте їхні IP-адреси до SPF: include Exchange Online їх не покриває.
• Сторонні відправники через M365. Сервіси, що шлють «від імені» вашого домену, потребують власного узгодження — налаштування M365 не автентифікує їх за вас.
• Поспішний перехід на p=reject. Без чистих звітів ви заблокуєте власну пошту. Право на примусове застосування треба заробити доказами.

Часті питання

Чи вмикає Microsoft 365 DKIM автоматично? Для вашого власного домену — ні. Microsoft 365 підписує вихідну пошту типовим ключем на домені *.onmicrosoft.com, а він не узгоджується з вашим справжнім доменом для DMARC. Потрібно увімкнути підписування DKIM для кожного власного домену в порталі Defender і опублікувати два записи CNAME.

Який запис SPF потрібен Microsoft 365? Додайте include:spf.protection.outlook.com до єдиного TXT-запису SPF вашого домену — наприклад, v=spf1 include:spf.protection.outlook.com -all. Якщо ви надсилаєте пошту й через інші сервіси, зведіть усі include в цей самий запис і не перевищуйте ліміт у 10 DNS-запитів.

---

Коли SPF, DKIM від власного домену й DMARC на місці, а звіти чисті, робота переходить у моніторинг: треба вчасно помітити наступний сервіс, який хтось під'єднає до M365, перш ніж він тихо провалить автентифікацію. Саме для цього й зроблено DDMARC — зрозумілі звіти замість сирого XML і сповіщення, щойно з'являється новий відправник.