Настройка домена для рассылки: SPF, DKIM, DMARC, MTA-STS, ARC, rDNS

Зачем это всё и что проверяет почтовик

Электронная почта была придумана как доверчивый протокол: в SMTP можно указать любой адрес отправителя. Именно поэтому поверх него навесили слой проверок. Когда письмо приходит на сервер Gmail или Яндекса, тот за доли секунды отвечает себе на три вопроса: имел ли право этот сервер отправлять от имени домена (SPF), не подменили ли содержимое по дороге (DKIM) и что делать, если проверки не прошли (DMARC). Плюс несколько дополнительных сигналов — шифрование канала (MTA-STS), сохранность подписи при пересылке (ARC) и обратная зона IP-адреса (rDNS).

Практический смысл простой. С февраля 2024 года Google и Yahoo требуют SPF, DKIM и DMARC от всех, кто отправляет заметные объёмы; Mail.ru и Яндекс двигаются в ту же сторону и уже сейчас режут письма без DKIM. Домен без записей — это отправитель без документов: его не обязательно заблокируют, но и во «Входящие» пустят неохотно. При этом настройка домена для рассылки — разовая работа на два-три часа, которая потом годами влияет на то, доходят ли ваши письма.

Записи в DNS не улучшают письмо. Они дают почтовику право вам доверять — а дальше репутацию вы зарабатываете поведением получателей.

SPF-запись: кто имеет право отправлять от вашего домена

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

Разберём по частям:

• v=spf1 — версия, всегда в начале.
• include: — подключает список серверов вашего почтового провайдера или сервиса рассылки. Каждый сервис публикует свой include в документации.
• ip4: / ip6: — конкретные адреса ваших собственных серверов.
• ~all — softfail: письма с других адресов помечаются подозрительными, но не отклоняются. -all — hardfail, жёстче и правильнее, но только когда вы уверены, что перечислили всех отправителей.

Три правила, которые ломают SPF чаще всего

• Одна запись на домен. Две TXT-записи с v=spf1 дают ошибку permerror — и проверка не проходит вообще. Все сервисы объединяются в одну строку.
• Лимит 10 DNS-запросов. Каждый include, a, mx — это запрос. Превысили десять — permerror. Лечится сокращением списка сервисов или SPF-флаттенингом.
• SPF не выживает при пересылке. Если получатель настроил автопересылку, IP меняется и SPF ломается. Это нормальная ситуация — именно её закрывают DKIM и ARC.

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

DKIM-подпись: криптографическая печать на письме

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

Ключевые моменты:

• Селектор (в примере — mail) позволяет держать несколько ключей одновременно: свой для корпоративной почты, свой для сервиса рассылок. Это же даёт возможность менять ключи без простоя.
• Длина ключа — минимум 1024 бита, рекомендуется 2048. Некоторые панели DNS не принимают длинную строку целиком: её разбивают на части в кавычках.
• Ротация. Ключи меняют раз в 6–12 месяцев: заводят новый селектор, переключают отправку, через неделю удаляют старый.

Ошибка DKIM-подписи в заголовках выглядит как dkim=fail или dkim=permerror. Самые частые причины: ключ скопирован с переносами строк или пробелами, в DNS попал лишний символ, запись создана не в том селекторе, домен подписи (d=) не совпадает с доменом в поле From, либо посредник по дороге меняет тело письма — например, добавляет дисклеймер или переписывает ссылки.

DMARC-запись: политика и отчёты

DMARC-запись связывает SPF и DKIM с доменом в поле From и говорит почтовику, что делать с письмами, не прошедшими проверку. Без DMARC у провайдера нет ваших инструкций — он решает на своё усмотрение.

• p=none — ничего не делать, только присылать отчёты. Стартовый режим.
• p=quarantine — отправлять подозрительные письма в спам.
• p=reject — отклонять на входе. DMARC-политика reject — цель, к которой идут: она защищает бренд от подделки писем от вашего имени.
• rua= — адрес для агрегированных отчётов. Раз в сутки вы получаете XML-сводку: кто отправлял от вашего имени, сколько писем прошло проверки.
• pct= — доля писем, к которым применяется политика. Удобно для плавного перехода: 25 → 50 → 100.
• sp= — политика для поддоменов. Если её не задать, поддомены наследуют основную политику.

Маршрут внедрения без потерь

SPF, DKIM, DMARC: отличия в одной таблице

Вопрос «SPF DKIM DMARC отличия» обычно возникает потому, что все три записи выглядят похоже — TXT в DNS. Но задачи у них разные:

MTA-STS, ARC и PTR: то, что забывают почти все

MTA-STS — шифрование не «по возможности», а обязательно

По умолчанию SMTP шифрует соединение оппортунистически: если сервер получателя не предложил TLS, письмо уйдёт открытым текстом. MTA-STS закрывает эту дыру: домен публикует политику, по которой почту принимает только через TLS с валидным сертификатом. Нужны два элемента — TXT-запись и файл политики на HTTPS-поддомене:

Режим testing позволяет обкатать политику без риска: отчёты приходят, но письма не отклоняются. Для входящей почты это в первую очередь про безопасность, но и про репутацию: крупные провайдеры учитывают поддержку TLS в оценке отправителя. Дополняет её запись TLS-RPT — отчёты о неудачных TLS-соединениях.

ARC — чтобы письмо пережило пересылку

ARC-подпись (Authenticated Received Chain) решает конкретную проблему: рассылочные списки и корпоративные шлюзы модифицируют письмо, из-за чего DKIM ломается, а DMARC с политикой reject отклоняет вполне легитимное сообщение. ARC сохраняет цепочку: каждый посредник фиксирует результаты проверок, которые он видел на входе, и подписывает их. Конечный получатель может доверять этой цепочке, даже если исходная подпись не сошлась.

Настраивается ARC на стороне почтового сервера или шлюза — отдельной DNS-записи для отправителя обычно не требуется, кроме публикации ключа, если ваш сервер сам выступает посредником. Практический вывод для бизнеса: если ваши письма часто пересылают внутри компаний-получателей, поддержка ARC у вашего провайдера — весомый аргумент при выборе.

PTR и reverse DNS — обратная зона для вашего IP

PTR-запись (она же reverse DNS для почты) связывает IP-адрес с доменным именем: обратный запрос по адресу должен вернуть имя вашего сервера, а прямой запрос этого имени — вернуть тот же IP. Это называется FCrDNS. Многие крупные провайдеры отклоняют письма с адресов без корректного PTR — просто на этапе соединения.

• Настраивает PTR владелец IP: хостинг, дата-центр или облако. Через панель DNS вашего домена это не делается.
• Имя в PTR должно быть осмысленным: mail.company.ru, а не host-203-0-113-10.provider.net.
• Если вы отправляете через облачный сервис рассылки на общем пуле IP, PTR настроен провайдером — проверьте, но менять его не нужно.

Проверка DNS-записей почты: чем и в каком порядке

Проверка почтового домена занимает десять минут и должна повторяться после каждого изменения в DNS. Порядок такой:

Типовые ошибки, из-за которых всё ломается

• Две SPF-записи. Классика при подключении нового сервиса: администратор добавляет вторую строку вместо правки существующей. Итог — permerror и провал проверки.
• DMARC сразу в reject. Без периода наблюдения вы гарантированно отрежете какой-нибудь забытый сервис — обычно это бухгалтерия или отдел кадров.
• DKIM только на основном домене. Если рассылка идёт с поддомена, ему нужен собственный ключ и селектор; SPF тоже отдельный.
• Ключ 512 бит из старой инструкции. Такие ключи многие провайдеры уже считают невалидными.
• Забыли про домен в поле From. DMARC требует выравнивания: домен в видимом отправителе должен совпадать с доменом DKIM-подписи или SPF. Отправка «от company.ru» через сервис, подписывающий письма своим доменом, проверку не пройдёт.
• Записи есть, а домену два дня. Идеальный DNS не отменяет прогрева: новому домену всё равно нужно набрать историю.

Email-аутрич: когда настройку логичнее отдать на сторону

Записи в DNS — это входной билет, а не результат. Домен с идеальной аутентификацией всё равно попадёт в спам, если отправлять по грязной базе, наращивать объёмы рывками и писать шаблонные письма. И наоборот: аккуратная инфраструктура плюс осмысленные письма дают стабильный поток ответов от нужных людей. Об этом стоит поговорить отдельно.

Что это вообще за услуга — email-аутрич?

Email-аутрич — это работа с холодной аудиторией через персональные деловые письма: вы определяете, какие компании и какие должности вам интересны, а подрядчик собирает контакты, готовит поводы для обращения и ведёт цепочку касаний до ответа. Технический слой, разобранный в этой статье, входит в услугу целиком: отдельные домены и поддомены, SPF, DKIM, DMARC, прогрев ящиков, мониторинг доставляемости и блок-листов. Проще говоря, вы получаете не «рассылку», а собранный и обслуживаемый канал первых контактов, за состояние которого кто-то отвечает.

Какую потребность закрывает email-аутрич?

Он нужен там, где нельзя просто ждать входящих обращений. Если ваш продукт покупают редко и обдуманно, поисковая реклама даёт мало запросов и высокую цену контакта, а сарафанное радио не масштабируется. Аутрич даёт управляемость: вы сами выбираете отрасль, размер компании и роль собеседника — и получаете диалоги с теми, кто действительно принимает решение. Для руководителя это ещё и предсказуемость: понятно, сколько контактов обработано, сколько ответов получено и во сколько обходится одна встреча.

Для кого услуга email-аутрич?

Наилучший эффект — у компаний с осмысленным чеком и понятным профилем клиента: производство и промышленные поставки, B2B-услуги, разработка и IT-продукты, логистика, оптовые направления, инжиниринг. Также подходит тем, кто выходит в новый регион или отрасль, где о них ещё не слышали, и командам, где менеджеры отлично ведут переговоры, но тонут в поиске контактов. Не подойдёт массовому B2C с импульсной покупкой и совсем маленьким чеком — там экономика не сойдётся, и честнее сказать об этом сразу.

Почему воспользоваться услугой стоит прямо сейчас?

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

Частые вопросы