SPF, DKIM и DMARC: почему ваши письма попадают в спам

Вы отправляете коммерческое предложение, а клиент говорит: «Ваше письмо так и не пришло». Позже он находит его в папке «Спам». Чаще всего проблема не в содержании письма, а в настройках аутентификации вашего домена. Если принимающий сервер не может убедиться, что письмо действительно отправили вы, он считает его подозрительным.

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

Почему письма попадают в спам?

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

Чтобы бороться с этим, крупные сервисы, такие как Gmail, Outlook и Yahoo, проверяют каждое входящее письмо: разрешено ли этому серверу отправлять почту от имени этого домена? Не было ли письмо изменено по пути? Что владелец домена просит делать с письмами, не прошедшими эти проверки? Ответы на эти три вопроса — SPF, DKIM и DMARC.

Аутентификация — не единственный фактор. Свою роль играют репутация IP-адреса отправителя, чёрные списки, содержание и то, как часто получатели отмечают ваши письма как спам. Но без правильно настроенных SPF, DKIM и DMARC доставляемость остаётся низкой, даже если всё остальное в порядке.

SPF: кто может отправлять почту от моего имени?

SPF (Sender Policy Framework) — это список серверов, которым разрешено отправлять почту от имени вашего домена. Он публикуется в DNS домена в виде TXT-записи. Принимающий сервер проверяет, есть ли в этом списке сервер, отправивший письмо.

Пример SPF-записи выглядит так:

companyname.com TXT "v=spf1 mx include:spf.provider.com ip4:203.0.113.10 ~all"

• v=spf1: указывает, что это SPF-запись.
• mx: отправлять почту могут MX-серверы домена.
• include: подключает список другого провайдера, например вашего почтового сервиса или сервиса рассылок.
• ip4: разрешает конкретный IP-адрес, например сервер приложений в вашем офисе.
• ~all: означает «считать подозрительным всё, чего нет в списке». -all означает «отклонять».

DKIM: не было ли письмо изменено по пути?

DKIM (DomainKeys Identified Mail) добавляет цифровую подпись к каждому отправляемому письму. Подпись создаётся закрытым ключом, который хранится на вашем почтовом сервере. Соответствующий открытый ключ публикуется в DNS. Принимающий сервер проверяет подпись с помощью открытого ключа и убеждается, что письмо действительно пришло с вашего сервера и не было изменено по пути.

Пример DKIM-записи:

mail2026._domainkey.companyname.com TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...long-public-key..."

• mail2026: селектор. Он позволяет использовать для одного домена несколько ключей.
• k=rsa: тип ключа.
• p=: сам открытый ключ. Это значение генерирует ваш почтовый провайдер, вам остаётся лишь добавить его в DNS.

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

DMARC: что происходит, если проверки не пройдены?

DMARC (Domain-based Message Authentication, Reporting and Conformance) — это уровень политик, связывающий SPF и DKIM. Он выполняет две задачи:

• Сообщает принимающим серверам, что делать с письмами, не прошедшими аутентификацию.
• Присылает вам отчёты о том, кто отправляет почту от имени вашего домена.

DMARC также проверяет выравнивание (alignment): домен, подтверждённый SPF или DKIM, должен совпадать с доменом в адресе «От», который видит получатель. Так никто не сможет пройти проверку SPF с другим доменом и при этом выдавать себя за ваш адрес.

Пример DMARC-записи:

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

Политики DMARC

• p=none: только мониторинг. С непрошедшими письмами ничего не происходит, но отчёты приходят. Это отправная точка.
• p=quarantine: непрошедшие письма попадают в папку «Спам».
• p=reject: непрошедшие письма полностью отклоняются. Это самая сильная защита от подделки вашего домена.

Пошаговое внедрение

1. Проведите инвентаризацию. Перечислите всё, что отправляет почту от имени вашего домена: корпоративная почта, программа электронных счетов-фактур, CRM, сервис рассылок, формы на сайте, принтеры и сканеры.
2. Создайте единую SPF-запись. Соберите все эти источники в одной записи и начните с ~all.
3. Включите DKIM. Получите DKIM-ключи у почтового провайдера и других сервисов-отправителей и добавьте их в DNS.
4. Опубликуйте DMARC в режиме мониторинга. Начните с p=none и укажите адрес для отчётов.
5. Изучайте отчёты несколько недель. В этих отчётах проявятся забытые источники отправки. Добавьте их в SPF и DKIM.
6. Постепенно ужесточайте политику. Когда вся легитимная почта будет проходить проверки, перейдите к quarantine, а затем к reject. Чтобы смягчить переход, можно с помощью параметра DMARC pct сначала применять политику лишь к части писем.

