Письма с вашего домена уходят в спам: SPF, DKIM и DMARC по порядку

Что происходит с письмом на той стороне

Когда ваше письмо приходит в чужой почтовый ящик, принимающий сервер за доли секунды отвечает себе на три вопроса. С того ли сервера письмо пришло — на это отвечает SPF. Не подменили ли текст по дороге и точно ли письмо ваше — это DKIM. И, наконец, что делать, если первые две проверки не сошлись, — это DMARC.

Ключевая деталь, из-за которой обычно и возникает путаница: у письма два отправителя. Есть адрес на конверте, которым обмениваются серверы, и есть видимое поле «От кого», которое читает человек. SPF проверяет только конверт. Подставить в видимое поле любой адрес можно независимо от того, настроен у вас SPF или нет, — именно поэтому одной записи мало, и именно это связывает воедино DMARC.

Ни одна из трёх записей не лежит на сайте: все три живут в DNS домена. Поэтому сайт может быть идеально настроен, а почта — сползать в спам, и наоборот.

SPF: кому вообще можно слать почту от вашего домена

SPF — это TXT-запись на домене со списком серверов, которым разрешено отправлять письма от вашего имени. Выглядит она примерно так:

v=spf1 include:_spf.your-provider.ru ip4:203.0.113.10 -all

Читается слева направо: разрешить серверам почтового провайдера, разрешить конкретному адресу, всем остальным — отказать. Последняя директива и есть самое важное место записи. -all означает «остальным нельзя», ~all — «остальные подозрительны, но пропустите». Мягкий вариант удобен на время настройки, но он остаётся в записях годами, и защита из строгой превращается в рекомендательную.

Четыре ошибки, которые встречаются чаще остальных:

• Две записи SPF на одном домене. Так бывает, когда подключают второй сервис и добавляют ещё одну строку рядом. По стандарту запись должна быть одна: увидев две, принимающая сторона считает проверку несостоявшейся — то есть хуже, чем если бы SPF не было вовсе. Несколько отправителей объединяются в одну запись через несколько include.
• Больше десяти обращений к DNS. Каждый include — это запрос, и вложенные записи провайдеров тянут за собой свои. Лимит в стандарте — десять; при его превышении проверка обрывается с ошибкой, о которой вам никто не сообщит.
• Забытый отправитель. Рассылочный сервис, CRM, а чаще всего сам сайт: форма обратной связи отправляет письма с адреса на вашем домене прямо с хостинга, а в SPF этого хостинга нет.
• Старый адрес после переезда. Запись продолжает разрешать отправку с сервера, которым вы уже не пользуетесь. Подробный разбор — в статье о переезде на российский хостинг.

DKIM: подпись, которая переживает пересылку

DKIM — электронная подпись, которую почтовый сервер ставит на каждое исходящее письмо. Закрытый ключ остаётся у провайдера, открытая часть лежит в DNS по адресу вида selector._domainkey.example.ru, где селектор выдаёт сам провайдер. Получатель берёт открытый ключ, проверяет подпись — и знает, что письмо действительно ваше и текст не меняли по дороге.

Зачем это нужно, если SPF уже есть. SPF привязан к серверу-отправителю и ломается на любой пересылке: клиент настроил себе автоматическую переадресацию, письмо ушло в список рассылки — отправляющий сервер сменился, проверка не проходит. Подпись при этом остаётся на месте и письмо доезжает. Без DKIM такое письмо выглядит для почтовой службы подозрительным дважды и отправляется в спам почти гарантированно.

Проверить DKIM снаружи можно только наполовину, и об этом честно стоит знать: селектор придумывает провайдер, перечислить все возможные нельзя. Поэтому и наша проверка, и любой другой внешний инструмент перебирают распространённые селекторы — и говорят «по типовым селекторам ключ не нашёлся», а не «у вас нет DKIM». Свой селектор смотрите в панели почтового сервиса, там же он и включается: провайдер выдаёт готовую TXT-запись, её остаётся добавить в DNS.

