Подделка отправителя почти не требует технических навыков: достаточно прописать в заголовке From ваш домен, и половина получателей поверит письму. Дальше по схеме – фишинг от имени бренда, жалобы клиентов, попадание в спам-листы, падение доставляемости уже легальной рассылки. Восстанавливать репутацию домена потом дороже, чем один раз выставить три записи. Ниже – рабочий чек-лист по SPF, DKIM и DMARC, по которому я прохожусь при аудите доменов. Заодно разберём, где в этой схеме прячется catch-all домен и почему он иногда сводит на нет всю защиту.

Логика простая. SPF перечисляет серверы, которым разрешено отправлять от вашего имени. DKIM подписывает письмо криптографическим ключом, и подпись проверяется на стороне получателя. DMARC связывает два предыдущих механизма с доменом в заголовке From и говорит, что делать с письмами, которые не прошли проверку: пропустить, отправить в спам или отклонить. Все три технологии работают только с входящей проверкой и репутацией отправителя. На то, как выглядит ваша исходящая почта, они не влияют, но именно от них зависит, дойдёт ли она до адресата или осядет в карантине.

Формат чек-листа выбран не случайно. Настройка редко ломается целиком – обычно забывают один пункт: не включили в SPF нового подрядчика по рассылке, не сменили DKIM-ключ после увольнения админа, оставили политику p=none и успокоились. Каждый такой пропуск – дыра, через которую проходит подделка. Дальше пять обязательных пунктов с пояснением, как проверить каждый, потом отдельный разговор про catch-all почту и типичные ошибки внедрения.

Зачем домену защита от спуфинга: риски подделки отправителя

Как работает подделка отправителя

В SMTP исторически не было встроенной проверки, кто именно отправляет письмо. Поле From в заголовке письма заполняет сам отправитель, и до появления SPF, DKIM и DMARC получатель не мог отличить письмо от легитимного владельца домена от подделки. Спуфер берёт ваш домен, ставит его в обратный адрес, и письмо уходит клиентам с вашим именем: “бухгалтерия”, “поддержка”, “директор”.

Дальше всё просто. Жертва видит знакомый домен, переходит по ссылке и вводит пароль. Или открывает вложение со счётом на оплату. Репутация домена при этом страдает не сразу: первые недели письма уходят с чужих IP, а страдает ваше имя. Когда получатели начинают жаловаться на спам, ваш настоящий домен попадает в спам-листы, и уже ваши легитимные письма перестают доходить до клиентов.

Отсюда два разных ущерба. Первый – прямой: фишинг от имени бренда, потерянные деньги клиентов, претензии. Второй – отложенный: падение доставляемости, когда репутация домена уже подмочена, и восстановить её сложнее, чем настроить защиту с нуля. Именно поэтому три технологии SPF, DKIM и DMARC работают в связке, а не по отдельности.

Что делают SPF, DKIM и DMARC

SPF – это TXT-запись в DNS, где перечислены IP-адреса и хосты, которым разрешено отправлять почту от вашего домена. Получатель сверяет IP отправителя со списком и выносит вердикт. Запись укладывается в лимит 10 DNS-запросов на проверку, и это ограничение – главный источник ошибок при настройке.

DKIM добавляет к каждому письму криптографическую подпись. Приватный ключ хранится на почтовом сервере, публичный – в DNS. Получатель проверяет подпись и видит, что письмо не изменили по дороге. Подпись привязана к домену и селектору, поэтому ключ можно ротировать без простоя.

DMARC – это политика, которая говорит получателю, что делать, если проверки SPF и DKIM не сошлись. Три режима: none (только наблюдение), quarantine (в спам) и reject (отклонить). Плюс адрес для агрегированных отчётов, куда приходят сводки о том, кто и откуда отправляет почту от вашего имени.

Важный нюанс, который часто путают: SPF, DKIM и DMARC влияют только на исходящую почту с точки зрения защиты вашего домена. На входящую почту они не действуют напрямую – приём и маршрутизацию решают MX-запись и правила почтового сервера. MX-запись направляет всю входящую почту домена на один сервер, и уже там решается судьба каждого письма. A-запись сопоставляет имя почтового хоста с IP-адресом, и без неё проверки могут не сработать.

