Поща от Вашия уебсайт и формуляри

Модул 7: Бюлетини и поща от Вашия уебсайт · Време за четене: 11 минути

Учебна цел: След този урок ще можете да настроите поща от уебсайта (контактни формуляри, потвърждения на поръчки, съобщения от WordPress) така, че да пристига, да не създава проблеми с DMARC и да не позволи злоупотреба с Вашия пакет.

Основни понятия: PHP mail(), SMTP с вход, envelope подател (envelope sender), From срещу Reply-To, адресът на посетителя никога като From, SMTP плъгин, транзакционна поща, спам чрез формуляри, captcha, honeypot, лимит за изпращане, локално доставяне, когато MX записът сочи другаде

Вашият уебсайт също е пощенска програма

Вашият уебсайт изпраща повече поща, отколкото си мислите. Контактен формуляр Ви изпраща имейл за всяко съобщение. Онлайн магазин изпраща потвърждения на поръчки, фактури и съобщения за изпращане. WordPress изпраща имейл при нов коментар, обновление или нулиране на парола. За получателя това е просто поща от Вашия домейн и тя се проверява също толкова строго, колкото пощата от Вашата пощенска кутия: SPF, DKIM, DMARC, репутация.

Въпреки това поща от уебсайт по-често се проваля от обикновената поща. Обикновено причината е едно от три неща: начинът на изпращане, адресът на подателя или злоупотреба с формуляра.

Начин 1: PHP mail()

Най-простият начин уебсайт да изпраща поща е функцията на PHP mail(). Уебсайтът предава пощата директно на пощенската програма на уеб сървъра, без вход. Обикновено работи, но има недостатъци:

• Envelope подателят (Return-Path) често се превръща в системния акаунт на Вашия пакет, например gebruiker@server.hosting.example, а не Вашия адрес. SPF тогава се проверява за домейна на сървъра и следователно не е изравнен (aligned) с Вашия From домейн (урок 7.1).
• Дали се добавя DKIM подпис от Вашия домейн зависи от сървъра. На някои сървъри да, на други не.
• Не виждате нищо обратно. Ако пощата не пристигне или получите bounce, той отива в системния акаунт, който никой не проверява.
• Няма лимит за формуляр. Ако формулярът бъде злоупотребен, сървърът изпраща от Ваше име, докато не бъде достигнат лимитът на пакета Ви.

Начин 2: SMTP с вход (по-добре)

Нека Вашият уебсайт изпраща поща по същия начин, по който го прави Вашата пощенска програма: вход в изходящия пощенски сървър с истинска пощенска кутия, чрез порт 587 (STARTTLS) или 465 (SSL/TLS), с пълния имейл адрес като потребителско име (уроци 1.4 и 2.1). Тогава:

• envelope подателят е Вашият адрес и пощата се подписва по същия начин, както обикновената поща от Вашия домейн;
• bounce съобщенията пристигат в пощенска кутия, която можете да прочетете;
• изпратената поща, ако желаете, се записва в папка Sent;
• можете да зададете собствен лимит за изпращане за всяка пощенска кутия.

В WordPress това се прави с SMTP плъгин. Той заменя стандартната функция за поща на WordPress с изпращане чрез SMTP. Попълвате същите данни, както в пощенска програма: сървър, порт, защита, потребителско име и парола. За целта е препоръчително да създадете отделна пощенска кутия, например website@example.com. Ако паролата бъде открадната, Вашата собствена пощенска кутия остава защитена и веднага виждате коя поща идва от уебсайта.

За собствен PHP сайт съществуват библиотеки, които изпращат поща чрез SMTP, като PHPMailer. Поставете паролата в конфигурационен файл извън уеб папката, не в кода на страница.

При WebOké данните за SMTP се намират в DirectAdmin ръководство 8.1, с името на сървъра на Вашия пакет; при други доставчици те се намират в ръководството или приветственото писмо и работят по същия начин.

Много транзакционна поща? Използвайте услуга

Ако изпращате стотици потвърждения на поръчки на ден, си струва да използвате транзакционна услуга: услуга за изпращане на автоматична поща. Тя има добра репутация и показва какво се е случило с всеки имейл. Свързвате домейна по същия начин, както при услуга за бюлетини (DKIM чрез CNAME, урок 7.1). Дръжте транзакционната поща и бюлетините разделени: неуспешна кампания не трябва да засяга потвърждението на поръчките Ви.

Златното правило: адресът на посетителя никога не е подателят

При контактен формуляр е изкушаващо да изпратите пощата „от" посетителя. Тогава можете веднага да натиснете Отговори във Вашата пощенска програма. Това изглежда така:

From: Pieter <pieter@example.net>
To: info@example.com
Subject: Vraag via het contactformulier

Но Вашият сървър изобщо не трябва да изпраща поща от името на example.net. Да приемем, че example.net има DMARC политика p=reject. Получаващият сървър (Вашият собствен или този на Gmail, ако пренасочвате пощата) вижда имейл с From example.net, който не минава през SPF или DKIM на example.net, и го отхвърля. Много големи пощенски домейни имат строга политика: при проверка на 8 ноември 2026 г. домейни като yahoo.com, aol.com, ziggo.nl и kpnmail.nl имаха DMARC политика p=reject, а icloud.com, gmx.de и web.de имаха p=quarantine. Посетител с такъв адрес попълва Вашия формуляр и Вие никога не получавате съобщението или то отива в спам папката Ви. Домейни с p=none (каквито по това време бяха gmail.com и hotmail.com) могат по всяко време да затегнат политиката си, а Google изрично пише в насоките си, че не бива да имитирате Gmail адреси като From. Затова никога не разчитайте, че ще мине добре.

