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

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

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:

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

  • Пряма відправка з прода.
  • Відправка через 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 для обох типів репортів.

Створила одну скриньку [email protected].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.

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

Що може сконфузити в 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

Сподобалась стаття? Натискай «Подобається» внизу. Це допоможе автору виграти подарунок у програмі #ПишуНаDOU

👍ПодобаєтьсяСподобалось13
До обраногоВ обраному7
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

От би ще дієві поради, як у Промоакції не потрапляти. Не научпоп, а конкретні кейси.

ну ось це виглядає як непоганий початок що перевірити
www.saleshandy.com/...​oid-gmail-promotions-tab

в мене, до речі, кейс був, коли дизайнер зробив розсилку дуже красивою html-ною — і вона улетіла в усіх в спам
ну тобто краще мімікрувати під прості робочі листи

Так-так, у нас був такий самий досвід з красивим html :) Дякую, це привід спробувати поекспериментувати та спростити ключові розсилки до рівня плинтусу.

а який зараз open rate? якщо не під NDA
можна з різними тегами експериментувати і дивитися що буде, але з того що я бачила в багатьох місцях,
25% — десь середній для розсилок
40% — у улюблених продуктів або в хоббі-напрямках
60% — у приватних повідомлень з сервісів
95% — у листів типу «скинути пароль»

Тобто останній тут — мірило що в цілому в спам не попадають.
Але потолок для просто розсилок часто в районі 25-40%.
Тобто якщо вже є 38-45%, то навряд чи можна щось покращити.
І бажана регулярність 1-4 рази на місяць, якщо частіше або рідше — там різко падають метрики.

Ще бачила прикольне рішення — відписувати тих, у кого довго не було open event, це може підняти метрики, або зекономити 50% mail cost через сервіси, але це повна втрата юзера :) хз чи це треба бізнесу.

Тим часом, антиспам системи заблочили листи з доу )
NOQUEUE: reject: RCPT from mail.a202.static.mgsend.net[104.130.123.202]: 554 5.7.1 Service unavailable; Client host [104.130.123.202] blocked using sbl.spamhaus.org; Error: open resolver; www.spamhaus.org/...​eturnc/pub/162.158.248.58 ;

Хто що робить в таких випадках?

так там написано, що проблема на стороні сервера отримувача
www.spamhaus.org/...​eturnc/pub/162.158.248.58

> Why has my email not been delivered?
>
> The problem is with the recipient’s email server configuration.
> This is not due to an issue with your email set-up.
> It is not because you are listed on one of our blocklists.

якщо хочете, пришліть у telegram @ksuhaster повний source цього email, підкажу більше

Так, потрібно було стежити ) Проблема описана тут www.spamhaus.org/...​eck-your-return-codes-now а рішення тут docs.spamhaus.com/...​age/MTAs/020-Postfix.html

Ось у цьому мануалі
mxtoolbox.com/...​etails/how-to-setup-dmarc
наприкінці
6. Validate Record is Setup Correctly
є посилання для перевірки налаштувань dmark.

Цікаво, що за ним домен, що я колись давно налаштовував
DMARC Record found
А якщо перевірити за лінком, що на початку статті, то я маю
DMARC record not found.

Якось то дивно вони перевіряють 🤔

там запис _dmarc.твій.домен ну напиши в консолі, наприклад:

host -t txt _dmarc.djinni.co
для джина буде відповідь:
_dmarc.djinni.co descriptive text "v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]; ruf=mailto:[email protected];"
якщо немає DMARC запису:
> host -t txt _dmarc.zuzu.com
Host _dmarc.zuzu.com not found: 3(NXDOMAIN)
для джина буде відповідь

Саме це «мій» домен має.
Але лінк на початку статті при перевірці виписав
DMARC record not found.
А лінк, з іншого мануала навпаки, сповістив, що found.

host -t txt _dmarc.mydomain.com

_dmarc.mydomain.com descriptive text "v=DMARC1; p=none; rua=mailto......

а, таке буває, часто такі сервіси «криві», хтось разово написав і закинув
той що з dmarcly.com повинен нормально показувати:
dmarcly.com/tools/dmarc-checker

тому що при форварді листа на рівні поштового сервера, IP відправника зміниться, і SPF правило не виконається

Тільки у дуже індуських серверів

Ну це на конкретних кейсах, які зразу вилазили :)
Це, до речі, gmail forward був з однієї пошти на іншу.

ааааа стаття бомба, засунула за пояс мабуть 90% айтішечки не менше

хто не тр_вся з поштою, той не жив

Якщо це не ванільний postfix то нічого надскладного там нема)

Та й з ванільним postfix нічого надскладного немає, читай мануал та й по всьому.

Це тільки до кінця мануалу ;)

А ще переважна більшість мануалів виглядає так:
Step 1: Draw two circles
Step 2: Draw owl

iRedMail робить всю мануальну роботу практично на рівні wizard для встановлювача звичайного застосунку.

Ну в принципі як і Mailcow. Та багато інших.

В цій гілці дискусія про насетап 1 каналу відправки.
Але у компанії з історією, як правило, декілька каналів відправки:
— якісь маркетингові сервери розсилок, іноді декілька,
— свій або чужий сервер для transactional email (повідомлення користувачам),
— якийсь обслуговувач ящиків співробітників (gmail, microsoft),
— якась служба підтримки (zendesk, intercom, frontapp).
І оце все треба зібрати в кучу, перевірити, доналаштувати.

Дякую за покрокову й детальну інструкцію, буду пробувати.

Ну по останній проблемі видно, що якщо користувач на gmail викидав листи «user+щось@gmail.com» в спам, то вони так і будуть туди падати. DMARC — це підвищити доставляємість. Поведінка юзера перекриє основну логіку антиспам-фільтрів.

Підписатись на коментарі