Як листи компанії перестали потрапляти в спам. Налаштування DMARC

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Cпівробітники однієї компанії, назвемо її mydomain.com, почали скаржитись, що відправлені листи потрапляють у спам. І доводиться наздоганяти клієнтів іншими способами зв’язку, щоб ті дістали email зі спаму. Це дуже неприємно і виснажує.

Саме для цієї проблеми існує рішення — увімкнути DMARC для домену. Це підвищує поштову репутацію вашого домена і зменшує можливість слати fake email від вашого імені.

Щоб вперше розібратися (за допомогою стандартних статтей), мені знадобилося три тижні, а ще три місяці пішло на обережний перехід. На другий раз все вийшло за один тиждень — згадати, впровадити, постежити.

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

Перевірка: чи є у вашого домена DMARC (можливо, вам це не треба)

Введіть тут свій домен, якщо буде зелененький Success, то все ok.

Коротко про DMARC, SPF, DKIM

Це все просто рядки в DNS.

SPF — з яких IP можна слати email з вашого домену.

DKIM — публічний ключ для підпису контенту в email. Щоб не можна було «по дорозі» дописати до email щось типу «ось вам посилання на інвойс, чекаємо на оплату».

DMARC — заява, що SPF і DKIM правильні, і інших точок відправлення не існує, можна не приймати email, в яких не виконується хоча б один з них.

Чому «хоча б один», а не обидва — тому що при форварді листа на рівні поштового сервера, IP відправника зміниться, і SPF правило не виконається.

Ось приклад, як ці записи виглядають (для простоти — по одному SPF і DKIM):

SPF

TXT
mydomain.com
v=spf1 ip4:123.123.123.123  include:_spf.google.com include:spf.mandrillapp.com ~all

DKIM

TXT

TXT
my._domainkey
v=DKIM1;t=s;p=6xqZ4VwYUuwwo0khKLjCNKSuNADCBiQKBgQDKLgKZ5P5OXkpOPnzh1sytIkSEsFYpjkaynGyfVW/4fYBKVAsOHomSwPQJjTxs+uZ4VwYUuwwo0khKLjCNKSuoAQH0ulxuiJ0R0PU5wN7GQzXkgm+BFtTKy7nPbsROHfkJfcLgKZ5P5OXkpOPnzh1sy

DMARC

TXT

TXT
_dmarc
v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]; ruf=mailto:[email protected],mailto:[email protected];

Dmarc adoption graph

Тут важливий синій графік, що використання DMARC експоненційно росте. Зелені проценти — ігноруйте, це просто відносне зростання.

Кількість доменів в інтернеті, мабуть, вже більше 500 млн, але можна припустити, що 5 млн — активні.

За підрахунком за звітами (про них нижче) через поштові сервери, які враховують DMARC, проходить десь близько 70% листів.

Робимо інвентаризацію всіх місць, з яких відправляємо email від імені домену компанії

В цьому випадку email їхали з:

• Проду.
• Mailgun.
• Mailchimp.
• Gmail.
• Apple mail icloud.com (по факту, через Gmail).
• Frontapp (по факту, через Gmail).

Робимо інвентаризацію записів в DNS — SPF, DKIM, DMARC

Дивимося, що в DNS компанії, це всі рядки з «spf» (один або кілька для піддоменів), «_domainkey» (кілька), «_dmarc» (один або ще немає).

DKIM something._domainkey — для кожного сервісу відправки буде свій.

Записи, як правило, TXT, але можуть зустрічатися legacy CNAME — це ок, можна так і залишати.

SPF було тільки два — у Mailgun і прямої відправки з проду:

TXT mydomain.com v=spf1 ip4:123.123.123.123 include:_spf.google.com ~all
TXT mg v=spf1 include:mailgun.org ~all

DKIM було 4, не для всіх сервісів, і деякі застарілі:

CNAME intercom._domainkey ce925367-d821-437e-bec6-37f626311662.dkim.intercom.io
CNAME k1._domainkey dkim.mcsv.net
TXT mandrill._domainkey k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCrLHiExVd55zd/IQ/J/mRwSRMAocV/hMB3jXwaHH36d9NaVynQFYV8NaWi69c1veUtRzGt7yAioXqLj7Z4TeEUoOLgrKsn8YnckGs9i3B3tVFB+Ch/4mPhXWiNfNdynHWBcPcbJ8kjEQ2U8y78dHZj1YeRXXVvWob2OaKynO8/lQIDAQAB;
TXT smtp._domainkey.mg k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC0mlnrIV3kZmuQ7AxBGvgSjqHdoTjldTgBA5p2F0+GUYPwvh1BMdGndLhqSI5FZE15tXlnTjoBfKC6XqrqBUMmvsptP0aJ3P205fhoZuLNfTEVqFSf0jpa/wSJn8CqhHs45ppStvZcDCWxepGhK1gUJWP24utaHcWaiq4Naj1/kQIDAQAB

