Contact Form 7 не отправляет письма и заявки: что проверить и как исправить

Не меняйте настройки до того, как воспроизвели проблему.

Откройте форму как обычный посетитель и отправьте сообщение с понятными тестовыми данными:

Имя: Тест WebFixer
Тема: Проверка формы
Сообщение: Тестовая заявка 17:42

Запомните точное время отправки.

Теперь посмотрите, что произошло на странице.

В штатной логике Contact Form 7 отправка может получить разные состояния: sent, spam, failed, invalid и другие. Это важнее, чем просто фраза, которую видит пользователь.

Диагностику дальше удобно разделить на три сценария:

1. форма показывает ошибку отправки;
2. форма показывает успех, но письма нет;
3. часть нормальных заявок определяется как спам.

Это три разные проблемы.

Contact Form 7 официально указывает две основные причины сообщения об ошибке после отправки формы:

• само письмо не удалось отправить;
• заявка была распознана как спам.

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

Если форма помечает отправку как failed, проверяйте почтовую цепочку.

Если состояние spam — SMTP тут может быть вообще ни при чём: Contact Form 7 остановил заявку до отправки письма.

Поможем определить, где обрывается цепочка — в самой форме, антиспаме, WordPress, SMTP или почтовом сервере — и восстановить приём заявок.

Откройте:

Контакты → Контактные формы → нужная форма → Письмо

Особенно внимательно проверьте поля:

Кому

От кого

Дополнительные заголовки

Адрес в поле «Кому» должен действительно существовать и быть записан в допустимом формате.

А вот с полем «От кого» есть очень важный нюанс.

Contact Form 7 рекомендует использовать здесь адрес того же домена, на котором работает сайт. Например, если сайт:

example.ru

нормальным отправителем будет что-то вроде:

wordpress@example.ru

или:

site@example.ru

а не адрес посетителя:

visitor@gmail.com

Официальная документация CF7 прямо предупреждает: чужой домен в From может выглядеть для почтовых систем как подмена отправителя.

Адрес посетителя нужно помещать не в From, а в:

Reply-To: [your-email]

Тогда само письмо отправляется от вашего домена, а кнопка «Ответить» в почтовом клиенте направляет ответ посетителю. Именно такую схему рекомендует Contact Form 7.

Это одна из самых частых настроек, которая внешне выглядит безобидно, но сильно влияет на доставляемость.

Вот здесь часто возникает путаница.

Contact Form 7 может сообщить:

«Ваше сообщение успешно отправлено»

а письма в ящике всё равно нет.

Это возможно и не противоречит работе WordPress.

Функция wp_mail() возвращает успех, когда используемый механизм смог обработать отправку без обнаруженной ошибки. Официальная документация WordPress отдельно предупреждает: успешный результат не означает, что письмо действительно доставлено получателю.

То есть:

Contact Form 7 → wp_mail() → OK

и:

письмо появилось во входящих

— это не одно и то же.

После WordPress остаются:

• MTA или SMTP-сервер;
• SPF/DKIM/DMARC;
• антиспам почтового провайдера;
• карантин;
• маршрутизация;
• ящик получателя.

Поэтому при зелёном ответе не нужно чинить форму вслепую.

Нужно идти дальше по почтовой цепочке.

Да, письмо может оказаться в спаме.

Но совет:

«Посмотрите папку Спам»

сам по себе проблему не решает.

Если письма с сайта регулярно фильтруются, проверьте:

• какой адрес стоит в From;
• существует ли этот ящик;
• SPF;
• DKIM;
• настройки SMTP или почтового сервера;
• журналы отправки.

Contact Form 7 рекомендует использовать отправителя на собственном домене и настроить почтовую аутентификацию, включая SPF и DKIM, чтобы уменьшить вероятность того, что нормальное письмо будет воспринято как spoofing или spam.

Теперь полезно отделить Contact Form 7 от всей остальной почтовой системы.

Отправьте другое системное письмо WordPress — например, письмо сброса пароля на тестовый аккаунт или используйте уже установленный инструмент тестирования почты.

Если вообще никакие письма WordPress не уходят, проблема гораздо шире Contact Form 7.

WordPress по умолчанию использует wp_mail(), а та в стандартной конфигурации опирается на PHPMailer и почтовое окружение сервера. Если на VPS или хостинге оно не настроено нормально, письма могут не уходить вообще.

Если остальные письма WordPress приходят, а Contact Form 7 — нет, возвращайтесь к конкретной форме и её mail configuration.

Это намного полезнее, чем сразу устанавливать ещё один SMTP-плагин.

Нет. Contact Form 7 сам по себе не требует SMTP.

