Як перевести DMARC із p=none у p=quarantine
DMARC-запис у вас уже є і стоїть у режимі p=none, тож отримувачі шлють звіти, але нічого не блокують. Перехід на p=quarantine, це не правка одного рядка в DNS, а перевірка готовності: кожна система, яка шле листи від імені домену, спершу має проходити автентифікацію і вирівнювання, інакше першими під quarantine потраплять ваші ж рахунки. Запустіть перевірку пошти на цій сторінці, щоб побачити домен очима отримувачів, і далі йдіть за кроками нижче.
Перевірте свій сайт
-
Переконайтеся, що всі легітимні відправники автентифікуються
Сувора політика зачіпає лише ті листи, які не пройшли перевірку, тож список відправників має бути повним і чистим ще до зміни політики. Запустіть перевірку пошти на цій сторінці: вона показує MX, запис SPF, знайдені DKIM-селектори і поточну опубліковану політику DMARC. Якщо DKIM-селекторів не знайдено, зупиніться: ви посилите політику, маючи лише SPF, а SPF не переживає пересилання. Чекер перебирає поширені імена селекторів, тож нестандартний може не знайтися; звіряйтеся ще й зі сторінкою DKIM у кожного сервісу розсилки (пошта, CRM, виставлення рахунків, маркетинг, хелпдеск, моніторинг).
-
Читайте агреговані звіти достатньо довго
Два тижні даних rua показують щоденних відправників, але не квартальних. Виставлення рахунків, сезонні кампанії, річне повідомлення про продовження, хелпдеск, який пише лише коли відкривають тікет, у звітах зʼявляються пізно або не зʼявляються взагалі. Дочекайтеся щонайменше повного циклу виставлення рахунків, чотири-шість тижнів це розумний мінімум, і читайте звіти як список IP-джерел і доменів, якими вони автентифікуються, а не як загальний відсоток проходження.
-
Перевіряйте саме вирівнювання, а не факт проходження
DMARC не цікавить, що SPF або DKIM пройшли, його цікавить, чи збігається домен, який пройшов перевірку, з доменом у полі From. Лист може пройти SPF за власним службовим доменом сервісу розсилки і все одно не пройти DMARC. Мʼяке вирівнювання (за замовчуванням, adkim=r і aspf=r) приймає збіг на рівні організаційного домену, тож mail.yourdomain.com вирівнюється з yourdomain.com, а суворе (s) вимагає точного збігу. У звітах шукайте рядки, де SPF або DKIM = pass, а результат DMARC = fail: це і є неспівпадіння, і лагодять його на боці сервісу-відправника, задавши власний Return-Path у вашому домені або підписуючи DKIM із d=yourdomain.com.
-
Переконайтеся, що SPF не вийшов за ліміт 10 запитів
SPF дозволяє 10 DNS-запитів; понад це отримувач повертає PermError, і шлях SPF фактично зникає ще до того, як ви посилите політику. Перевірка на цій сторінці рахує, у скільки запитів обходиться ваш запис. Якщо показує 10 або більше, спершу виправте це: приберіть include сервісів, якими вже не користуєтеся, або замініть роздутий include на конкретні IP-адреси. Якщо число із запасом менше 10 і DKIM на місці, у вас працюють обидва шляхи автентифікації, можна рухатися далі.
-
Переходьте на quarantine з невеликим відсотком
Відредагуйте TXT-запис _dmarc: замініть p=none на p=quarantine, залиште rua і додайте pct=10, щоб політика застосовувалася приблизно до десятої частини листів, які не пройшли перевірку: v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@yourdomain.com. Дайте тиждень, потім піднімайте до 25, 50, 100, витримуючи повний цикл звітності на кожному рівні. Ставтеся до pct як до інструмента плавного переходу, а не постійного налаштування: оновлена специфікація DMARC прибирає цей тег, та й не кожен отримувач його враховує, тож заберіть pct, коли дійдете до повного quarantine.
-
Не вимикайте rua і стежте після кожного підвищення
Ніколи не прибирайте тег rua, поки посилюєте політику, це єдиний зворотний звʼязок. Після кожного кроку читайте нові звіти й шукайте легітимні джерела, які почали падати. Якщо таке зʼявилося, знизьте pct або поверніться до p=none, полагодьте автентифікацію чи вирівнювання цього відправника і продовжуйте. Визначтеся й із субдоменами: без тега sp вони успадковують вашу політику, і тимчасово додати sp=none, щоб вивести галасливий субдомен з-під суворої політики, цілком нормально.
Як перевірити результат
Прогоніть домен через перевірку пошти на цій сторінці ще раз. У рядку DMARC має бути нова політика (p=quarantine, з pct, якщо ви його залишили), SPF має лишатися валідним із кількістю запитів менше 10, а потрібні DKIM-селектори мають знаходитися. Якщо DMARC і далі показує p=none, або зміна TXT ще не розійшлася (зачекайте час TTL старого запису), або новий запис додали поруч зі старим: на _dmarc має бути рівно один DMARC-запис, а за двох отримувачі вважають, що придатної політики немає взагалі.
Порада: Пересланий лист майже завжди не проходить SPF, бо сервер пересилання відправляє його зі своєї IP-адреси, і саме тому крізь сувору політику лист проносить справний DKIM-підпис із вирівняним d=. Списки розсилки йдуть далі й переписують тему чи тіло, ламаючи ще й DKIM; більшість добре налаштованих списків обходять це, підставляючи власний домен у поле From. Стрибок із p=none одразу в p=reject без такої підготовки, це класичний спосіб втратити справжню пошту: якщо відправником є сторонній сервіс, його bounce-повідомлення до вас зазвичай не доходять, і про проблему ви дізнаєтеся від клієнта.