Проверить текущее состояние можно за пару минут. Запросите TXT-запись домена через любой DNS-резолвер и посмотрите, есть ли строка v=spf1. Проверьте селектор DKIM через публичный валидатор. Запросите запись _dmarc и посмотрите, какая политика выставлена. Если хотя бы одной записи нет, домен открыт для подделки.

Дальше имеет смысл идти по чек-листу, а не настраивать всё хаотично. Порядок такой: сначала SPF, потом DKIM, потом DMARC в режиме наблюдения, и только после сбора статистики – ужесточение политики. Ниже разберём пять пунктов, которые закрывают основные дыры, и отдельно остановимся на catch-all, который многие включают “на всякий случай” и тем самым расширяют поверхность атаки.

Чек-лист настройки SPF, DKIM и DMARC: пять обязательных пунктов

Перед вами пять пунктов, которые я проверяю у каждого клиента перед тем, как считать защиту домена рабочей. Порядок не случайный: сначала фундамент в DNS, потом криптография, потом политика и контроль. Пропустите любой пункт, и вся конструкция развалится.

1. SPF-запись укладывается в лимит 10 DNS-запросов. SPF разрешает отправку только перечисленным серверам, но каждый механизм include, a, mx, ptr и exists стоит один или несколько DNS-запросов. Лимит жесткий: 10 запросов, дальше получатель вернет permerror и проигнорирует запись целиком. Проверка простая: отправьте письмо на сервис вроде mail-tester или разберите заголовки у Gmail, там будет строка вида “Received-SPF: pass … (domain of example.ru designates 192.0.2.10 as permitted sender)”. Если видите permerror или too many DNS lookups, режьте include: оставляйте только те сервисы, через которые реально идет почта. Часто хватает объединить рассылку и транзакционные письма на одном провайдере.

2. Все легитимные отправители включены в SPF. Это самая частая причина “сломалось после настройки”. Проверьте по логам почтового сервера и по панелям сервисов, откуда уходит почта: CRM, тикетница, бухгалтерия, формы на сайте, линкбилдинг-рассылки от подрядчика. Каждый источник должен быть в SPF или отправлять через свой поддомен со своей записью. Практика: заведите отдельный поддомен вида mail.example.ru для массовых рассылок, чтобы репутация основного домена не страдала.

3. DKIM-ключ живет и ротируется раз в год. DKIM подписывает письмо приватным ключом, а публичная часть лежит в TXT-записи селектора. Проверка: возьмите любое письмо, посмотрите заголовок DKIM-Signature, выпишите селектор (например, s=mail2024) и запросите dig TXT mail2024._domainkey.example.ru. Запись должна быть, ключ должен быть не короче 2048 бит. Раз в год генерируйте новую пару, публикуйте новый селектор, дайте сутки на распространение DNS, переключите подпись на сервере и только потом удаляйте старый селектор. Так ротация проходит без разрыва подписей.

4. DMARC-политика выставлена в reject. Запись _dmarc.example.ru с v=DMARC1; p=none полезна только на этапе сбора статистики. Рабочая защита это p=reject (или как минимум p=quarantine с pct=100). Начните с p=none на две-четыре недели, изучите отчеты, убедитесь, что все легитимные потоки проходят аутентификацию, и переходите на reject. Проверка: dig TXT _dmarc.example.ru и тестовое письмо с поддельного адреса, которое должно получить отказ. Не забудьте про поддомены: директива sp=reject закрывает и их, иначе через поддомен можно спуфить основной домен.

5. Отчеты DMARC приходят на отдельный ящик. В записи укажите rua=mailto:dmarc@example.ru и ruf=mailto:forensic@example.ru, но не направляйте их на общий ящик поддержки: агрегированные отчеты это XML-архивы, по несколько штук в день с каждого крупного провайдера. Заведите отдельный адрес или подключите сервис разбора отчетов. Без регулярного чтения отчетов вы не узнаете, что кто-то из подрядчиков шлет почту в обход SPF, и политика reject тихо отрежет легитимный трафик.

Держите этот список под рукой при каждой смене подрядчика или почтового провайдера: именно в такие моменты SPF и DKIM чаще всего расходятся с реальностью.