Свежий случай на WordPress.org хорошо это показывает: пользователь обнаружил, что CF7 не отправляет письма без SMTP, хотя обычный PHP mail() на сервере работал. Это рассматривалось как конкретная проблема окружения/wp_mail(), а не как новое обязательное требование Contact Form 7.

SMTP часто делает отправку стабильнее, потому что WordPress использует настоящий авторизованный почтовый сервер вместо локальной серверной почты.

Но правильный порядок такой:

сначала определить, что именно не работает → потом выбирать способ исправления.

Не:

«не пришла форма → установить SMTP-плагин».

Иногда SMTP уже настроен идеально, а Contact Form 7 всё равно не отправляет заявку из-за spam filtering или ошибки самой формы.

Это ещё одна популярная ловушка.

Представьте:

SMTP test → письмо пришло
Contact Form 7 → письмо не пришло

Это значит, что почтовый транспорт в принципе способен работать.

Но между CF7 и SMTP всё ещё остаются:

• неправильный To;
• неправильный From;
• mail-tags;
• заголовки;
• антиспам;
• сторонний плагин;
• конкретная конфигурация формы.

В support-кейсах встречается именно такой сценарий: SMTP-плагин успешно отправляет тестовое письмо, а формы Contact Form 7 показывают успех, но уведомления не приходят.

Поэтому после успешного SMTP test не закрывайте диагностику.

Проверьте реальное письмо именно из CF7.

Если на сайте есть SMTP/mail logging, отправьте тестовую заявку и сразу откройте журнал.

Ищите запись с тем же временем.

Она позволяет ответить на главный вопрос:

Contact Form 7 вообще передал письмо почтовой системе или нет?

Очень показательный свежий кейс 2026 года: SMTP-транскрипт показывал ответ почтового сервера:

250 Accepted

то есть сервер принял письмо, но получатели его всё равно не видели. В такой ситуации искать ошибку в Contact Form 7 уже почти бессмысленно — письмо ушло дальше по цепочке и фильтруется после WordPress.

Это хороший диагностический рубеж:

письма нет в mail log → проверяем WordPress/CF7;

mail log показывает ошибку → проверяем SMTP/сервер;

сервер принял письмо → проверяем доставку и почтового провайдера.

Теперь совсем другая ветка.

Contact Form 7 умеет использовать несколько механизмов антиспама, включая Akismet, Cloudflare Turnstile, reCAPTCHA и WordPress Disallowed List.

Проблема в том, что антиспам может ошибаться.

И официальный CF7 прямо признаёт: автоматическая фильтрация не может быть точной на 100%, возможны false positives — нормальные сообщения, ошибочно признанные спамом.

Свежие реальные случаи это подтверждают. Летом 2026 года пользователь сообщал, что после обновлений Contact Form 7 реальные тестовые отправки стали фиксироваться как spam.

Поэтому если клиент говорит:

«Я отправляю форму, а она не проходит»

не ограничивайтесь SMTP.

Сначала выясните, не остановила ли заявку антиспам-система.

Если установлен Flamingo, у Contact Form 7 есть очень полезный инструмент — spam log.

Он может показать, какой механизм посчитал отправку подозрительной.

Например:

Spam log:
reCAPTCHA response token is empty

или другую причину, связанную с конкретным spam module.

Это намного лучше, чем:

«Отключим reCAPTCHA и посмотрим».

Особенно опасен совет, который регулярно встречается на форумах:

add_filter( 'wpcf7_spam', '__return_false' );

Такой код действительно может заставить форму снова принимать сообщения — и поэтому пользователи иногда считают его удачным «фиксом».

Но он фактически отключает spam filtering Contact Form 7.

В свежем обсуждении пользователь применил именно этот workaround после того, как нормальные сообщения блокировались как spam. Само обсуждение хорошо показывает проблему, но использовать такой snippet как постоянное решение без понимания причины не стоит.

Если после отключения всей антиспам-защиты форма внезапно заработала, вы нашли направление диагностики.

Но вы ещё не исправили проблему.

Если spam log указывает конкретный модуль — проверяйте именно его.

Contact Form 7 нативно поддерживает reCAPTCHA v3; она работает в фоне и не показывает классическую галочку пользователю.

Если spam log сообщает о пустом reCAPTCHA token, проверьте:

• загружается ли JavaScript;
• не блокирует ли его оптимизатор;
• не вмешивается ли consent/cookie-система;
• корректна ли интеграция reCAPTCHA;
• нет ли конфликтующего CAPTCHA-плагина.

Не переходите автоматически с v3 на случайный плагин reCAPTCHA v2 только потому, что форма перестала отправляться.

Если Akismet маркирует нормальные заявки как spam, Flamingo позволяет увидеть их и отметить как Not Spam, передав false-positive feedback Akismet.

