У вас настроены SPF и DKIM, но письмо от вашего имени всё равно может попасть во "Входящие"
Наличие SPF, DKIM и даже DMARC в DNS ещё не означает, что злоумышленник не сможет отправить письмо с вашим адресом в поле отправителя. Эти технологии проверяют разные параметры сообщения, а полноценную защиту от подмены адреса обеспечивает только их правильная связка и строгая политика обработки подозрительных писем.
Показательный случай: письмо было отправлено якобы с адреса самой компании на её же домен. Оно успешно попало во "Входящие", отображалось с корректным именем отправителя и не получило никаких предупреждений. При проверке выяснилось, что SPF присутствует, DKIM работает, а запись DMARC опубликована. Формально всё было настроено, но защита фактически не применялась.
Почему SPF не защищает поле From
В электронном письме существуют два адреса отправителя.
Первый - технический, или конвертный. Он передаётся во время SMTP-сеанса и известен как `MAIL FROM` или `Return-Path`. На него отправляются уведомления о недоставке. В обычном почтовом интерфейсе пользователь этот адрес, как правило, не видит.
Второй адрес находится в заголовке `From`. Именно он отображается в почтовом клиенте и создаёт у получателя впечатление, что письмо пришло от конкретного человека или организации.
SPF проверяет только конвертный адрес. В DNS публикуется перечень серверов, которым разрешено отправлять почту от имени домена, указанного в `MAIL FROM`. Заголовок `From` при этом напрямую не анализируется.
Злоумышленник может использовать собственный домен в конвертной части письма. Его SPF успешно пройдёт, поскольку отправка действительно выполняется с разрешённого сервера. Одновременно в видимом заголовке `From` можно указать адрес вашей компании. Для SPF такая конструкция будет корректной: он проверял другой домен.
Если конвертный адрес пустой, как бывает при отправке уведомлений о недоставке, SPF проверяет доменное имя, переданное сервером в команде `HELO` или `EHLO`.
Что именно проверяет DKIM
DKIM добавляет к письму криптографическую подпись. Она подтверждает, что сообщение подписал сервер, имеющий доступ к закрытому ключу соответствующего домена, а содержимое письма после подписания не изменялось.
Обычно заголовок `From` включается в область подписи. Однако сама по себе корректная DKIM-подпись ещё не доказывает, что письмо отправлено именно вашей организацией. Сообщение может быть подписано доменом злоумышленника, а в видимом `From` при этом будет указан ваш адрес.
Таким образом, SPF и DKIM способны успешно пройти проверку, не подтверждая соответствие отображаемого отправителя реальному домену отправки.
Как DMARC связывает проверки
DMARC добавляет к результатам SPF и DKIM понятие выравнивания, или alignment. Домен, прошедший проверку, должен совпадать с доменом в заголовке `From`.
При этом письмо считается прошедшим DMARC, если выполнено хотя бы одно из условий:
- SPF успешно пройден и домены выровнены;
- DKIM успешно пройден и домены выровнены.
Обе проверки одновременно не обязательны. Достаточно одной корректной и согласованной проверки.
Именно DMARC позволяет принимающему серверу понять, что технически валидное письмо действительно связано с доменом, который видит пользователь.
Что означает политика p=none
Основные параметры DMARC задаются в DNS-записи:
- `p=` - политика для основного домена;
- `sp=` - отдельная политика для поддоменов;
- `rua=` - адрес для агрегированных отчётов;
- `ruf=` - адрес для подробных отчётов по отдельным сообщениям;
- `pct=` - доля писем, к которым применяется политика;
- `adkim=` и `aspf=` - режим строгости выравнивания DKIM и SPF.
Значение `p=none` часто ошибочно воспринимают как включённую защиту. На самом деле оно означает: проверять письма и отправлять отчёты, но не применять к нарушителям никаких санкций. Подозрительное сообщение будет доставлено обычным образом - в том числе во "Входящие".
Режим `none` полезен на этапе внедрения. Он помогает обнаружить все легитимные источники отправки: корпоративную почту, сервисы рассылок, CRM, бухгалтерские системы, платформы поддержки, мониторинг и другие внешние приложения. Но если оставить его навсегда, запись DMARC будет выполнять преимущественно диагностическую функцию.
Чем отличаются quarantine и reject
После проверки инфраструктуры можно перейти к более строгим политикам:
- `p=quarantine` - письмо с нарушением рекомендуется отправить в спам или пометить как подозрительное;
- `p=reject` - принимающий сервер должен отклонить сообщение.
Параметр `pct` требует особого внимания. Например, `p=reject; pct=20` не означает, что 20% сообщений будут отклонены, а остальные доставлены. Для части писем применяется указанная политика, а для остальных используется более мягкое действие - обычно `quarantine`. Поэтому при неполном покрытии письма не обязательно будут отвергнуты.
Стандартное значение `pct` - 100. Временное снижение параметра допустимо при постепенном внедрении, но после завершения тестирования его необходимо вернуть к полному покрытию.
Проверка поддоменов
Политика основного домена и политика поддоменов - не одно и то же. За поведение поддоменов отвечает параметр `sp=`. Если он не задан, поддомены обычно наследуют основную политику, но рассчитывать на это без проверки не стоит.
Например, для домена может быть установлено `p=reject`, а для поддоменов явно задано `sp=none`. В таком случае письма с поддоменов продолжат приниматься без жёсткой фильтрации. Обратная ситуация также возможна: политика главного домена мягкая, а для поддоменов задано отдельное строгое правило.
Если поддомен используется для рассылок, уведомлений или тестовых систем, его следует анализировать отдельно. Нельзя автоматически считать, что защита основного домена одинаково распространяется на всю почтовую инфраструктуру.
Что означает strict и relaxed
Параметры `adkim` и `aspf` определяют требования к совпадению доменов.
При режиме `r` - relaxed - учитывается организационный домен. Например, отправитель с `mail.example.com` может считаться выровненным с `example.com`.
При режиме `s` - strict - требуется полное совпадение доменных имён. В таком случае `mail.example.com` и `example.com` уже не будут считаться одинаковыми.
Relaxed-режим удобнее для сложной инфраструктуры, где почта отправляется с разных поддоменов. Strict обеспечивает более жёсткую защиту, но требует точного проектирования всех сервисов и адресов отправки.
Почему нельзя сразу включать reject
Резкий переход к `p=reject` может нарушить легитимную переписку. Письма иногда отправляются через сервисы, о которых администратор не знает: маркетинговые платформы, системы электронного документооборота, тикетные системы, облачные приложения и автоматические уведомления.
Если такие источники не настроили SPF, DKIM или выравнивание доменов, их сообщения будут выглядеть как поддельные. После включения `reject` они начнут отклоняться, хотя отправляются самой компанией.
Правильный порядок выглядит так:
1. опубликовать DMARC с `p=none`;
2. подключить агрегированные отчёты;
3. составить перечень всех легитимных отправителей;
4. настроить для них SPF и DKIM;
5. проверить выравнивание с доменом из `From`;
6. временно использовать `quarantine`;
7. после стабилизации перейти к `reject`;
8. регулярно контролировать отчёты и изменения инфраструктуры.
Что проверить администратору
В первую очередь нужно посмотреть не только наличие DNS-записей, но и фактическое поведение почты:
- какой домен указан в `MAIL FROM`;
- какой домен использует DKIM-подпись;
- совпадает ли он с доменом в `From`;
- какая политика указана в `p`;
- задано ли отдельное значение `sp`;
- не занижен ли `pct`;
- поступают ли агрегированные отчёты;
- не осталось ли неизвестных сервисов, отправляющих почту от имени компании;
- используется ли strict или relaxed alignment;
- не истёк ли срок действия DKIM-ключей;
- не содержит ли SPF слишком много вложенных DNS-запросов.
Также важно проверять реальные заголовки полученных писем, а не ограничиваться просмотром DNS. Только заголовки показывают, какие именно проверки выполнил принимающий сервер и с какими доменами он сравнивал результаты.
Главный вывод
SPF подтверждает разрешение на отправку для технического адреса, DKIM проверяет целостность и подлинность подписи, а DMARC связывает эти результаты с видимым адресом `From` и задаёт дальнейшее действие.
Запись DMARC сама по себе не означает, что поддельные письма будут заблокированы. Если в ней установлено `p=none`, домен получает отчёты, но продолжает принимать сообщения, не прошедшие проверку. Реальная защита начинается только после настройки выравнивания и перехода к `quarantine` или `reject` с учётом всех законных источников корпоративной почты.