Додаємо SPF та DKIM, яких не вистачає

У цьому випадку більшість SPF та DKIM записів вже були, деякі некоректні виправили, і треба було додати DKIM:

• На проді, пряма відправка email з коду, додали лібу з DKIM підписом і прописали ключ в DNS.
• Увімкнули для Gmail в Google Suite за цією інструкцією.
• Прописали SPF та DKIM для Mailchimp за цією інструкцією.

Щоб протестувати, повідправляла по одному листу в усіх напрямках, що були вище:

• Пряма відправка з прода.
• Відправка через Mailgun.
• Відправка через Mailchimp.
• Відправка з Gmail з домену компанії.
• Відправка з локальної Apple mail з домену компанії.

Як виглядало вмикання DKIM в Gmail за інструкцією за посиланням вище

Ось тут генерували DKIM, прописали його в зоні, натиснули START AUTHENTICATION, і за кілька хвилин воно відпрацювало — це просто побачили за заголовками на тестовому листі. Не за 48 годин.

Аналізуємо заголовки листа

В Gmail побачити заголовки — натиснути на «три крапки» і вибрати «Show original».

Якщо все правильно, повинні бути dkim=pass і spf=pass:

Authentication-Results: mx.google.com;
dkim=pass [email protected] header.s=k3 header.b=hE1bjUnu;
arc=pass (i=1 spf=pass spfdomain=mail51.suw131.mcsv.net dkim=pass dkdomain=mailchimpapp.net);
spf=pass (google.com: domain of [email protected] designates 209.85.220.41 as permitted sender)

Тут arc — це не шматок «dmarc», це Authenticated Received Chain — Wikipedia, він нас не дуже хвилює. Але він також буде часто присутній в заголовку Authentication-Results.

Створюємо окремий email для репортів

У DMARC запису треба буде вказати два email:

• aggregate для збірних репортів про більшість відправлених листів;
• forensic «для розслідувань» з заголовками «поганого листа» по один email на кожний «поганий» лист.

Forensic листів і раніше було мало — одиниці на рік або разовий сплеск на сотню, бо коли dmarc увімкнено, спамерам немає сенсу слати. А зараз поштові сервери майже зовсім не шлють, бо забагато персональної інфи.

Тому на forensic я вказувала адмінський email. Можна обидва типи репортів слати на один. Дивлячись, що потім плануєте з ними далі робити.

Ось так будуть виглядати репорти (десятки в день) від поштових серверів:

У компанії десь 20 листів на день, у кожному репорт на 1-100 records, кожен record про 1-300 відправлених листів з домену компанії.

Якщо використовувати готові сервіси для красивої аналітики (про це нижче), треба буде вказати email для обох типів репортів.

Створила одну скриньку aggregate-reports@mydomain.com, а на forensic reports поставила адмінів.

Вмикаємо dmarc 100% none

Це холостий запуск DMARC, щоб почати отримувати репорти, але щоб не зламалася чинна логіка доставки листів.

Додаємо в DNS запис:

TXT _dmarc v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]; ruf=mailto:[email protected],mailto:[email protected];

Тепер у листів, що приходять, наприклад, через Mailgun, такий заголовок Authentication-Results (додалося dmarc=pass):

Authentication-Results: mx.google.com;
dkim=pass [email protected] header.s=smtp header.b=S9H7ybFy; dkim=pass [email protected] header.s=mg header.b=PQPjhfUL;
spf=pass (google.com: domain of [email protected] designates 104.130.123.202 as permitted sender) smtp.mailfrom="[email protected]";
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=mydomain.com

Аналізуємо репорти

Ось такі XML-і будуть в листах від поштових серверів. Там може бути інфа про багато листів, а може бути один рядок про один лист.

Для кожного зараз нас цікавить лише блок , чи там spf=pass, dkim=pass.

Коли ввімкнемо наступні режими — будемо дивитись на : none — це доставлено, quarantine — спам, reject — повернуто.

Вмикаємо DMARC по-справжньому

Якщо з попереднім заходом все було ок і нової інфи не з’явилося, типу що десь DKIM неправильний, або не вистачає, то далі рекомендується включати потроху до повного стану reject 100%.

Режими:

• none — не заважати листам, але слати репорти;
• quarantine — відправляти в спам листи, що не підійшли;
• reject — не приймати листи, що не підійшли.

Проценти — до якого проценту листів рандомно застосовувати це правило. Всі інші будуть доставлятися.

У залежності від відповідальності і обсягу доставок, ви можете поступово нарощувати режим quarantine, а потім режим reject. Або можете різко вмикати і дивитися, що буде.

Тут перемикання на наступний етап були ввечері в робочі дні, і ввечері, і зранку на вихідних. Один раз швидко вимкнула, бо щось пішло не так — неправильно перепастила в одному місці DKIM, побачила одразу в репортах.

