Посетителят вижда „Изпратено“, но във фирмената поща няма нищо. Или натиска бутона и страницата остава без отговор. Това са различни проблеми и изискват различна проверка. Преди да сменяте разширението за формата или пощенския доставчик, установете докъде е стигнало конкретното запитване.
Липсата на запитвания сама по себе си не доказва повреда. Възможно е никой да не е изпратил формата. Тук разглеждаме случая, в който има известен опит за изпращане, час и получател, а очакваният имейл липсва.
Първо намерете последната потвърдена стъпка
Не започвайте с „всичко е счупено“. Запишете адреса на страницата, приблизителния час, устройството и показаното съобщение. Ако проблемът е възникнал след промяна, добавете каква е тя: нов хостинг, нова форма, смяна на пощата или обновяване на разширение.
| Стъпка | Какво установявате | Кой може да провери |
|---|---|---|
| Попълване | Има ли липсващо поле или невалиден адрес? | Собственикът, в самата форма |
| Заявка от браузъра | Изпратени ли са данни към правилния адрес? | Разработчикът, в мрежовия панел |
| Обработка на сървъра | Приета ли е заявката и направен ли е опит за писмо? | Разработчикът или хостингът |
| Пощенска услуга | Писмото чака ли, прието ли е или е отхвърлено? | Администраторът на пощата |
| Поща на получателя | Има ли писмо, спам, карантина или пренасочване? | Получателят или неговият администратор |
Когато бутонът не изпраща нищо
Проверете дали формата показва грешка до задължително поле и дали тя се вижда на телефон. Празно поле над видимата част на екрана може да остави впечатление за неработещ бутон. Вижте и дали потвърждението е четимо, без да се налага посетителят да търси къде се е появило.
Следващата проверка е за разработчика: появява ли се заявка при изпращане, към кой адрес отива и какъв отговор получава? Прекъсната връзка, грешен адрес и отказ от защитата на сървъра не се поправят чрез настройките на пощенската кутия. Не изключвайте всички защити на сайта заради една грешка; установете конкретното правило или невалидно поле.
При прегледа на кода на DrNiki проверката на полетата е преди изпращането. Сървърът също проверява задължителните данни и формата на имейл адреса. Това са две отделни проверки: видимата в браузъра помага на човека, а сървърната не разчита само на нея.
„Прието“ не означава „получено във входящата кутия“
Отговорът от сайта трябва да се прочете според действителната логика на приложението. Самият код HTTP 200 не доказва изпратено писмо. Например защита от автоматизирани заявки може умишлено да върне привидно успешен отговор, без да изпраща имейл.
Дори при реален опит за изпращане има следващи стъпки. PHP документацията за mail() уточнява, че положителният резултат означава приемане за доставка, а не непременно получаване. Същото разграничение е изрично посочено за wp_mail() в WordPress. Ако WordPress форма не изпраща имейли, зеленият надпис в администрацията не е достатъчен за заключение.
В прегледаната локална версия на DrNiki има отделен отговор при неуспешно предаване към mail(). Това показва как е написана обработката; прегледът на кода не удостоверява доставено запитване. За доставка е нужна проверка на конкретното писмо по-нататък в пощенската услуга и при получателя.
Условен пример: сайтът приема заявката в 10:15, но получателят в настройките е сгрешен. Пощенската услуга отчита отказ за несъществуващ адрес. Поправката е в адреса и последващата проверка на доставката, а не в дизайна на бутона. Това е пример за диагностика, не история за клиентски резултат.
Проверете кой изпраща писмото и къде отива отговорът
Полето From посочва подателя на писмото. Reply-To указва към кого да бъде насочен отговорът. Практична настройка е сайтът да изпраща от разрешен за пощенската услуга адрес на собствения ви домейн, а адресът на посетителя да се използва за отговор. Така не се представяте за изпращач от чужд домейн.
Точно това разделение има в прегледания код на DrNiki: адрес от домейна за подател и провереният адрес на посетителя за отговор. Самото попълване на тези полета обаче не настройва пощенската услуга и не удостоверява домейна.
Какво правят SPF, DKIM и DMARC
- SPF описва кои сървъри са разрешени да изпращат от името на домейна, използван при тази проверка.
- DKIM добавя проверим цифров подпис към писмото.
- DMARC свързва проверките с домейна във видимия подател и задава политика при несъответствие.
Стойностите се вземат от вашия пощенски доставчик. Не копирайте произволен DNS запис от чужд сайт. Документацията на Cloudflare за пощенските записи обяснява предназначението им и зависимостта от доставчика.
Насоките на Gmail за изпращачи разграничават общите изисквания от тези за големи обеми. Удостоверяването помага на получаващата услуга да провери писмото, но не гарантира входяща папка. Имат значение и репутацията на изпращача, съдържанието и правилата на получателя. Настроен SMTP също не е самостоятелно доказателство за доставка.
Ако проблемът започва след преместване на сайта
Хостингът на сайта и пощата може да са при различни доставчици. Работещата начална страница не доказва, че са запазени настройките за писмата. Преди промяна запазете копие на съществуващите DNS записи и уточнете къде трябва да останат пощенските кутии.
При проверката сравнете MX записите за получаване, записите за удостоверяване и настройките за изпращане в приложението. Ако се сменя само уеб хостингът, не заменяйте автоматично MX записите с тези на новия сървър. Проверете също адреса на получателя и дали новата среда има разрешен начин за изпращане. Пароли и ключове се предават през защитен достъп, не в публична задача.
Как да потвърдите, че поправката работи
Уговорете един контролиран тест със собствена пощенска кутия. Използвайте ясно разпознаваемо тестово съобщение и запишете часа. Проверете последователно отговора на сайта, наличните данни от пощенската услуга и полученото писмо, включително папката за спам. След това проверете дали бутонът за отговор насочва към правилния адрес.
Ако писмото липсва, предайте на отговорния специалист часа, адреса на страницата и кратко описание на грешката. Пълни заглавки и дневници могат да съдържат лични адреси и други чувствителни данни; споделяйте ги само по защитен канал и в необходимия обем. Не публикувайте реални клиентски запитвания като пример.
Накрая разграничете техническата проверка от отчетите за маркетинг. Събитие за приета заявка не доказва получен имейл, а получено писмо не доказва продажба. За тази част вижте измерването с Analytics и Search Console. Ако формата работи, но хората не я използват, следващата задача е яснотата на офертата и страницата.
Често задавани въпроси
Трябва ли веднага да сменя разширението за формата?
Не. Първо установете дали проблемът е в полетата, заявката към сървъра, изпращането или получаването. Смяната на разширението няма да поправи сгрешен получател или липсващи пощенски настройки.
Успешен SMTP тест доказва ли, че формата работи?
Не изцяло. Той проверява конкретното тестово изпращане. Самата форма може да използва различен получател или да има проблем преди изпращането, затова трябва да се провери целият път.
Какво да изпратя на човека, който поддържа сайта?
Адреса на страницата, часа на опита, устройството и видимото съобщение. Уточнете какво е променяно наскоро и кой трябва да получава запитванията. Не изпращайте пароли в обикновен чат.