Catch-all почта и спуфинг: что такое catch-all и чем он опасен для домена

Про catch-all вспоминают, когда клиент жалуется, что письмо на info@ или sales@ “не дошло”. Смотришь в панель, а ящика такого нет, и сервер честно ответил отправителю 550 no such user. что такое catch-all домен раскрывает эту тему глубже. Первая мысль: включить приём почты на любой адрес, чтобы больше ничего не терялось. Мысль понятная, но с точки зрения защиты от спуфинга она часто работает против владельца домена.

Что такое catch-all по сути: это резервное правило сервера, которое срабатывает, когда локальная часть адреса не совпала ни с одним существующим ящиком или алиасом. Нераспознанная локальная часть не отбивается, а письмо уходит в единый ящик, указанный в настройке. MX-запись направляет всю входящую почту домена на один сервер, дальше уже этот сервер решает, что делать с получателем. Важно: catch-all настраивается на почтовом сервере, а не в DNS. В DNS вы лишь указываете MX и A-запись, которая сопоставляет имя почтового хоста с IP-адресом. Само правило живёт в почтовой панели хостинга или в конфиге MTA.

Как работает catch-all почта на практике. Администратор задаёт адрес-ловушку, например box@domain.tld, и ставит галочку “принимать почту на несуществующие адреса”. Дальше любое письмо на qwerty@, director@, hr@, бухгалтерия@ падает в этот ящик. Пользователь забирает почту одним логином по POP3 или IMAP, а при необходимости раскладывает поток фильтрами по адресу получателя. Звучит удобно, и для маленькой компании с десятком ролей это действительно экономит время: не нужно заводить ящик под каждую хотелку.

Теперь про риск. Catch-all домен многократно увеличивает поверхность атаки. Спамеры и фишеры перебирают локальные части наугад: admin, billing, support, имя-фамилия. Без catch-all сервер отбивает мусор на этапе SMTP, и он не занимает место, не попадает в индекс и не отвлекает людей. С включённым правилом каждое такое письмо принимается. Если DMARC-политика стоит в p=none, подделка отправителя не блокируется, и письма с вашего же домена, отправленные чужим сервером, спокойно долетают до ящика-ловушки. Дальше сотрудник открывает вложение “счёт.pdf” от имени собственного домена и не видит подвоха.

Отдельная история, из-за которой catch-all часто и заводят: линкбилдинг и регистрация в каталогах. Люди дают адрес вида seo@domain.tld, чтобы не светить основной, а потом удивляются, что на него валится спам. Catch-all собирает этот спам в один ящик, но заодно собирает и фишинг. Ещё одна деталь: опечатка в адресе контрагента теперь не вернёт отправителю ошибку. Письмо молча уляжется в ловушку, и вы узнаете о проблеме через неделю, когда сорвётся сделка.

Сравним варианты настройки, чтобы выбрать осознанно.

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

Типичные ошибки при внедрении и порядок проверки защиты домена

Даже аккуратно собранная защита ломается на мелочах. Ниже – сбои, которые я вижу чаще всего при аудите чужих доменов, и порядок проверки, который имеет смысл повторять раз в квартал.

Четыре сбоя, которые обнуляют всю защиту

Переполнение лимита DNS-запросов в SPF. Запись SPF обрабатывается за 10 DNS-запросов максимум. Каждый механизм include, a, mx и ptr расходует квоту, а вложенные include тянут за собой чужие записи. Домен с четырьмя ESP в SPF легко уходит за предел, и тогда результат проверки – permerror, то есть не pass. Проверять просто: любой публичный SPF-валидатор показывает счётчик запросов. Держите его в районе 6-7, оставляя запас на новые сервисы.

Забытая ротация DKIM. Ключ, который не меняли три года, рано или поздно утекает вместе с уволенным подрядчиком или старым сервером рассылок. Ротация раз в год – норма. Механика: генерируете новую пару, публикуете новый селектор рядом со старым, переключаете подпись на сервере, ждёте сутки-двое, снимаете старый селектор. Важно не удалять старый ключ раньше времени: подписанные им письма ещё в очереди на доставку.

