Настройка SPF, DKIM, DMARC: письма доходят
Три записи, три разные задачи
SPF — кто имеет право отправлять от вашего имени — TXT-запись на вашем домене, перечисляющая почтовые серверы, которым разрешено отправлять письма от вашего имени. Принимающий сервер сверяет реальный источник со списком; несовпадение — сильный сигнал, хотя сам по себе и не повод для мгновенного отклонения, — что письмо, возможно, не настоящее.
DKIM — доказательство, что ничего не подделано — отправляющий сервер криптографически подписывает каждое сообщение закрытым ключом, которым владеет только он; соответствующий открытый ключ опубликован в вашем DNS. Действительная подпись доказывает сразу две вещи: сообщение отправил обладатель вашего ключа, и ничего не было изменено в пути после подписания.
DMARC — политика, которая связывает их вместе — определяет, должны ли SPF и DKIM совпадать с доменом в видимом адресе «От», говорит принимающим серверам, что делать, если сообщение не проходит обе проверки (ничего не делать, поместить в карантин или отклонить), и запрашивает периодические отчёты о том, что отправляется от вашего имени — прошло проверку или нет.
Откуда на самом деле берутся эти записи
Узнайте, что на самом деле отправляет вашу почту
Не хостинг вашего сайта, а тот почтовый сервис или сервис отправки, с которого письмо действительно уходит: Google Workspace, Microsoft 365, Zoho, Proton или подобный.
Опубликуйте SPF для этого отправителя
Ваш почтовый провайдер публикует свою точную строку SPF в документации по настройке; вы вставляете её в DNS вашего домена, в той же панели, где создаёте любую другую DNS-запись.
Включите подпись DKIM у этого провайдера
Большинство провайдеров сами генерируют пару ключей и выдают точную DNS-запись для публикации — настройку DKIM ведёт провайдер, вы не собираете её вручную.
Добавьте запись DMARC, начав с режима только мониторинга
Напишите DMARC TXT-запись сами, начав с p=none, и ужесточайте её только тогда, когда отчёты подтвердят, что все ваши настоящие отправители проходят проверку чисто.
Как это устроено в Olmira
Индивидуальный SMTP для каждого клиента — это ответ Olmira именно на эту проблему: подключите собственный почтовый аккаунт под каждую задачу — транзакционные письма, маркетинг, поддержка, биллинг и другое, — и письмо реально уходит через аккаунт, который уже под вашим контролем, с адресом «от», который назначили вы. Доставляемость при этом опирается на SPF, DKIM и DMARC, которые уже есть у домена этого аккаунта: подключите настоящий рабочий почтовый ящик, с которого вы и так отправляете письма, — и его существующая аутентификация покроет и почту, отправленную через Olmira.
Важнее всего одно правило: адрес «от» для задачи должен быть на том же домене, с которого подключённому аккаунту реально разрешено отправлять, — несовпадение этих двух вещей на любой платформе является самой частой причиной сбоя, похожего на подделку письма. Задача, которую вы не настроили, просто использует собственный релей Olmira, а не проваливает отправку. Остальное про интеграции — на странице Интеграции.
Технически письмо отправится, но SPF и DKIM бесплатного почтового сервиса подтверждают его домен, а не тот, который вы указали в поле «от кого»: письмо, которое якобы отправлено с домена вашей компании, но прошло через чужие аутентифицированные серверы, обычно не проходит проверку соответствия. Настоящий почтовый ящик на собственном домене стоит завести до того, как вам понадобится выглядеть убедительно в больших объёмах.
SPF и DKIM сегодня почти обязательны — несколько крупных почтовых провайдеров уже требуют хотя бы один из них от массовых отправителей. DMARC — это то, что действительно связывает их вместе и говорит получателям, что делать при сбое проверки; пропустить его — ничего не сломается сразу, но именно эта часть превращает «аутентифицировано» в «принудительно применено».
Аутентификация доказывает, что сообщение действительно от вас; она не освобождает его от обычной фильтрации спама. Содержание, объём рассылки, вовлечённость получателей и репутация домена по-прежнему важны — сверх того, что аутентификация проходит чисто.
Та же задержка распространения DNS, что и у любой другой записи, — см. подключение DNS-записей домена, чтобы понять, что на самом деле происходит, пока вы ждёте, и почему «ещё нет» — это не то же самое, что «неверно».
Каждый настоящий источник отправки — ваш повседневный почтовый ящик, маркетинговая платформа, контактная форма на сайте — должен быть включён в одну и ту же запись SPF и, если провайдер это поддерживает, иметь собственную подпись DKIM. Пропустить один из них — самая частая причина, по которой законный инструмент вдруг начинает не проходить проверки после того, как «всё уже было настроено».