Графік етапів переходу тут був такий (з четверга до понеділка):

• 100% none
• 5% quarantine
• 20% quarantine
• 50% quarantine
• 100% quarantine
• 50% reject
• 100% reject

Перевіряємо, що листи компанії потрапляють не в спам, і що в заголовках Authentication-Results: spf=pass, dkim=pass, dmarc=pass

У репортах aggregate-reports вже дивимося на disposition, і розглядаємо ті, які quarantine або reject (їх буде мало, близько 1 на 1000).

Як може виглядати email, коли вже увімкнений reject, тут був факап DKIM налаштування, плюс відправка з аліасу. Виправили потім DKIM:

Дві доби до повного впровадження нового правила

В репортах ви будете продовжувати бачити репорти про попередні правила (блок policy_published), до поштових серверів це дійде десь за добу, і репорти вони можуть надсилати десь раз на добу. Тобто десь дві доби до повного переходу на нове правило.

Але якщо на перші репорти — ви дивитесь на всі, то просто це враховуйте.

Контролюємо, де можемо

Відправки листів всіма шляхами тестували вручну: що доходить, чи спілкування з клієнтами у співробітників відбувається в звичайному режимі.

Але для сервісів розсилок позберігали проценти open-листів. Потім порівнювали для відповідних тегів або компаній на статистиці за кілька днів, що не зламали. Там у різних типів email будуть різні «нормальні» проценти відкриття листів. Десь 20%, десь 40%, десь 60%. У першу добу — процент нижче, на проміжку в тиждень вже приблизно такий же.

Підключаємо parsedmarc у простому вигляді

Щоб не аналізувати XML-файли вручну, можна такою тулзою вигрібати ящик aggregate-reports і надсилати те ж саме в csv.

Ось простий репозиторій, де треба вказати свої дані від geoip2 і логін/пароль від ящику, звідки забирати репорти.

GeoIP конфіг треба зареєструватися і безкоштовно скачати тут.

Оскільки тут скриньки на Gmail, там треба було додатково ще дозволити Gmail-акаунту ходити на нього скриптами, це робиться тут:

Google Account Settings -> Security -> Less secure app access -> On

Далі, коли вказали все в конфігах, просто з цього каталога docker compose up і він відпрацює і надійшле репорт у вигляді архіву.

Нас там цікавить лише файлик aggregate.csv.

Тут сортуємо у колонці disposition і роздивляємося quarantine та reject рядку.

Цікаві source_ip_address, source_country, source_reverse_dns, source_base_domain.

Зазвичай і так видно, що фігня якась, точно спамери.

Але можна перевірити IP ще тут.

Через двокрапки — це ipv6 адреси, їх там же можна перевіряти.

Про сервіси і ціни dmarcly, dmarcian та інші

Коли я перший раз зітикнулася з DMARC, дивилася на різні сервіси.

З тих пір вони сильно подешевшали. У них є красива аналітика цих репортів. І, як правило, 14 днів trial: можна все налаштувати, роздивитись, що буває, і втекти на простий безкоштовний parsedmarc.

Щоб їх підключити, ніяких доступів давати не треба, достатньо просто вказати їх email в ваш DMARC-рядок в DNS.

Сервіси, які мені сподобалися:

• dmarcly.com ($70/month для 1M email)
• dmarcian.com ($200/month для 1M email)

Що може сконфузити в pricing.

Ключовий термін — «DMARC capable message» — це скільки ваших email пройде через репорти.

Якщо, наприклад, ви всього шлете близько 1млн email на місяць, то через DMARC репорти пройде десь 700 тис.

Хоча записів <record> в репортах буде ~100 тис, а листів-репортів ви отримаєте ~500.

Тарифний план ви дивитесь той, що для 1 млн :)

Рідкісні проблеми

• SPF може включати до 10 адрес, якщо треба більше — там можливе групування. Платні сервіси це можуть зробити за вас через свої DNS-записи.
• Стародавні редактори DNS можуть не пропустити TXT-записи більше 255 символів, для DKIM треба буде 1024 або 2048. DKIM запис можна нарізати на декілька.
• Використання ще одного домену-аліасу — йому треба теж все це прописати і окремий DKIM зробити.
• Одному користувачу продовжили листи попадати в спам, але вони були продовженням треду від старого листа, який давно був у спамі. Відправка нового email — пофіксила.
• Ще одному користувачу листи продовжили падати в спам, бо він залишив email на сервісі як [email protected]. Таке використовують для сортування по папкам, але в його випадку більшість таких email в нього падали в спам, він їх звідти не виймав. Тому лист компанії теж пішов в спам. Йому почали писати на [email protected] і все доходило.

Про проблеми з налаштуванням DMARC або з потраплянням ваших листів у спам — можете питати у коментах. Або звертайтеся у telegram @ksuhaster