Политика p=none вместо reject. Многие ставят DMARC в режим мониторинга и оставляют так навсегда. p=none ничего не блокирует: поддельные письма продолжают доходить до получателей, а вы лишь получаете отчёты. Правильный маршрут – none на две-три недели, затем quarantine с процентом 25-50, затем полный reject. Если боитесь за легитимные рассылки, сначала соберите их в SPF и подпишите DKIM.

Отчёты на общий ящик. Агрегированные XML-отчёты по DMARC приходят со всех крупных провайдеров и весят немало. Если они валятся в info@ вместе с рабочей перепиской, их перестают читать через неделю. Заведите отдельный ящик или внешний сервис разбора отчётов и повесьте на него правило в почтовой панели хостинга.

Отдельно про catch-all. Если на домене включён catch-all, письмо на нераспознанную локальную часть не отбивается ответом 550 no such user, а принимается. При p=none такой ящик превращается в свалку списанных адресов, фишинговых копий и мусора. При жёсткой политике reject и выключенном catch-all сервер отбивает подделку на уровне SMTP, и это самый чистый вариант.

И не путайте зоны ответственности: SPF, DKIM и DMARC влияют только на исходящую почту и на то, как её оценивают получатели. Входящую защиту они не обеспечивают, за неё отвечают фильтры и правила маршрутизации почты на самом сервере.

Порядок проверки после настройки:

1. Убедитесь, что MX-запись направляет всю входящую почту домена на нужный сервер, а A-запись сопоставляет имя почтового хоста с IP-адресом.
2. Прогоните TXT-запись SPF через валидатор: лимит запросов, отсутствие двойных пробелов, синтаксис all.
3. Отправьте тестовое письмо на сервис проверки DKIM и убедитесь, что подпись проходит по нужному селектору.
4. Посмотрите опубликованную DMARC-запись: p=reject, rua на отдельный ящик, при необходимости ruf для форензики.
5. Проверьте, что catch-all выключен или хотя бы ограничен, и что для несуществующих адресов сервер отвечает 550.
6. Раз в месяц просматривайте агрегированные отчёты: новые источники в столбце pass – повод добавить их в SPF, всплеск fail – повод разбираться.

Дальше – дисциплина. Ротация ключей по календарю, пересмотр SPF при подключении любого нового сервиса, контроль того, что отчёты действительно читают. Защита от спуфинга – не разовая настройка, а регулярная процедура, и чек-лист выше как раз помогает её не забросить.

Практический следующий шаг прост: возьмите свой домен и прогоните его через любой публичный проверяльщик DMARC (dmarcian, MXToolbox, mail-tester). Смотрите на три цифры. Первая: сколько DNS-запросов реально съедает SPF-запись, включая include и redirect. Вторая: есть ли в DNS селектор DKIM, которым вы подписываете исходящую почту прямо сейчас, и совпадает ли длина ключа с 2048 битами. Третья: какая политика стоит в `_dmarc`, p=none, p=quarantine или p=reject, и куда уходят aggregate-отчёты. Если хотя бы один пункт вызывает сомнение, начинайте с него, а не с переписывания всего сразу.

Дальше действуйте в таком порядке. Выпишите всех легитимных отправителей: почтовый сервер хостинга, рассылочный сервис, CRM, Helpdesk, платёжные уведомления. Для каждого найдите IP или домен и убедитесь, что он покрыт SPF и подписывает письма своим DKIM-селектором. Затем переведите DMARC в quarantine с процентом 25-50 и неделю смотрите отчёты: если легитимный поток проходит аутентификацию, поднимайте до 100 и переключайтесь на reject. Отдельно настройте ящик для отчётов, не общий, а служебный, иначе сводки утонут в переписке. Заведите напоминание на ротацию DKIM-ключа через 10-12 месяцев и на пересмотр SPF при смене подрядчиков.

И последнее, что стоит закрыть в тот же вечер: проверьте, не включён ли на домене catch-all. Если включён и вы не используете его осознанно для единого ящика, отключите. Маршрутизация почты на любой нераспознанный адрес в сочетании со слабой DMARC-политикой превращает ваш домен в удобную мишень, а сервер вместо честного 550 no such user молча принимает подделку. Защита от спуфинга держится на трёх записях и одной привычке: раз в квартал смотреть отчёты и не оставлять политику в режиме мониторинга навсегда.