Письма с сайта не доходят или падают в спам: SPF, DKIM, DMARC и SMTP

Типичная ситуация: клиент говорит, что оставлял заявку на сайте, а в почте менеджера её нет — ни во «Входящих», ни в «Спаме». Форма показала «Спасибо, мы свяжемся», а письмо потерялось по дороге. Чаще всего дело не в коде формы и не в «глюке хостинга», а в том, что почтовые сервисы не верят отправителю: у домена не настроены SPF, DKIM и DMARC, письмо уходит через PHP-функцию mail() с общего сервера, а адрес в поле «От кого» не совпадает с сервером, который реально отправляет. Разберём, как устроены эти проверки, какие записи нужны домену в 2026 году и как за полчаса понять, где именно теряются письма.

Почему письма и заявки с сайта не доходят: 5 типовых причин

Форма на сайте — это обычно две операции: сохранить заявку (если сохраняет) и отправить уведомление на почту. Если первая работает, а вторая нет, заявка для бизнеса всё равно потеряна. Причины почти всегда одни и те же:

1. Нет SPF, DKIM или DMARC у домена. Сервер получателя не может проверить, что письмо действительно от вас, и по умолчанию относится к нему с подозрением.
2. Отправка через mail() с виртуального хостинга. Письмо уходит с общего IP-адреса, с которого одновременно шлют почту сотни чужих сайтов, без DKIM-подписи и часто с технического адреса вида user@server123.hoster.ru.
3. Адрес «От кого» не соответствует отправителю. Форма ставит в поле From адрес клиента (client@gmail.com) или ящик на Яндексе, а отправляет ваш хостинг. Для Gmail и Яндекса это выглядит как подделка.
4. Сменили хостинг или почту — записи остались старые. После переезда SPF указывает на прежний сервер, DKIM-ключ от старой платформы, а в DNS заодно появилась вторая SPF-запись.
5. Лимиты и блокировки. Сайт отправляет через бесплатный ящик по SMTP и упирается в суточный лимит, либо IP хостинга попал в чёрный список DNSBL.

Бывает и так, что форма вообще не отправляется — сервер возвращает ошибку, и данные не уходят с сайта. Это другая история, её мы разобрали в статье про ошибку 405 и неотправляющиеся формы. Здесь — случай, когда форма «сработала», а письмо не дошло.

Что такое SPF, DKIM и DMARC простыми словами

Протокол SMTP, по которому ходит почта, изначально никак не проверяет отправителя: написать в поле «От кого» можно любой адрес. SPF, DKIM и DMARC закрывают эту дыру. Все три — TXT-записи в DNS вашего домена, то есть настраиваются там же, где A- и MX-записи (подробнее про устройство DNS — в статье что такое домен).

SPF-запись: формат и частые ошибки

SPF перечисляет всех, кто вправе отправлять почту от вашего домена. Запись начинается с v=spf1, дальше идут механизмы, в конце — правило для остальных:

• a и mx — разрешить серверы из A- и MX-записей домена;
• ip4: / ip6: — конкретный IP-адрес или подсеть, например сервер сайта;
• include: — подключить SPF стороннего сервиса (почтовой платформы, сервиса рассылок);
• redirect= — полностью передать политику другому домену. Так выглядит стандартная запись Яндекс 360: v=spf1 redirect=_spf.yandex.net;
• ~all — остальным «мягкий отказ» (письмо под подозрением), -all — жёсткий отказ.

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

• Две SPF-записи на домене. Одну добавил хостинг, вторую — почтовая платформа. По RFC 7208 это ошибка (permerror), и проверка не проходит ни по одной. Записи нужно объединить в одну.
• redirect плюс что-то ещё. Если в почту Яндекс 360 надо добавить сервер сайта или сервис рассылок, redirect меняют на include: v=spf1 ip4:1.2.3.4 include:_spf.yandex.net ~all.
• Больше 10 DNS-запросов. Стандарт RFC 7208 ограничивает проверку десятью DNS-обращениями: каждый include, a, mx, redirect тратит минимум одно, а вложенные include — ещё. Превышение — снова permerror.
• Сервер сайта не указан. Почта на Яндексе, сайт на хостинге, SPF содержит только Яндекс — все письма из форм не проходят SPF.