Правилният начин:

From: Website example.com <website@example.com>
Reply-To: Pieter <pieter@example.net>
To: info@example.com
Subject: Vraag via het contactformulier

Подателят е Вашият собствен адрес, така че SPF, DKIM и DMARC са коректни. Адресът на посетителя е в полето Reply-To. Ако натиснете Отговори, отговорът Ви отива при Pieter. В повечето плъгини за формуляри ще намерите това в настройките на пощата: задайте при Подател (From) постоянен адрес от Вашия домейн, а при Reply-To полето, в което посетителят въвежда своя адрес.

Защита на формулярите от злоупотреба

Формуляр без защита рано или късно бива открит от ботове. В най-добрия случай получавате спам. В най-лошия случай злоупотребяват с него, за да изпращат спам до други: ако Вашият формуляр изпраща потвърждение до „адреса, който посетителят въвежда", бот може да въведе там всеки адрес на света, със собствен текст в съобщението. Тогава Вашият домейн изпраща спам, с всички последствия за репутацията Ви (урок 5.2).

Защита на няколко нива:

• Captcha или невидима проверка (като reCAPTCHA или Turnstile) спира повечето ботове.
• Honeypot: скрито поле, което хората не виждат, но ботовете попълват. Попълнено ли е? Съобщението не се изпраща.
• Без свободен текст в потвърждение към посетителя, или изобщо без потвърждение до посочения адрес. Проста бележка „Благодарим, получихме съобщението Ви" на страницата е достатъчна.
• Лимит за изпращане за пощенска кутия за пощенската кутия на уебсайта, по-нисък от този на пакета Ви.
• Актуализиране на софтуера. Стари плъгини са известен вход за злоупотреба.

Забелязвате ли, че пакетът Ви внезапно изпраща много поща, или получавате съобщение, че дневният лимит е достигнат, докато самите Вие изпращате малко поща? Веднага сменете паролите и проверете кой формуляр или скрипт изпраща пощата (урок 3.4).

Пощата е другаде, уебсайтът е тук

Често срещан капан: Вашият уебсайт е при един доставчик, а пощата Ви при друг (например Microsoft 365 или Google Workspace). Вашият MX запис сочи към другия доставчик. Но уеб сървърът все още мисли, че сам обработва пощата за Вашия домейн, защото домейнът е и в собствения му пакет. Поща от формуляра до info@example.com той доставя локално, в пощенска кутия на уеб сървъра, която никой не проверява, или връща грешка като 550 ... mailbox unavailable.

Решението е в панела на уеб сървъра да посочите, че пощата се обработва другаде. В DirectAdmin при WebOké това е отметката „Използвайте този сървър за обработка на моите имейли" (Use this server to handle my emails) при MX Records (изключете я). Други панели имат подобни настройки, например „e-mail routing: external" в cPanel. Още по-добре: нека уебсайтът изпраща поща чрез SMTP с пощенска кутия при доставчика, при когото пощата Ви наистина се намира.

Обобщение

• Поща от уебсайт се проверява също толкова строго, колкото обикновена поща. Нека сайтът изпраща поща чрез SMTP с вход, не чрез mail().
• Използвайте отделна пощенска кутия за уебсайта, със собствен лимит за изпращане.
• Адресът на посетителя принадлежи в Reply-To, никога в From. Иначе DMARC се проваля, а при домейни с p=reject (като yahoo.com, ziggo.nl, kpnmail.nl) пощата бива отхвърлена.
• Защитете формулярите с captcha, honeypot и без свободни потвърждения до посочени адреси.
• Ако пощата Ви е при друг доставчик, изключете локалното доставяне на уеб сървъра или изпращайте поща чрез SMTP при този доставчик.

Тест

Задача

Задача O7.3: Проверка на поща от уебсайта. Попълнете формуляр на Вашия собствен уебсайт с адрес от Gmail или Outlook.com като подател и прегледайте копрегелите на съобщението, което пристига при Вас. Отговорете на контролния списък: кой адрес е в From, дали адресът на посетителя е в Reply-To, какво показват spf=, dkim= и dmarc= при Authentication-Results, изпраща ли сайтът Ви поща чрез SMTP или чрез mail(), и има ли формулярът captcha или honeypot? Ако нямате собствен уебсайт, отговорете на въпросите за примера от този урок. След това ще получите примерен отговор.

Прочетете още

Стъпките в тези статии важат за панелите на WebOké; при други доставчици работи по подобен начин.

• Форма за контакт на Вашия уебсайт: изпращане на полетата по имейл и предотвратяване на спам
• Как да получа правилния подател с mail() в PHP? SMTP
• Изпращането на имейл през PHP не работи, MX записите сочат другаде
• Лимит за изпращане на имейли
• Достигнат е дневният лимит за имейли
• Ръководство за DirectAdmin 8.1: Всички настройки на едно място: сървъри, портове и защита
• Ръководство за DirectAdmin 5.10: E-mail при Microsoft 365 или Google Workspace, уебсайт при WebOké