SPF, DKIM, DMARC в Office 365: покрокове налаштування для B2B-розсилок

Якщо компанія готується запускати cold email по базі конкретних контактів, домен у Microsoft 365 має пройти автентифікацію ще до першого листа. Без коректних SPF, DKIM та DMARC records поштові сервіси на кшталт Gmail та Outlook сприймають розсилку як підозрілу, навіть якщо текст листа бездоганний. Ця інструкція описує, як налаштувати spf dkim dmarc dns records в Office 365 крок за кроком, без зайвої теорії.

Чому SPF, DKIM і DMARC критичні саме для холодних розсилок

Коли менеджер з продажу пише персональний лист конкретній людині в конкретній компанії, обсяги невеликі — кілька десятків листів на день. Але поштові провайдери оцінюють не лише обсяг, а й репутацію та автентифікацію відправника. Домен без SPF, DKIM і DMARC виглядає для Gmail і Outlook так само, як лист із незнайомої адреси без цифрового підпису — навіть якщо зміст абсолютно легітимний.

LDM послідовно виступає проти будь-яких прийомів «обходу спам-фільтрів». Мета налаштування цих трьох записів протилежна — зробити так, щоб легітимний бізнес-лист виглядав саме тим, чим він є: повідомленням від реальної компанії з реальним доменом, а не анонімним розсиланням.

Крок 1: налаштування SPF record в Office 365

SPF (Sender Policy Framework) — TXT-запис у DNS, який перелічує сервери, яким дозволено надсилати пошту від імені вашого домену. Для Microsoft 365 базовий запис виглядає так: v=spf1 include:spf.protection.outlook.com -all.

Якщо домен уже використовує сторонні сервіси для розсилок (наприклад, платформу для холодних кампаній чи CRM з функцією надсилання листів), їхні include-рядки потрібно додати в той самий SPF record — DNS дозволяє лише один запис SPF на домен. Поширена помилка — створити другий TXT-запис замість того, щоб об'єднати include в один рядок; це ламає перевірку повністю.

• Перевірте, чи вже є SPF record через nslookup -type=TXT ваш-домен.com
• Об'єднайте всі include (Office 365, платформа розсилок, CRM) в один запис
• Слідкуйте за лімітом у 10 DNS-lookup — перевищення робить SPF недійсним
• Завершіть запис на -all (hard fail), а не ~all, коли впевнені у повноті списку

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

На відміну від SPF, DKIM у Microsoft 365 за замовчуванням підписує листи через домен onmicrosoft.com, а не через ваш кастомний домен. Щоб implement spf dkim and dmarc office 365 повністю, DKIM для власного домену треба увімкнути окремо в Microsoft Defender.

У Defender for Office 365 відкрийте розділ Email authentication settings → DKIM, оберіть потрібний домен. Система згенерує два CNAME-записи виду selector1._domainkey і selector2._domainkey. Додайте обидва в DNS-зону домену, після чого перемкніть тумблер Enable в самому Defender — CNAME-записи без активації тумблера DKIM не запрацюють.

Крок 3: DMARC — від моніторингу до захисту

DMARC record говорить поштовим серверам, що робити з листом, який не пройшов SPF або DKIM, і надсилає звіти на вказану адресу. Мінімальний старт: v=DMARC1; p=none; rua=mailto:dmarc-reports@vasha-kompaniya.com.

Політика p=none нічого не блокує — вона лише збирає дані про те, хто надсилає листи від імені домену. Це критично важливо перед стартом холодних B2B-кампаній: за 3–4 тижні звіти покажуть усі легітимні джерела пошти (включно з CRM, платформою розсилок, бухгалтерським сервісом), і лише після цього безпечно переходити на p=quarantine, а згодом на p=reject.

Типові помилки при налаштуванні в Office 365

Найчастіша проблема — використання одного домену і для внутрішньої корпоративної пошти, і для холодних розсилок. Якщо кампанія раптом отримає скарги чи потрапить у чорний список, постраждає репутація всього домену, включно з листуванням бухгалтерії та контрактами. Практика LDM — виносити холодні розсилки на окремий піддомен (наприклад, outreach.vasha-kompaniya.com) із власними SPF, DKIM і DMARC, які успадковують довіру основного домену, але ізольовані за ризиком.

Друга поширена помилка — забути про DKIM-тумблер у Defender після додавання CNAME-записів у DNS. Записи присутні, але автентифікація фактично не активна, поки адміністратор не підтвердив увімкнення вручну.

• Два SPF-записи замість одного об'єднаного — DNS-стандарт це не підтримує
• Перевищення 10 DNS-lookup через include ланцюжки сторонніх сервісів
• DKIM CNAME додано в DNS, але не увімкнено тумблер у Defender
• Одразу p=reject без періоду моніторингу p=none
• Використання основного корпоративного домену для холодних розсилок без піддомену

Чек-лист перед першою розсилкою

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

• SPF record об'єднаний в один рядок, завершується на -all
• DKIM активовано в Defender для кастомного домену (обидва селектори)
• DMARC запущено з p=none, звіти надходять на призначену поштову скриньку
• Piddomeн для холодних розсилок налаштований окремо від корпоративної пошти
• DNS-зміни перевірені через nslookup або mxtoolbox — записи резолвяться коректно

Питання й відповіді