DMARC: что делать, если проверки не сошлись

DMARC — запись на поддомене _dmarc, которая делает две вещи. Во-первых, требует, чтобы домен из проверенных SPF или DKIM совпадал с видимым полем «От кого» — тем самым, которое читает клиент. Во-вторых, говорит почтовым службам, как поступать с письмами, которые проверку не прошли.

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.ru

Политика принимает три значения: none — ничего не делать, только присылать отчёты; quarantine — класть в спам; reject — не доставлять вовсе. Отдельно стоит сказать про первое: p=none ничего не защищает. Это режим наблюдения, и подделанное письмо от вашего домена при нём по-прежнему попадает клиенту во «Входящие». Запись есть, галочка стоит, эффекта нет — самая частая ситуация из тех, что мы видим в отчётах.

Правильный порядок внедрения — тремя шагами, а не одним:

1. p=none и адрес для отчётов в rua. Две-три недели почтовые службы присылают сводки: кто и от вашего имени отправлял почту.
2. Читаете отчёты и убеждаетесь, что вся своя почта проверку проходит: сайт, CRM, рассылки, бухгалтерия. Всё, что не проходит, — либо чинится, либо добавляется в SPF и подписывается.
3. quarantine, а через некоторое время reject.

Прыгать сразу в reject — это не «сделать строго», а выстрелить себе в ногу: неучтённый отправитель просто перестанет доставлять письма, причём молча и для всех сразу.

Где это ломается на практике

Домен, с которого не пишут. Ему записи нужны не меньше, чем рабочему: домен без SPF и DMARC — удобная площадка для рассылки от вашего имени, и претензии за такой фишинг придут вам. Настройка простая и разовая: v=spf1 -all и DMARC с политикой reject.

Поддомены. SPF на example.ru не покрывает mail.example.ru — у каждого имени своя запись. DMARC, наоборот, распространяется на поддомены и умеет задавать им отдельную политику директивой sp=. Про забытые поддомены вообще стоит помнить отдельно — они всплывают и в других проверках, см. разбор перед запуском.

Подключили рассылочный сервис. Классический сценарий: сервис добавили, SPF не тронули, DKIM не включили — и первая же массовая рассылка уезжает в спам целиком, заодно портя репутацию домена для обычной переписки.

Записи пропали. Смена регистратора, перенос зоны, «почистили лишнее» — и SPF с DMARC исчезли. Внешне ничего не происходит: сайт открывается, письма уходят. Замечают такое через недели, по жалобам клиентов. Ежедневная проверка домена ловит это на следующий день — в том числе поэтому в подписке проверка повторяется сама и показывает, что изменилось со вчера.

Как проверить свой домен

Быстрый путь — проверка на главной: введите адрес сайта, и в отчёте будет видно, есть ли SPF, есть ли DMARC и не стоит ли он в режиме наблюдения, нашёлся ли ключ DKIM по распространённым селекторам, куда указывают MX и какой почтовый провайдер за ними стоит. Это бесплатно и без регистрации.

Руками — три команды. Они же годятся, чтобы проверить чужой домен перед тем, как поверить письму от него:

dig +short TXT example.ru
dig +short TXT _dmarc.example.ru
dig +short MX example.ru

В ответе на первую команду должна быть ровно одна строка, начинающаяся с v=spf1, и заканчиваться она должна на -all. На вторую — строка с v=DMARC1 и политикой строже, чем p=none. На третью — почтовый сервис, которым вы пользуетесь сейчас, а не тот, что был до переезда. В Windows то же самое делает nslookup -type=txt example.ru.

DKIM проверяется той же командой, но по своему адресу — подставьте селектор из настроек почтового сервиса:

dig +short TXT selector._domainkey.example.ru

Три записи настраиваются за полчаса и один раз. Дальше остаётся следить, что они на месте: исчезают они тихо, а замечаются по фразе клиента «мы ничего не получали».