DMARC-запис: як налаштувати DMARC покроково (p=none → quarantine → reject)

DMARC-запис — один рядок у DNS, але саме він вирішує, що станеться з листом, який видає себе за ваш домен і не пройшов перевірку. Налаштуєте недбало — або нічого не захистите, або заблокуєте власні рахунки клієнтам. Нижче — усі теги, готові приклади й план переходу від p=none до p=reject.

Якщо SPF, DKIM і вирівнювання для вас нові поняття, почніть зі статті SPF, DKIM і DMARC: що це і як налаштувати — DMARC спирається на обидві перевірки.

Де розміщено DMARC-запис

DMARC — TXT-запис на піддомені _dmarc того домену, що стоїть в адресі «Від кого»:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

На одному імені має бути лише один DMARC-запис: якщо отримувач знайде два, він проігнорує DMARC для домену. Піддомен без власного запису успадковує запис основного домену (example.com).

Теги DMARC

М'яке і суворе вирівнювання. За м'якого домени мають лише мати спільний основний домен: підпис із d=news.example.com збігається з «Від кого» example.com. Суворе вимагає точного збігу. Майже всім підходить м'яке.

Приклади DMARC-записів

Лише спостереження — безпечний старт:

v=DMARC1; p=none; rua=mailto:[email protected]

Карантин для чверті листів, що не пройшли:

v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]

Повний захист разом із піддоменами:

v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]

Домен, який узагалі не надсилає пошту (разом із v=spf1 -all):

v=DMARC1; p=reject; sp=reject

Після публікації перевірте запис у перевірці DMARC: вона покаже помилки синтаксису і те, як прочитано кожен тег.

Як налаштувати DMARC покроково

1. Спершу переконайтеся, що працюють SPF і DKIM. Перевірте їх у перевірці SPF та перевірці DKIM. Без них DMARC збиратиме лише звіти про провали.
2. Оберіть адресу для звітів. Зведені звіти — XML-файли, в активного домену їх десятки на день. Заведіть окрему скриньку або підключіть сервіс розбору звітів, а не особисту пошту.
3. Опублікуйте p=none з rua у панелі DNS-провайдера: ім'я _dmarc, тип TXT.
4. Збирайте звіти 2–4 тижні, щоб проявилися відправники, які пишуть раз на тиждень чи місяць: рахунки, зарплатні відомості, розсилки.
5. Виправте кожне справжнє джерело, що не проходить: увімкніть у ньому DKIM із вашим доменом або додайте до SPF із вирівняним Return-Path.
6. Переходьте на p=quarantine, за бажання з pct=25, далі 50 і 100, перевіряючи звіти після кожного кроку.
7. Переходьте на p=reject, коли карантин кілька тижнів працює без несподіванок.

Як читати зведені звіти

Кожен звіт — від одного поштового сервісу за один період, зазвичай добу. Усередині рядки на кшталт цих (спрощено):

• Обидві перевірки вирівняні — ваш основний сервер, усе гаразд.
• SPF пройшов, але не вирівняний, DKIM провалено — типовий сторонній сервіс зі своїм Return-Path і без вашого DKIM-ключа. З'ясуйте, чий це IP, і ввімкніть там DKIM із вашим доменом. За p=reject ці листи було б заблоковано.
• Усе провалено з незнайомого IP — забута система або підробка. Ловити підробки DMARC і створено, але спершу переконайтеся, що це не ваш забутий сервер.

Крім рядків, кожен звіт має шапку: хто його надіслав (Google, Yahoo, Microsoft та інші), за який період і яку політику сервіс побачив у вашому DNS. Останнє — корисна звірка: якщо через тиждень після публікації quarantine у звіті досі p=none, отримувач бачить старий або задвоєний запис. Звіти приходять стиснутими вкладеннями (zip або gzip), по одному від сервісу на добу, тож в активного домену швидко набираються сотні файлів.

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

Політика для піддоменів

Тег sp задає політику для піддоменів без власного DMARC-запису. Два типові варіанти:

• p=reject; sp=reject — усе закрито, коли ви впевнені в налаштуванні.
• p=reject; sp=none — основний домен захищено, піддомени ще перевіряються. Не залишайте так надовго: підробляти billing.example.com зловмисникам анітрохи не гірше.

Піддомен, що сам надсилає пошту, наприклад news.example.com, може мати власний запис _dmarc.news.example.com — він важливіший за sp.

Звіти на адресу іншого домену

Якщо адреса в rua належить іншому домену — зазвичай це сервіс розбору звітів, — цей домен має підтвердити, що погоджується їх отримувати. Інакше поштові сервіси пропустять таку адресу. Дозвіл — TXT-запис на боці отримувача звітів:

example.com._report._dmarc.reports-provider.net.  TXT  "v=DMARC1"

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

Часті помилки в DMARC-записі

• Неправильне ім'я. Запис ставлять на _dmarc, а не на сам домен. Якщо DNS-панель сама дописує домен, вводьте лише _dmarc, інакше вийде _dmarc.example.com.example.com.
• v=DMARC1 не першим тегом або з помилкою, наприклад v=DMARC 1 із пробілом. Отримувачі вважають, що запису немає.
• Немає mailto: у rua. Значення має бути адресою-URI: rua=mailto:[email protected], а не просто скринькою.
• Два DMARC-записи, що лишилися після зміни сервісу звітів. Залиште один, а кілька адрес перелічіть у rua через кому.
• Політику посилили, а звіти ніхто не читає. Запис із p=reject і переповненою чи покинутою скринькою rua — отже, ви не помітите, коли новий сервіс почне провалювати перевірку.

Після кожної зміни дайте DNS оновитися (зазвичай від хвилин до кількох годин, залежно від TTL запису) і перевірте результат у перевірці DMARC. Перші зведені звіти зазвичай приходять протягом доби-двох: більшість поштових сервісів надсилає їх раз на день.

Що ламається за p=reject

• Списки розсилки, які додають підпис чи мітку в тему, ламають DKIM, а IP сервера списку ламає SPF. Багато списків тепер переписують адресу «Від кого»; допомагає й ARC — механізм, що зберігає результати перевірок під час пересилання.
• Просте пересилання ламає SPF, але зберігає DKIM, якщо лист не змінено. Ще одна причина зробити DKIM основною вирівняною перевіркою.
• Форми на сайті, що надсилають лист «від відвідувача» або від вашого домену через пошту хостингу. Надсилайте їх через сервіс з автентифікацією вашого домену.

Перед такими змінами перевірте й MX-записи в перевірці MX: звіти приходять поштою, і їм треба кудись доходити.