Представьте, вам на почту приходит письмо от гендиректора: просьба срочно оплатить счет. Адрес отправителя совпадает буква в букву, подпись на месте. Но гендиректор его не отправлял. Если перейти по ссылке, можно поймать вредоносное ПО или попросту перевести деньги неизвестному злоумышленнику.
Чтобы создать такое письмо, мошеннику не нужно ничего взламывать — достаточно вписать чужой адрес в поле «От кого», потому что почтовый протокол его никак не проверяет. Защитить почту от подделки помогают SPF, DKIM и DMARC. Что это такое и как работает — разбираем в статье.
Что такое SPF, DKIM и DMARC — максимально коротко
Это три записи в DNS вашего домена, и каждая закрывает свою уязвимость. SPF (Sender Policy Framework) говорит, с каких серверов можно отправлять письма от вашего имени. DKIM (DomainKeys Identified Mail) ставит на письмо криптоподпись, по которой видно, что его не подменили по дороге. DMARC (Domain-based Message Authentication, Reporting and Conformance) задает правило, что делать с письмами, которые проверку не прошли, и присылает отчеты.
Почему письмо от вашего домена может отправить кто угодно
Почту передает протокол SMTP, придуманный еще в начале 1980-х. Тогда в Сети все друг друга знали, и проверки отправителя в протоколе просто не было. Поэтому в поле «От кого» можно вписать любой адрес, и сервер его пропустит. Это не уязвимость конкретной почты, а свойство самого протокола.
Важная деталь, без которой не понять ни одну из трех записей: у письма два разных адреса отправителя.
- Адрес в конверте (его называют MAIL FROM или Return-Path) — технический. Его видит принимающий сервер, но не видит человек.
- Адрес в заголовке From — тот самый «От кого», который показывает почтовый клиент. Его видит человек.
В обычном письме эти адреса совпадают. Но подделать можно каждый по отдельности, и вот в чем подвох: SPF проверяет адрес из конверта, а обманывают человека через видимый From. Одна запись эту уязвимость целиком не закрывает — поэтому их три, и работают они в связке.
Кому это вообще нужно настраивать? Всем, у кого почта работает на собственном домене. Отдельная история — когда письма за вас отправляют сторонние сервисы: CRM, форма обратной связи на сайте, платформа рассылок. Записи в DNS все равно ваши, и настраивать их придется вам, а не сервису.
Еще один повод не откладывать: крупные почтовые провайдеры уже сделали эти записи обязательными для массовых отправителей. Google и Yahoo требуют SPF, DKIM и DMARC от массовых отправителей с февраля 2024 года (у Google порог — около 5000 писем в сутки на адреса Gmail; Yahoo точный порог не называет). Microsoft подключил похожие правила для Outlook.com, Hotmail и Live с мая 2025 года. Если рассылки от вашего домена не проходят проверку, они рискуют осесть в спаме или вовсе не дойти.
SPF: кто имеет право отправлять письма от вашего домена
SPF (Sender Policy Framework) — это список серверов, которым разрешено слать письма от вашего домена. Он лежит в DNS в виде TXT-записи.
Проверка идет так: письмо приходит на чужой сервер, тот берет домен из конверта, запрашивает у DNS его SPF-запись и сверяет IP-адрес отправителя со списком разрешенных. На выходе получаем один из результатов:
- pass — сервер в списке, все в порядке;
- fail — сервера в списке нет, запись прямо запрещает такие письма;
- softfail — сервера нет, но запись просит не блокировать жестко, а отнестись с подозрением (обычно письмо уходит в спам);
- neutral — домен ничего конкретного не говорит про этот сервер;
- none — у домена вообще нет SPF-записи.
Из чего состоит SPF-запись
Проще всего разобрать на примере. Вот типичная запись:
v=spf1 include:_spf.google.com ip4:203.0.113.10 ~all
Читается слева направо:
Хвост all — это правило для всех, кого не перечислили выше, и у него есть квалификатор:
- -all — жесткий запрет (fail). Все, что не в списке, — подделка.
- ~all — мягкий вариант (softfail). Подозрительно, но не блокируем совсем.
- ?all — нейтрально, почти как отсутствие правила.
- +all — разрешить всем. Фактически это значит «отправлять от моего домена может кто угодно», то есть запись, которая не защищает ни от чего.
На старте обычно ставят ~all: пока не уверены, что перечислили всех своих отправителей. Когда убедились, что ничего не забыли, переходят на -all.
Как добавить SPF-запись в DNS
SPF-запись добавляют там же, где живут остальные DNS-записи домена: в панели регистратора, хостинга или, например, Cloudflare.
Параметры записи:
- Тип — TXT.
- Имя (хост) — @, то есть сам домен.
- Значение — строка v=spf1 ….
- TTL — время кеширования; можно оставить значение по умолчанию.
Одно правило важнее остальных: SPF-запись на домене должна быть ровно одна. Две записи v=spf1 не складываются, а ломают проверку — это одна из самых частых ошибок. Если нужно добавить еще один сервис, его дописывают в существующую запись через include, а не заводят вторую.
Чего SPF не умеет
SPF полезен, но в одиночку не защищает от всех угроз, потому что:
- Ограничен десятью DNS-запросами. Каждый include (а внутри него бывают вложенные) тратит запрос. Когда их набирается больше десяти, проверка возвращает ошибку permerror и SPF перестает работать. Для компаний с десятком внешних сервисов это реальная проблема.
- Ломается при пересылке. Если получатель настроил автопересылку на другой ящик, письмо уходит уже с сервера-пересыльщика, которого нет в вашем SPF. Проверка не проходит, хотя письмо честное.
- Не смотрит на видимый From. Тот самый главный изъян: SPF проверяет конверт, а человек читает заголовок. Можно пройти SPF и все равно обмануть человека подделкой видимого адреса.
DKIM: подпись, которая доказывает, что письмо не подменили
DKIM (DomainKeys Identified Mail) подтверждает, что письмо действительно отправлено вашим доменом и никто не переписал его в процессе.
Работает это на паре ключей. Отправляющий сервер берет закрытый (приватный) ключ и подписывает им письмо — заголовки и тело. Подпись он вставляет прямо в служебный заголовок DKIM-Signature. Открытый (публичный) ключ вы заранее кладете в DNS. Получатель достает подпись, забирает из DNS открытый ключ и проверяет: сходится — письмо не трогали, не сходится — где-то подменили содержимое.
Селектор и запись в DNS
Открытый ключ в DNS лежит не в корне домена, а по адресу вида селектор._domainkey.домен. Селектор — это метка, которая позволяет держать несколько ключей сразу. Например, один — для корпоративной почты, другой — для сервиса рассылок. Какой ключ использовать для конкретного письма, получатель понимает из заголовка DKIM-Signature: там указаны домен (d=) и селектор (s=).
Сама запись — снова TXT и выглядит примерно так:
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ…
Здесь v — версия, k — тип ключа (обычно RSA), p — сам открытый ключ длинной строкой.
Как включить DKIM
В корпоративной почте и сервисах рассылок ключи обычно генерируются автоматически: вы включаете DKIM в настройках, сервис выдает готовую TXT-запись, а вам остается скопировать ее в DNS. Вручную ключи создают реже, в основном на своих почтовых серверах.
На что стоит обратить внимание:
- Длина ключа. Встречаются ключи на 1024 и на 2048 бит. Второй надежнее, и его же рекомендуют крупные провайдеры — если есть выбор, берите 2048.
- Ротация ключей. Ключи полезно периодически менять: если старый закрытый ключ попал в утечку, у злоумышленника будет меньше времени им воспользоваться. Про это почти не пишут в инструкциях, но это хорошая привычка.
DMARC: что делать с письмами, которые не прошли проверку
DMARC (Domain-based Message Authentication, Reporting and Conformance) связывает SPF и DKIM в единое правило и добавляет то, чего им по отдельности не хватает: смотрит на видимый From и решает судьбу писем, которые проверку не прошли.
Ключевая идея DMARC — выравнивание. DMARC проверяет, не просто «прошел ли SPF или DKIM», а совпадает ли домен, прошедший проверку, с доменом в видимом поле From. Отсюда следует неожиданная, но частая ситуация: SPF может дать pass, а DMARC при этом — fail. Так бывает, когда рассылку шлет сторонний сервис: SPF проходит по домену сервиса, но этот домен не совпадает с вашим доменом в поле From, и выравнивание не сходится. Именно на этом чаще всего ломаются рассылки, которые «вроде настроили правильно».
Строгость выравнивания настраивается двумя параметрами: adkim (для DKIM) и aspf (для SPF). Значение r (relaxed, по умолчанию) разрешает совпадение по основному домену, s (strict) требует полного совпадения вплоть до поддомена.
Теги DMARC-записи
DMARC — тоже TXT-запись, лежит по адресу _dmarc.домен. Из чего она состоит:
Минимальная рабочая запись выглядит так:
v=DMARC1; p=none; rua=mailto:dmarc@ваш-домен.ru
Как внедрять политику поэтапно
Главное правило: не ставьте p=reject сразу. Жесткая политика без подготовки — надежный способ отправить в спам собственные же письма, о которых вы забыли. Правильный порядок такой:
- p=none — режим наблюдения. Письма никто не блокирует, но вам начинают приходить отчеты о том, кто и как отправляет почту от вашего домена.
- Собрать и прочитать отчеты. Обычно за пару недель становится видно всех легальных отправителей — в том числе тех, про кого вы не помнили.
- p=quarantine с ростом pct. Подозрительные письма уходят в спам. Через pct можно включать политику постепенно: сначала для части писем, потом для всех.
- p=reject — финальная стадия. Письма, не прошедшие проверку, отклоняются совсем. К ней переходят, когда уверены, что все свои отправители настроены.
Отчеты DMARC
Отчеты по тегу rua приходят почтой в виде XML-файлов в архивах. Внутри сводка: с каких IP-адресов шли письма от вашего домена, сколько их было и проходили ли они SPF и DKIM. Смотреть в первую очередь стоит на две вещи: появились ли незнакомые отправители (возможная подделка) и есть ли среди «провалившихся» ваши же легальные сервисы, которые вы забыли настроить.
Разбирать XML руками необязательно — существуют парсеры, которые превращают отчеты в понятные таблицы и графики.
Как SPF, DKIM и DMARC работают вместе
Проще всего запомнить так: три записи отвечают на три разных вопроса.
SPF — с правильного ли сервера пришло письмо?
DKIM — не изменили ли письмо по дороге?
DMARC — что делать, если ответы не сошлись, и куда прислать отчет?
| Запись | Что проверяет | Где хранится | Что будет, если не настроить |
| SPF | Разрешен ли сервер-отправитель | TXT-запись в корне домена | С вашего домена смогут слать письма чужие серверы |
| DKIM | Не подменили ли содержимое письма | TXT-запись селектор._domainkey.домен | Нельзя доказать, что письмо не переписали в пути |
| DMARC | Совпадает ли все это с видимым From и как поступать с нарушителями | TXT-запись _dmarc.домен | Подделки видимого адреса дойдут до людей, отчетов не будет |
Чем-то одним ограничиться нельзя. SPF не смотрит на видимый From, DKIM сам по себе никого не блокирует, а DMARC без первых двух нечего проверять. Защита появляется, только когда работают все три.
Пошаговая настройка: чек-лист для домена
Порядок действий, если начинаете с нуля:
- Соберите список всех, кто отправляет письма от вашего домена. Корпоративная почта, CRM, форма на сайте, сервис рассылок, биллинг. Это первый и самый важный шаг: забытый отправитель потом попадет под вашу же политику, и его письма перестанут доходить.
- Настройте SPF — одна TXT-запись со всеми своими отправителями, в конце ~all.
- Включите DKIM для каждого сервиса, который шлет письма, и добавьте выданные записи в DNS.
- Опубликуйте DMARC с p=none и укажите rua для отчетов.
- Соберите отчеты, найдите отправителей, которых упустили, и допишите их в SPF и DKIM.
- Ужесточите политику — переведите DMARC в quarantine, затем в reject, а SPF — с ~all на -all.
Оговорка про DNS: изменения расходятся по серверам не мгновенно, иногда на это уходит несколько часов. Если проверка сразу не видит новую запись — подождите и повторите.
Как проверить, что записи работают
Надежнее всего отправить письмо самому себе и заглянуть в его исходник. В служебном заголовке Authentication-Results сразу видно вердикт по всем трем проверкам: spf=pass dkim=pass dmarc=pass. Если появился fail — значит, эту запись еще надо чинить.
Где искать исходник:
- Gmail — открыть письмо → «⋮» → «Показать оригинал».
- Во многих других клиентах команда называется «Показать оригинал», «Исходный текст» или View source.
Кроме исходника есть онлайн-сервисы. Например, mail-tester: вы отправляете письмо на выданный им адрес и получаете оценку с разбором SPF, DKIM, DMARC и других факторов. MXToolbox проверяет сами записи по домену. Такие сервисы удобны, но относиться к их «баллам» стоит спокойно — они оценивают доставляемость в целом, а не только три наши записи.
Кому удобнее консоль — записи быстро смотрятся командами: nslookup -type=txt на Windows или dig txt на Linux и VPS.
Частые ошибки при настройке SPF, DKIM и DMARC
Большинство проблем — из-за мелочей. Собрали в таблицу те, что встречаются чаще всего.
Отдельная, самая обидная ситуация: все три записи настроены правильно, а письма все равно попадают в спам. Аутентификация — не единственное, на что смотрят почтовые провайдеры. Проверьте еще:
Репутацию IP и домена. Если с адреса раньше слали спам или домен новый и холодный, письма будут придирчиво фильтровать.
Обратную DNS-запись (PTR). У отправляющего сервера должно быть корректное обратное имя. Ее отсутствие — тревожный сигнал для провайдера.
Ссылку на отписку. Для рассылок нужен заголовок для отписки в один клик — без него письма легко улетают в спам, а у массовых отправителей это еще и обязательное требование.
Резкий рост объемов. Если вчера уходило 50 писем, а сегодня 50 000, провайдер воспримет это как всплеск спама. Объемы наращивают плавно.
