20.10.2026 16:40
hack_less 0 5300 Источник

Письмо пришло от имени знакомого сервиса. Логотип на месте, адрес отправителя выглядит убедительно, а текст не вызывает подозрений. Можно ли доверять такому сообщению?

Необязательно. Имя отправителя и оформление письма достаточно легко подделать. Поэтому почтовые серверы используют несколько механизмов проверки, которые помогают определить, действительно ли сообщение отправлено с разрешённого сервера и не было ли его содержимое изменено.

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

SPF: кому разрешено отправлять почту

SPF (Sender Policy Framework) — механизм, который позволяет владельцу домена указать, какие серверы имеют право отправлять от его имени почту.

Например, компания использует отдельный почтовый сервис. Чтобы принимающие серверы могли проверить легитимность отправителя, владелец публикует соответствующую TXT‑запись в DNS.

Упрощённый пример:

example.com. TXT "v=spf1 ip4:192.0.2.10 -all"

Здесь:

  • v=spf1 — версия SPF;

  • ip4:192.0.2.10 — разрешённый IPv4-адрес отправляющего сервера;

  • -all — остальные источники не входят в разрешённый список.

Адрес 192.0.2.10 используется исключительно как пример из диапазона, предназначенного для документации.

Когда письмо поступает получателю, почтовый сервер проверяет IP отправителя и сопоставляет его с SPF‑политикой домена, используемого при SMTP‑обмене.

Если проверка успешна, сервер получает подтверждение того, что отправляющий IP разрешён этой политикой.

Но есть нюанс: SPF не проверяет достоверность отображаемого адреса в поле From.

Злоумышленник может отправить письмо со своего сервера, используя чужой адрес в видимом поле отправителя. Если проверяется другой домен, SPF может завершиться успешно, хотя пользователь увидит знакомое имя.

Поэтому SPF — полезный, но недостаточный механизм защиты.

Типичные ошибки SPF

При настройке SPF часто встречаются следующие проблемы:

  1. Не добавлен новый почтовый сервис после смены инфраструктуры.

  2. В DNS опубликовано несколько SPF‑записей для одного имени, что может привести к ошибке проверки.

  3. Превышен лимит в десять DNS‑запросов, учитываемых SPF при обработке политики.

  4. Используется слишком мягкая политика, не соответствующая реальной конфигурации отправки почты.

Отдельная проблема — пересылка писем. После пересылки IP отправляющего сервера может измениться, из‑за чего SPF перестанет проходить, хотя исходное письмо было легитимным.

DKIM: проверяем цифровую подпись письма

DKIM (DomainKeys Identified Mail) решает другую задачу: позволяет проверить криптографическую подпись определённых частей письма и связанных с ними заголовков.

Отправляющий сервер подписывает письмо с использованием закрытого ключа. Соответствующий открытый ключ публикуется в DNS.

Пример записи открытого ключа:

selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=PUBLIC_KEY"

Здесь selector1 — селектор, который помогает определить нужный ключ, а p=PUBLIC_KEY — условное обозначение открытого ключа. В реальной записи вместо него находится длинное значение.

При получении письма сервер читает заголовок DKIM-Signature, находит указанный селектор и получает открытый ключ из DNS. Затем он проверяет подпись.

Если проверка проходит успешно, это означает, что подпись соответствует проверяемому содержимому и открытому ключу.

Важно понимать: DKIM не гарантирует, что письмо написано человеком, которому можно доверять. Злоумышленник также может подписывать письма собственным доменом.

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

Как выглядит DKIM в заголовках

Упрощённый пример:

DKIM-Signature: v=1; a=rsa-sha256;
 d=example.com; s=selector1;
 h=from:to:subject:date;
 bh=BODY_HASH; b=SIGNATURE

Основные параметры:

  • d — домен, от имени которого сформирована подпись;

  • s — селектор ключа;

  • h — список заголовков, включённых в подпись;

  • bh — хеш тела сообщения;

  • b — криптографическая подпись.

Значения BODY_HASH и SIGNATURE здесь условные.

При изменении подписанного содержимого проверка может завершиться неудачей. Однако успешный DKIM сам по себе не говорит о том, что письмо безопасно: он подтверждает определённые свойства подписи, а не добросовестность отправителя.

DMARC: связываем SPF и DKIM с адресом отправителя

SPF и DKIM решают отдельные задачи, но для защиты от подмены адреса требуется ещё один уровень проверки.