DKIM-запись: селектор, ключ и где их взять

DKIM — цифровая подпись. Сервер-отправитель подписывает каждое письмо закрытым ключом, а открытый ключ публикуется в DNS по адресу селектор._domainkey.site.ru. Получатель находит ключ по селектору из заголовка письма и сверяет подпись.

Ключ сами не придумывают — его выдаёт тот, кто отправляет письма:

• Яндекс 360 для бизнеса — ключ в админ-панели в настройках домена, селектор mail;
• VK WorkSpace (бывший Mail.ru для бизнеса) — значение записи в панели администратора, раздел «Управление доменом»;
• Сервис транзакционных писем — выдаёт свою DKIM-запись при подключении домена;
• Хостинг — в ISPmanager и похожих панелях включается галочкой у почтового домена, но у части хостеров DKIM для писем через mail() доступен только с выделенным IP (так, например, указано в документации Beget).

У каждого отправителя свой селектор, поэтому DKIM-записей на домене может быть несколько — в отличие от SPF. Рекомендуемая длина ключа — 2048 бит (минимум по RFC 8301 — 1024; часть платформ, например Яндекс 360, выдаёт 1024-битный ключ — менять его не нужно); длинную строку некоторые DNS-панели разбивают на части по 255 символов, это нормально.

Настройка DMARC: от p=none к reject

DMARC говорит серверу получателя, что делать с письмами, не прошедшими проверку, и куда слать отчёты. Запись размещают на поддомене _dmarc:

v=DMARC1; p=none; rua=mailto:dmarc@site.ru

• p= — политика: none (только наблюдать), quarantine (в спам), reject (отклонять);
• rua= — адрес для сводных отчётов: какие серверы и с каким результатом слали почту от вашего домена;
• pct= — доля писем, к которым применяется политика; sp= — политика для поддоменов; adkim/aspf — строгость выравнивания.

Порядок внедрения всегда один: SPF → DKIM → DMARC с p=none → 2–4 недели читаем отчёты и находим всех легальных отправителей (сайт, CRM, бухгалтерия, сервис рассылок) → quarantine → reject.

PTR и репутация IP: почему mail() с хостинга попадает в спам

Функция PHP mail() передаёт письмо локальному почтовому серверу хостинга. На виртуальном хостинге это означает:

• IP-адрес общий: если соседний сайт взломали и с него пошёл спам, репутация падает у всех;
• PTR-запись IP указывает на имя сервера хостера, а не на ваш домен;
• DKIM-подписи от вашего домена нет или она на домене хостера — выравнивание DMARC не проходит;
• обратный адрес (envelope sender, Return-Path) технический, вида user@server.hoster.ru.

Яндекс в требованиях к отправителям прямо пишет, что у отправляющего хоста должен быть постоянный IP с корректным обратным DNS, а адрес «От кого» должен совпадать с адресом, под которым идёт авторизация на сервере. Письмо из mail() этим условиям обычно не отвечает. Для своего VPS PTR-запись настраивают через хостера или дата-центр, для виртуального хостинга правильнее уйти с mail() на SMTP.

Требования Яндекс Почты, Mail.ru и Gmail к отправителям в 2026 году

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

SMTP для сайта: почтовый ящик или сервис транзакционных писем

Надёжная схема — отправлять письма сайта не через mail(), а по SMTP с авторизацией через сервер, на который уже настроены SPF и DKIM вашего домена. Вариантов два.

Ящик на корпоративной почте (Яндекс 360, VK WorkSpace)

Заводите отдельный ящик вроде noreply@site.ru, создаёте для него пароль приложения и прописываете в настройках сайта: smtp.yandex.ru, порт 465, SSL. Поле «От кого» — строго этот ящик, адрес клиента из формы ставьте в Reply-To, чтобы менеджер отвечал ему одной кнопкой. Подходит для форм обратной связи и небольших интернет-магазинов.