Contact Form 7 также использует WordPress:

Настройки → Обсуждение → Запрещённые ключи комментариев

Сообщение, содержащее слово или отправленное с IP из этого списка, может быть признано спамом и не отправлено.

Иногда там остаётся старое правило, о котором администратор давно забыл.

Проверим spam log, reCAPTCHA, Akismet, Turnstile и правила WordPress и восстановим приём нормальных обращений без полного отключения защиты.

Если существующая форма большая, создайте временную тестовую Contact Form 7 с минимальным количеством полей:

Имя
Email
Сообщение

И самым простым почтовым шаблоном.

Если новая тестовая форма отправляет письмо, а старая нет, значит:

WordPress способен отправлять почту, а проблема связана с конкретной формой.

Тогда сравнивайте:

• mail-tags;
• To;
• From;
• Reply-To;
• дополнительные заголовки;
• обязательные и необязательные поля;
• сторонние расширения CF7;
• условную логику;
• загрузку файлов;
• дополнительные интеграции.

Это заметно быстрее, чем отключать весь WordPress.

Contact Form 7 связывает поля формы с шаблоном письма через mail-tags.

Если поле было удалено или переименовано:

[your-phone]

а старый tag всё ещё используется в письме, конфигурация может стать некорректной или давать неожиданный результат.

Особенно внимательно проверяйте заголовки.

Contact Form 7 имеет встроенный configuration validator и отдельно предупреждает об опасных или некорректных mail configurations.

Поэтому после крупных изменений формы сначала исправьте предупреждения CF7, а уже потом ищите экзотический конфликт PHP.

Не обязательно виноват сам Contact Form 7.

Свежие support-кейсы показывают, что формы могут перестать нормально работать после изменений самого CF7 или взаимодействующих с ним компонентов. В одном из недавних случаев пользователи связывали проблему с обновлениями и spam detection.

Поэтому зафиксируйте:

• когда пришла последняя нормальная заявка;
• какие плагины обновились после этого;
• обновлялся ли WordPress;
• менялся ли PHP;
• менялись ли CAPTCHA/anti-spam;
• устанавливались ли расширения Contact Form 7.

Но не откатывайте всё подряд.

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

Вокруг Contact Form 7 существует огромное количество дополнений:

• conditional fields;
• database/storage;
• Telegram integrations;
• CRM integrations;
• redirect;
• multistep;
• upload addons;
• CAPTCHA addons;
• styling addons.

Когда форма перестаёт отправляться, человек часто обвиняет основной Contact Form 7, хотя сбой находится в расширении.

Есть реальные support-кейсы, где проблема после обновления CF7 исчезала после обновления связанного addon-плагина.

Если форма простая — тестируйте основной CF7 отдельно от его дополнительных расширений.

Это особенно полезно, если:

обычная тестовая форма работает, а рабочая сложная — нет.

Современная форма Contact Form 7 отправляется не как обычная страница из девяностых.

Если после нажатия кнопки:

• бесконечно крутится индикатор;
• вообще нет ответа;
• появляется странная ошибка;
• статус страницы остаётся неизменным,

откройте DevTools → Network и повторите отправку.

Посмотрите запрос Contact Form 7.

Важно различать:

HTTP-запрос вообще не ушёл

и:

HTTP-запрос получил 200, но mail sending внутри завершился ошибкой

Например, в свежем support-кейсе AJAX-запрос возвращал 200 OK, reCAPTCHA работала, но CF7 всё равно сообщал о проблеме почтовой отправки.

То есть 200 у самого AJAX request ещё не означает, что письмо было доставлено.

Всегда смотрите и response data/status Contact Form 7.

Вот это особенно важно для коммерческого сайта.

Сам Contact Form 7 не сохраняет отправленные сообщения в базе данных.

Официально для хранения заявок разработчик рекомендует отдельный плагин Flamingo.

Получается неприятная архитектура:

клиент отправил заявку
        ↓
Contact Form 7
        ↓
email
        ↓
почтовая проблема
        ↓
заявку никто не увидел

Если почта — единственное место, куда попадает обращение, проблема доставки превращается в проблему бизнеса.

Для сайта, где формы приводят клиентов, полезно иметь второй независимый след заявки: хранение submissions, CRM, Telegram или другую предусмотренную архитектурой систему.

Но при включении хранения нужно учитывать персональные данные и политику конфиденциальности сайта.

Если часть заявок приходит, а часть нет, отправьте несколько контролируемых тестов:

тест 1 — обычный текст
тест 2 — другой email
тест 3 — сообщение со ссылкой
тест 4 — другое устройство/сеть

Не нужно устраивать сотню комбинаций.