DMARC (Domain‑based Message Authentication, Reporting and Conformance) использует результаты SPF и DKIM и проверяет их согласованность с доменом в видимом поле From.

Предположим, пользователь получает письмо:

From: support@example.com

При этом технический домен отправки может отличаться. Это нормально для некоторых почтовых сервисов, но важно, чтобы выполнялись правила согласования доменов DMARC.

Для успешного DMARC достаточно, чтобы прошла хотя бы одна из двух проверок — SPF или DKIM — и соответствующий домен был согласован с доменом из From.

Это ключевой момент: DMARC не требует одновременного успеха SPF и DKIM.

Пример DMARC‑записи

_dmarc.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

Разберём параметры:

  • v=DMARC1 — версия протокола;

  • p=quarantine — рекомендуемая политика для писем, не прошедших DMARC;

  • rua — адрес для получения агрегированных отчётов, если принимающий сервис поддерживает их отправку.

У DMARC есть три основные политики:

Политика

Назначение

p=none

Собирать данные и наблюдать за результатами проверок

p=quarantine

Просить получателей помещать не прошедшие проверку сообщения в карантин, например в спам

p=reject

Просить отклонять такие сообщения

Политика DMARC — это указание принимающему серверу, а не абсолютная гарантия конкретного поведения. Обработка может зависеть от реализации и дополнительных обстоятельств.

Обычно настройку начинают с мониторинга, анализируют отчёты и только после проверки всех легитимных источников отправки постепенно ужесточают политику.

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

Практика: читаем результаты аутентификации

Теперь разберём пример, который можно встретить в заголовках полученного письма.

Откройте оригинал сообщения или его полные заголовки в почтовом клиенте. Ищите поле Authentication-Results, сформированное принимающим сервером.

Например:

Authentication-Results: mx.example.net;
 spf=pass smtp.mailfrom=bounce.example.com;
 dkim=pass header.d=example.com;
 dmarc=pass header.from=example.com

Это условный пример, а не результат проверки реального письма.

Что он означает?

SPF: pass

IP отправляющего сервера прошёл проверку относительно домена bounce.example.com. Но одного этого результата недостаточно: домен SPF должен быть согласован с доменом From по правилам DMARC, чтобы SPF участвовал в успешной DMARC‑проверке.

DKIM: pass

Подпись успешно проверена, а в примере она связана с доменом example.com. Если домен подписи соответствует требованиям согласования DMARC, результат DKIM может обеспечить успешную проверку DMARC.

DMARC: pass

Принимающий сервер определил, что выполнены требования DMARC для домена example.com.

Такой результат — хороший признак корректной аутентификации письма. Но он не исключает компрометацию почтового ящика, злоупотребление легитимным почтовым сервисом или отправку вредоносного содержимого с настоящего домена.

На что обращать внимание при анализе

При проверке подозрительного сообщения полезно сопоставить несколько полей:

  • From — видимый адрес отправителя;

  • Return-Path — адрес обратного пути, связанный с SMTP‑конвертом;

  • Authentication-Results — результаты проверок, выполненных принимающим сервером;

  • DKIM-Signature — параметры цифровой подписи;

  • Received — сведения о прохождении письма через почтовую инфраструктуру.

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

Что делать, если SPF, DKIM и DMARC не прошли проверку

Неудачная проверка — повод для дополнительного анализа, но не автоматическое доказательство атаки.

Например, SPF может не пройти после пересылки сообщения. DKIM может сломаться из‑за изменения подписанного содержимого. DMARC может не пройти из‑за неправильно настроенного стороннего сервиса рассылок.

Для администратора почтовой инфраструктуры порядок действий может выглядеть так:

  1. Проверить DNS‑записи домена и убедиться, что все легитимные отправители учтены.

  2. Сопоставить домен из From с доменами SPF и DKIM.

  3. Проверить отчёты DMARC и выяснить, какие источники регулярно не проходят аутентификацию.

  4. Убедиться, что почтовые сервисы используют корректные подписи и актуальные настройки.

  5. После устранения проблем постепенно ужесточить DMARC‑политику.

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

Почему все три механизма нужны одновременно

SPF, DKIM и DMARC не дублируют друг друга.

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

Вместе эти механизмы значительно усложняют подмену адреса отправителя и дают администраторам полезные данные для расследования проблем с почтой.

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

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

Мы в Telegram: https://t.me/+jAjZcfEdOx42NzRi

Комментарии (0)