Ограничение — суточные лимиты почтового сервиса. Для Яндекс Почты, по её справке, это 300 писем в сутки при отправке по SMTP, причём письмо на 10 адресатов считается за 10, а при однотипных письмах антиспам может заблокировать отправку раньше. Для бизнес-тарифов Яндекс 360 уточняйте лимиты в документации своего тарифа.

Сервис транзакционных писем

Если сайт шлёт подтверждения заказов, восстановление паролей, уведомления личного кабинета — нужен специализированный сервис. У российских сервисов Unisender Go, DashaMail и NotiSend есть и SMTP, и API для транзакционных писем: сервис выдаёт SPF- и DKIM-записи для вашего домена, собирает статистику доставки и сам разбирается с отказами. Отдельные ящики и лимиты почтовой платформы не расходуются.

Как подключить SMTP на WordPress, Битрикс и самописном сайте

• WordPress — функция wp_mail() по умолчанию использует mail(); переключение на SMTP делается SMTP-плагином или через хук phpmailer_init в теме.
• 1С-Битрикс — с версии главного модуля 21.900 SMTP-отправка настраивается штатно, на старых версиях — через переопределение функции custom_mail() в init.php.
• Самописный сайт на PHP, Node.js — библиотеки PHPMailer или Nodemailer с SMTP-транспортом; логин и пароль храните в переменных окружения, а не в коде.

Если после обновлений и смены подрядчиков никто не помнит, как устроена отправка на сайте, это разовая задача на доработку сайта: перевести формы на SMTP, поправить заголовки и протестировать доставку на основные почтовые сервисы.

Как проверить SPF, DKIM, DMARC и заголовки письма

1. Посмотрите записи в DNS. В терминале: dig TXT site.ru, dig TXT _dmarc.site.ru, dig TXT mail._domainkey.site.ru (в Windows — nslookup -type=TXT). Проверьте, что SPF-запись одна и в ней есть все отправители.
2. Отправьте тестовую заявку с формы на ящики в Gmail, Яндексе и Mail.ru — у каждого свой фильтр.
3. Откройте исходник письма («Показать оригинал» в Gmail, «Свойства письма» в Яндекс Почте) и найдите строку Authentication-Results. Должно быть spf=pass, dkim=pass, dmarc=pass.
4. Сверьте домены. В заголовках смотрите From, Return-Path и d= в DKIM-Signature: для выравнивания домен From должен совпасть хотя бы с одним из них.
5. Проверьте IP отправителя по строкам Received: есть ли у него PTR и не в чёрных ли он списках DNSBL.
6. Подключите постмастеры Яндекса, Mail.ru и Google — они показывают репутацию домена и долю писем в спаме.

Чек-лист: чтобы ни одна заявка с сайта не потерялась

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

• На домене одна SPF-запись, в ней сервер сайта, почтовая платформа и сервисы рассылок
• DKIM включён у каждого отправителя, ключи опубликованы и проходят проверку
• DMARC настроен, хотя бы p=none с адресом для отчётов
• Сайт отправляет почту по SMTP с авторизацией, а не через mail()
• В поле «От кого» — ящик вашего домена, адрес клиента — в Reply-To
• У IP отправителя есть PTR, он не в чёрных списках
• Тестовая заявка на Gmail, Яндекс и Mail.ru приходит во «Входящие» с spf=pass, dkim=pass, dmarc=pass
• Заявки дублируются в CRM или Telegram, а не живут только в почте
• После переезда или смены почты записи и отправку проверили заново

Вывод простой: письма с сайта не доходят не из-за невезения, а потому что почтовые сервисы не могут подтвердить отправителя. Три TXT-записи, SMTP вместо mail() и правильный адрес «От кого» решают проблему в большинстве случаев, а дублирование заявок в CRM страхует от остальных.