Распространённые ошибки

Больше одной SPF-записи

У домена может быть только одна SPF-запись. Добавление второй записи «v=spf1» для нового сервиса вместо обновления существующей — очень частая ошибка, из-за которой обе записи становятся недействительными.

Лимит в 10 DNS-запросов

Проверка SPF может выполнить не более 10 DNS-запросов. В этот лимит засчитываются все механизмы include, mx и a, в том числе вложенные include. По мере добавления сервисов лимит превышается, и проверка SPF возвращает ошибку. Удалите сервисы, которыми больше не пользуетесь, и, где уместно, указывайте фиксированные IP-адреса через ip4.

Запуск DMARC сразу с reject

Переход к политике reject до завершения инвентаризации может привести к отклонению легитимных писем, например счетов или уведомлений. Всегда начинайте с режима мониторинга.

DKIM включён только у основного провайдера

Сторонние сервисы — рассылки и CRM — тоже должны подписывать письма от имени вашего домена собственными DKIM-ключами. Иначе выравнивание DMARC не пройдёт.

Адрес для отчётов никто не читает

Отчёты DMARC приходят в формате XML и могут быть объёмными. Нужен инструмент, который делает их читаемыми, или ответственный, который регулярно их просматривает.

Одной аутентификации недостаточно

Даже при правильно настроенных SPF, DKIM и DMARC письма иногда всё равно попадают в спам. Следите также за следующим:

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

Требования крупных почтовых сервисов к отправителям

С начала 2024 года Google и Yahoo применяют к отправителям более строгие правила, а Microsoft объявила об аналогичных требованиях для Outlook.com. Общие рамки таковы:

• От всех отправителей ожидается использование как минимум SPF или DKIM, наличие корректной обратной DNS-записи и подключение по TLS.
• Массовые отправители (по определению Google — те, кто отправляет более 5,000 писем в день на адреса Gmail) должны иметь SPF, DKIM и запись DMARC с политикой не ниже p=none, а адрес «От» должен быть выровнен.
• Маркетинговые письма должны предлагать отписку в один клик и поддерживать низкий уровень жалоб на спам.

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

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

Часто задаваемые вопросы

Достаточно ли настроить что-то одно из SPF, DKIM и DMARC?

Нет. Все три работают вместе. SPF и DKIM подтверждают подлинность, а DMARC проверяет, что это подтверждение соответствует адресу «От», и решает, что делать, если проверка не пройдена.

Я добавил записи. Когда изменения вступят в силу?

DNS-записи обычно распространяются в течение нескольких минут — нескольких часов. Репутации домена может потребоваться чуть больше времени на восстановление; при регулярной и корректной отправке улучшения обычно заметны в течение нескольких дней или недель.

Как проверить, что записи настроены правильно?

Отправьте письмо на свой адрес Gmail и с помощью функции «Показать оригинал» посмотрите результаты проверок SPF, DKIM и DMARC. Онлайн-инструменты проверки DNS также укажут на синтаксические ошибки в записях.

Не заблокирует ли политика DMARC reject мою легитимную почту?

Нет, если инвентаризация полная и каждый источник отправки выровнен через SPF или DKIM. Именно поэтому так важно изучить отчёты в режиме мониторинга перед переходом к reject.

Корпоративная почта CloudRUX

Настройка SPF, DKIM и DMARC может выглядеть как пара DNS-записей, но доставляемость решают детали. С корпоративной почтой CloudRUX наши инженеры настраивают эти записи в рамках подключения, сопровождают вас при внедрении DMARC, а если что-то пойдёт не так, на связи будет инженер, говорящий на русском и турецком языках. Тарифы — от 1.19 USD за пользователя в месяц (без НДС), настройка и миграция бесплатно. Подробности — на странице корпоративной почты; также вы можете связаться с нами, чтобы вместе разобраться с проблемами доставки ваших писем.