Письмо приходит от вашего генерального директора. Адрес правильный, подпись на месте, логотип корпоративный. Бухгалтер не глядя оплачивает приложенный счёт. А через час выясняется, что директор ничего не отправлял. Деньги ушли мошенникам.
Протокол SMTP, на котором держится вся мировая электронная почта, разрабатывался во времена, когда интернет был маленьким и все друг другу доверяли. В нём изначально нет надежного механизма проверки отправителя. Любой студент может написать короткий скрипт и отправить письмо от имени director@ваша-компания.ru.
Чтобы закрыть эту фундаментальную дыру, ИТ-индустрия внедрила три протокола, которые сегодня стали строгим стандартом: SPF, DKIM и DMARC. Настроить их нужно аккуратно, чтобы отсечь хакеров, но при этом не загнать в спам легитимные рассылки от собственного отдела продаж.
SPF: паспортный контроль для серверов
Протокол SPF (Sender Policy Framework) отвечает на один простой вопрос: «Имеет ли право этот конкретный IP-адрес отправлять письма от имени нашего домена?».
Вы создаете обычную TXT-запись на вашем DNS-сервере. В ней вы перечисляете все доверенные источники. Это может быть ваш локальный почтовый сервер (например, MS Exchange), корпоративный портал или облачный сервис массовых рассылок.
Когда ваше письмо стучится в чужой почтовик, тот лезет в ваши DNS-записи. Совпал IP-адрес отправителя со списком из SPF — письмо проходит. Не совпал — получает огромный минус в карму.
Тут важен синтаксис. В конце записи всегда стоит механизм обработки. Мягкий отказ ~all просто пометит письмо от чужака как подозрительное. Жёсткий отказ -all прикажет принимающей стороне немедленно уничтожить пакет. На старте внедрения всегда используйте тильду, чтобы не потерять важную почту из-за ошибок в настройках.
DKIM: криптографическая печать
У SPF есть серьезный недостаток. Он ломается при банальной пересылке. Письмо ушло с вашего сервера, попало на промежуточный узел связи, а оттуда улетело финальному адресату. Для конечного сервера отправителем будет выступать этот промежуточный узел. Естественно, его IP-адреса нет в вашем списке, и проверка SPF с треском провалится.
Здесь спасает DKIM (DomainKeys Identified Mail). Это настоящая цифровая подпись.
Вы генерируете пару ключей. Закрытый ключ живет глубоко на вашем почтовом сервере и незаметно подписывает каждое исходящее письмо. Открытый ключ вы вешаете в публичный доступ в виде еще одной DNS-записи.
Теперь пересылка не страшна. Даже если письмо пройдет через десяток чужих серверов, криптографическая подпись в заголовке останется неизменной. Получатель расшифрует её вашим открытым ключом и убедится, что текст письма и вложения никто не модифицировал в пути.
DMARC: главный надзиратель
SPF и DKIM — отличные технологии, но они не умеют отдавать жесткие приказы. Что делать чужому серверу, если подпись DKIM сошлась, а проверка SPF провалилась?
Политику поведения диктует DMARC. Это текстовая запись, которая связывает проверки воедино. Она четко говорит принимающим серверам, как именно наказывать самозванцев.
| Режим | Значение в DNS | Что происходит с письмом |
|---|---|---|
| Мониторинг | p=none | Письмо доставляется пользователю. Владелец домена просто получает отчеты о подделках. |
| Карантин | p=quarantine | Письмо, не прошедшее проверки, принудительно улетает в папку «Спам». |
| Отклонение | p=reject | Чужой сервер сбрасывает соединение. Письмо удаляется на подлете. |
Как внедрять и не сломать бизнес
Самая частая ошибка системных администраторов — сразу влепить политику p=reject. На следующий день выясняется, что отдел маркетинга использует сторонний сервис для отправки коммерческих предложений, а HR-отдел рассылает офферы через облачную CRM. Никто не добавил их адреса в SPF, и теперь все эти критически важные для бизнеса письма летят в мусорную корзину.
Правильный путь выглядит иначе. Сначала вы настраиваете SPF и генерируете ключи DKIM. Затем включаете DMARC в режиме p=none и указываете свой адрес для получения ежедневных RUA-отчетов.
Несколько недель вы просто изучаете эти XML-отчеты. Вы с удивлением обнаружите десятки легитимных сервисов, которые отправляют почту от вашего имени. Вы аккуратно добавляете их IP-адреса в SPF и прописываете для них отдельные ключи DKIM. И только когда в отчетах останется исключительно хакерский мусор, вы переводите рубильник в режим карантина, а затем — в жёсткий отказ.
Частые вопросы
Можно ли обойтись только настройкой SPF, чтобы не возиться с ключами DKIM?
Технически можно, но это плохая идея. Крупные почтовые провайдеры (Google, Yahoo, Mail.ru) радикально ужесточили правила. Если вы делаете массовые рассылки или отправляете транзакционные письма клиентам, наличие связки SPF + DKIM + DMARC стало строго обязательным. Без цифровой подписи ваши письма рано или поздно начнут молча срезаться спам-фильтрами.
Что такое DMARC Alignment (выравнивание) и зачем оно нужно?
Это защита от хитрой подмены заголовков. Мошенник может отправить письмо со своего сервера и даже подписать его своим валидным ключом DKIM. Проверки пройдут. Но в поле «От кого» (From), которое видит ваш сотрудник, он впишет адрес генерального директора. Выравнивание DMARC проверяет, чтобы домен, указанный в служебных технических заголовках, строго совпадал с тем доменом, который реально отображается на экране пользователя.
Мы всё настроили идеально по зеленой зоне, но письма всё равно идут в спам. Почему?
Тройка SPF, DKIM и DMARC подтверждает только вашу личность. Она доказывает антиспам-системам, что вы — это действительно вы. Но она ничего не говорит о качестве вашего контента. Если ваш отдел продаж делает холодные рассылки по купленным базам с кликбейтными темами, получатели будут массово нажимать кнопку «Это спам». Репутация вашего подтвержденного домена рухнет, и фильтры начнут блокировать вас именно за плохой контент, а не за технические настройки.