Defaults.Exposed › Поправки › Guides
Имейли от формата за контакт отиват в спам — поправката с автентикиран SMTP (2026)
Публикувано 2026-07-08
Данни към 2026-06-29 · методология v7. Агрегирани census данни от 261 милиона оценени домейна. Вижте как оценяваме.
Имейлите от формата за контакт и уебсайта попадат в спам, защото уеб сървърът ги изпраща без автентикация — без SPF оторизация, без DKIM подпис. Надеждното решение е пренасочване на тази поща през автентикиран SMTP, а не добавяне на сървъра в белия списък. 46.4% от 261,086,232 домейна, оценени в census-а на Defaults.Exposed (данни към 2026-06-29), не публикуват никакъв SPF запис.
Редът на поправката е важен и повечето уроци го обръщат наопаки. Стартирайте безплатно сканиране, за да видите какво в действителност публикува домейнът ви; пренасочете пощата на сайта през автентикиран SMTP (доставчика на пощенска кутия или транзакционна имейл услуга), за да получи истински DKIM подпис; поправете адреса From на формата; и само като последна мярка добавете IP-то на сървъра към SPF.
Защо имейлите от уебсайта ми отиват в спам?
Заради кой реално ги изпраща. Когато посетител попълни формата за контакт, имейлът не се изпраща от вашия доставчик на поща — уеб сървърът го генерира сам, обикновено чрез PHP функцията mail(). От гледна точка на получателя, това съобщение:
- идва от IP адрес, който SPF записът ви не оторизира (вашият SPF покрива доставчика на поща, а не уеб хоста);
- не носи DKIM подпис, така че нищо криптографски не го свързва с вашия домейн;
- често се изпраща от споделен хостинг IP, чиято репутация се определя от стотици чужди сайтове.
Неавтентикирана поща от IP с смесена репутация е точно това, за което съществуват спам филтрите — Gmail и Outlook виждат случаен сървър, твърдящ, че е вие. По-широката картина е мрачна: 46.4% от домейните не публикуват никакъв SPF, а само 10.59% (27,640,987 от 261,086,232 оценени домейна, census към 2026-06-29) прилагат DMARC политика.
Защо това засяга особено WordPress сайтовете?
WordPress изпраща цялата си поща — известия от форми, нулиране на пароли, потвърждения на поръчки — чрез една функция, wp_mail(), която по подразбиране обвива PHP mail() на уеб сървъра. Всеки WordPress сайт, който не е бил умишлено преконфигуриран, е неавтентикиран изпращач от кутията. Плъгините за форми (Contact Form 7, WPForms, Gravity Forms) всички предават пощата към същата функция: изглежда като проблем с плъгина, но всъщност е проблем с транспорта.
Решението не е различен плъгин за форми, а SMTP плъгин (WP Mail SMTP и аналозите му), който пренасочва всичко, изпращано от wp_mail(), през истински автентикиран пощенски акаунт — инфраструктура, която SPF вече оторизира, с приложен DKIM подпис.
Кой метод за изпращане трябва да използва сайтът?
| Метод за изпращане | SPF | DKIM | Оцелява при смяна на хостинг? | Присъда |
|---|---|---|---|---|
PHP mail() / wp_mail() по подразбиране от уеб сървъра | не минава | няма | не е приложимо — счупено навсякъде | проблемът, не вариант |
| Автентикиран SMTP чрез доставчика на пощенска кутия (Google Workspace, Microsoft 365 и др.) | минава | подписано | да — независимо от хостинга | поправката за повечето сайтове |
| Транзакционна имейл услуга (SES, Postmark, Brevo и др.) с верифициран домейн | минава | подписано | да | поправката при голям обем (e-commerce, много форми) |
| IP на уеб сървъра добавен към SPF записа | минава (само SPF) | няма | не — безшумно се чупи при смяна на IP | само като резервна мярка — вижте по-долу |
За няколко известия дневно, SMTP чрез вече платената пощенска кутия е най-краткият път; при реален обем транзакционна услуга е създадена за това. И двете дават DKIM — бързото решение с IP в белия списък никога не го дава.
Как да поправя доставяемостта на имейли от формата за контакт?
- Стартирайте безплатното сканиране на defaults.exposed преди да докосвате каквото и да е. Показва какви SPF, DKIM и DMARC публикува домейнът ви — дали поправяте транспорта на формата, липсващ запис или и двете. Няма никакъв SPF? Започнете с как да поправите SPF.
- Създайте отделна SMTP самоличност за сайта — напр.
[email protected]при доставчика на пощенска кутия или верифициран изпращащ домейн в транзакционна услуга. Използвайте парола за приложение или API ключ, който можете да отмените — не личната парола на реален потребител. - Пренасочете пощата на сайта през него. WordPress: инсталирайте SMTP плъгин и го насочете към акаунта. Други стекове: конфигурирайте mailer-а на фреймуърка вместо локалния
mail(). - Поправете адреса From (антипатернът по-долу): From трябва да е ваш собствен домейн; посетителят отива в Reply-To.
- Ако изпращачът е транзакционна услуга, добавете нейните DKIM записи (обикновено двойка CNAME) — DNS стъпките следват ръководствата за настройка на SPF.
- Изпратете тестово попълване на формата и направете ново сканиране. Хедърите трябва да показват
spf=passиdkim=passза вашия домейн; след това отстранете всичко останало чрез поправка на SPF и поправка на DKIM.
Защо формата изпраща „от” имейл адреса на посетителя?
Най-честата самонанесена грешка в конфигурацията на форми, и много плъгини го правеха по подразбиране: известието пристига From: адреса на посетителя, за да можете да кликнете reply. Изглежда удобно — и е фалшификация. Сървърът ви няма право да изпраща поща като [email protected] — не минава SPF и DKIM за gmail.com, а DMARC политиката на Gmail казва на получателите да я изхвърлят или отхвърлят. Поправката не струва нищо:
- From: адрес в собствения ви домейн (SMTP самоличността от стъпка 2)
- Reply-To: адресът на посетителя — отговорът пак отива директно при него
Всеки масов плъгин за форми поддържа това; това са две полета в настройките за известия.
Защо просто да не добавя IP на сървъра към SPF записа?
Това е поправката, към която повечето форуми посягат първи, и е резервна мярка с причина. Добавянето на ip4:<server> (или механизъм a за уеб хоста) към SPF наистина кара проверката да минава — но:
- При споделен хостинг оторизирате непознати. IP-то принадлежи на машината, не на вас; всеки друг сайт на сървъра може да изпрати SPF-минаваща поща като вашия домейн.
- Чупи се безшумно. Хостинг доставчиците мигрират сървъри и сменят IP-та, без да ви уведомят; SPF ви продължава да оторизира адрес, от който сте се преместили преди месеци.
- Не ви дава DKIM. SPF сам по себе си се чупи при пренасочване и не може да ви доближи до DMARC прилагане по начина, по който може подписът.
Запазете тази опция за наистина ограничения случай: dedicated сървър со статично IP, което контролирате, и приложение, което не може да говори SMTP — и ако можете, добавете DKIM подписване на машината.
SPF проверява ли адреса, който формата поставя в „From”?
Не — и именно това обърква половината от самостоятелните диагнози. Получателите оценяват SPF спрямо домейна в Return-Path (RFC5321.MailFrom), а не хедъра From. Уеб сървърите често поставят собственото си hostname в Return-Path, така че SPF записът ви никога не е бил консултиран — получателят е проверил SPF за srv0421.examplehost.com. Автентикираният SMTP поправя и това: Return-Path става вашият домейн, така че SPF pass-ът накрая се брои за вас. Ето защо DKIM е важен — DMARC alignment изисква pass, свързан с домейна в From, а DKIM подписът пътува с съобщението.
Често задавани въпроси
SMTP плъгинът ще поправи ли и имейлите за нулиране на пароли и WooCommerce?
Да. В WordPress всичко минава през wp_mail(), така че пренасочването поправя известията от форми, нулирането на пароли и имейлите за поръчки с един ход.
Нужни ли са ми SPF и DKIM записи, ако използвам SMTP плъгин? Да — плъгинът променя каква инфраструктура изпраща пощата ви; записите са това, което я оторизира. Ако домейнът ви е сред 46.4% от 261,086,232 оценени домейна без SPF запис (census, 2026-06-29), автентикираният SMTP сам по себе си не е достатъчен. Контролният списък за имейл на нов домейн покрива пълния набор от записи.
Имейлите от формата минават SPF, но все пак не минават DMARC — защо? Почти винаги е антипатернът From-спуфинг по-горе, или SPF минава за домейна на Return-Path на хоста, а не за вашия. Поправете From/Reply-To първо; ако все пак не минава, липсващото е aligned DKIM подпис — вижте „DKIM подписът не е валиден”. Ако и SaaS инструменти извън сайта не минават, ръководството за SPF неуспех при SaaS покрива реда на поправката.
Струва ли си всичко това за форма за контакт с малко трафик? Формата обикновено е там, откъдето влизат парите — пропусната запитка е клиент, когото никога не сте знаели, че сте изгубили. А поправката е безплатна; бариерата е да знаете, че уеб сървърът е бил неавтентикираният изпращач от самото начало.
Изпратете доклада на собственика
Ако сте разработчикът или изпълнителят, поправящ това: след като тестовото изпращане мине, пуснете отново безплатното сканиране и препратете оценения доклад на собственика на сайта — датиран, разбираем за обикновен човек запис, че домейнът се автентикира правилно, и артефактът, от който ще се нуждаят за следващото подновяване на киберзастраховката или въпросника по сигурността от клиент. Ако сте собственикът, четящ това, защото запитките са спрели да пристигат: изпратете тази страница и вашия доклад от сканирането на който управлява уебсайта ви — работа за следобед с „преди и след”, което можете да им покажете.
Проверете домейна → · SPF неуспех за SaaS инструментите? → · Поправете SPF → · Как оценяваме → · Само агрегирани данни. Данните се съхраняват и обработват в ЕС.