Цель — найти одно отличие, после которого заявка начинает определяться как spam или исчезать.

Например, если обычный текст проходит, а сообщение со ссылкой стабильно попадает в spam, это уже гораздо полезнее общего:

«Contact Form 7 иногда глючит».

Когда SMTP/mail log подтверждает, что почтовый сервер принял сообщение, Contact Form 7 свою часть цепочки уже выполнил.

Дальше проверяйте:

• spam/quarantine;
• SPF;
• DKIM;
• DMARC;
• reputation отправителя;
• ограничения принимающего сервера;
• корректность адреса;
• почтовые логи.

В этом месте переустановка Contact Form 7 ничего не изменит.

Подключайте хостинг, если:

• wp_mail() не работает вообще;
• серверная почта не настроена;
• CF7 показывает mail failure;
• в журнале видны ошибки почтовой подсистемы;
• SMTP соединение блокируется;
• сервер не может подключиться к внешнему mail host.

Передайте поддержке:

точное время теста
адрес сайта
адрес отправителя
адрес получателя
текст ошибки
результат mail log

Пароли SMTP и другие секреты отправлять в открытом сообщении не нужно.

Contact Form 7 в своей официальной FAQ тоже рекомендует обращаться к администратору сервера, если фактическая отправка письма завершается ошибкой.

Если нужна короткая схема, используйте такой порядок.

1. Отправьте тестовую заявку и запомните время.
2. Посмотрите результат CF7.

Ошибка отправки или spam?

1. Проверьте To, From и Reply-To.

From должен быть адресом вашего домена.

1. Проверьте, уходят ли другие письма WordPress.

Если нет — проблема шире CF7.

1. Посмотрите mail log.

Письмо вообще попало в почтовую систему?

1. Если CF7 считает сообщение spam — откройте spam log.

Не отключайте защиту вслепую.

1. Проверьте простую тестовую форму.

Она работает?

Значит копайте конфигурацию основной.

1. Если проблема началась после обновления — проверьте последний изменённый компонент.

Особенно addons CF7, CAPTCHA и SMTP.

После этих шагов обычно уже понятно, где находится проблема.

Не переустанавливайте WordPress из-за неработающей формы.

Не удаляйте Contact Form 7 вместе с рабочими формами.

Не ставьте несколько SMTP-плагинов одновременно.

Не отключайте весь антиспам постоянным PHP snippet только ради того, чтобы форма снова стала зелёной.

Не используйте email посетителя в From, если он принадлежит чужому домену.

Не считайте успешный SMTP test доказательством, что Contact Form 7 тоже настроен правильно.

Не считайте зелёный ответ CF7 доказательством доставки письма.

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

После каждой правки отправляйте собственный контролируемый тест.

Если Contact Form 7 не отправляет письма или заявки, не начинайте с установки очередного плагина.

Сначала выясните, где исчезает обращение.

Если CF7 показывает mail failure — проверяйте mail configuration и wp_mail().

Если форма показывает успех, а письмо не приходит — переходите к mail logs и почтовой доставке.

Если заявка определяется как spam — смотрите spam log и конкретный антиспам-модуль.

Если простая тестовая форма работает — ищите различие в рабочей форме.

Если всё началось после обновления — проверяйте последний изменённый плагин или интеграцию.

Главное здесь — не «заставить кнопку Отправить снова стать зелёной».

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

Успешная отправка через wp_mail() не гарантирует фактическую доставку в почтовый ящик. После WordPress письмо ещё проходит через почтовый сервер и фильтры получателя. Проверьте mail log, spam/quarantine и почтовую аутентификацию домена.

Не обязательно. CF7 использует почтовый механизм WordPress wp_mail(). Но если серверная почта настроена плохо или заблокирована хостингом, использование корректно настроенного внешнего SMTP может решить проблему доставки.

Заявку могут блокировать reCAPTCHA, Akismet, Turnstile, Disallowed List или другое spam filtering. Для поиска конкретной причины полезен spam log, доступный при использовании совместимого хранилища вроде Flamingo.

Contact Form 7 рекомендует адрес того же домена, что и сайт. Email посетителя лучше использовать через Reply-To, а не подставлять в From. Это уменьшает риск проблем с подменой отправителя и доставляемостью.

По умолчанию нет. Сам Contact Form 7 не хранит отправленные сообщения в базе. Для этого его разработчик предлагает Flamingo или другое совместимое решение хранения.

Воспроизведите проблему, определите состояние отправки и проверьте последние обновлённые компоненты: сам CF7, его addons, CAPTCHA, SMTP и другие интеграции. Свежие support-кейсы показывают, что проблема после обновлений действительно может находиться как в CF7, так и в связанных компонентах.