E-mail de pe site-ul dumneavoastră și formulare

Modulul 7: Newslettere și e-mail de pe site-ul dvs. · Timp de citire: 11 minute

Obiectiv de învățare: După această lecție veți putea configura e-mailul de pe site (formulare de contact, confirmări de comandă, notificări WordPress) astfel încât să ajungă la destinație, să nu creeze probleme DMARC și să nu permită abuzul pachetului dumneavoastră.

Concepte-cheie: PHP mail(), SMTP cu autentificare, expeditor plic (envelope sender), From vs. Reply-To, adresa vizitatorului niciodată ca From, plugin SMTP, e-mail tranzacțional, spam prin formulare, captcha, honeypot, limită de trimitere, livrare locală când MX-ul indică în altă parte

Site-ul dumneavoastră este și el un program de e-mail

Site-ul dumneavoastră trimite mai multă poștă electronică decât credeți. Un formular de contact vă trimite fiecare mesaj. Un magazin online trimite confirmări de comandă, facturi și mesaje de expediere. WordPress trimite e-mailuri la un comentariu nou, o actualizare sau o resetare de parolă. Pentru destinatar, acestea sunt pur și simplu mesaje de pe domeniul dumneavoastră, și sunt verificate la fel de strict ca mesajele din căsuța dumneavoastră poștală: SPF, DKIM, DMARC, reputație.

Totuși, e-mailul de pe site eșuează mai des decât poșta electronică obișnuită. Acest lucru se datorează de obicei unuia dintre trei factori: modul de trimitere, adresa expeditorului sau abuzul formularului.

Metoda 1: PHP mail()

Cea mai simplă metodă prin care un site trimite e-mailuri este funcția PHP mail(). Site-ul predă atunci mesajul direct programului de e-mail al serverului web, fără autentificare. De obicei funcționează, dar are dezavantaje:

• Expeditorul plic (Return-Path) devine adesea contul de sistem al pachetului dumneavoastră, de exemplu gebruiker@server.hosting.example, și nu adresa dumneavoastră. SPF este atunci verificat pentru domeniul serverului și, prin urmare, nu este aliniat cu domeniul dumneavoastră din From (lecția 7.1).
• Dacă se adaugă o semnătură DKIM a domeniului dumneavoastră depinde de server. Pe unele servere da, pe altele nu.
• Nu vedeți nimic înapoi. Dacă mesajul nu ajunge sau primiți un bounce, acesta ajunge la contul de sistem, unde nimeni nu se uită.
• Nicio limită per formular. Dacă formularul este abuzat, serverul trimite în numele dumneavoastră până la atingerea limitei pachetului dumneavoastră.

Metoda 2: SMTP cu autentificare (mai bine)

Lăsați site-ul dumneavoastră să trimită așa cum face programul dumneavoastră de e-mail: autentificare pe serverul de trimitere cu o căsuță poștală reală, prin portul 587 (STARTTLS) sau 465 (SSL/TLS), cu adresa completă de e-mail drept nume de utilizator (lecțiile 1.4 și 2.1). Astfel:

• expeditorul plic este adresa dumneavoastră, iar mesajul este semnat la fel ca poșta electronică obișnuită de pe domeniul dumneavoastră;
• bounce-urile ajung într-o căsuță poștală pe care o puteți citi;
• mesajul trimis apare, dacă doriți, în folderul Sent;
• puteți seta o limită de trimitere proprie pentru fiecare căsuță poștală.

În WordPress, acest lucru se face cu un plugin SMTP. Acesta înlocuiește funcția de e-mail implicită a WordPress cu trimiterea prin SMTP. Completați aceleași date ca într-un program de e-mail: server, port, securitate, nume de utilizator și parolă. De preferință, creați pentru aceasta o căsuță poștală separată, de exemplu website@example.com. Dacă parola este vreodată furată, propria dumneavoastră căsuță poștală rămâne în siguranță, iar dumneavoastră vedeți dintr-o privire care mesaje provin de pe site.

Pentru un site PHP propriu există biblioteci care trimit prin SMTP, cum ar fi PHPMailer. Puneți parola într-un fișier de configurare în afara directorului web, nu în codul unei pagini.

La WebOké, datele pentru SMTP se găsesc în ghidul DirectAdmin 8.1, împreună cu numele serverului pachetului dumneavoastră; la alți furnizori, acestea se găsesc în ghid sau în e-mailul de bun venit, iar funcționarea este similară.

Multe e-mailuri tranzacționale? Folosiți un serviciu

Dacă trimiteți sute de confirmări de comandă pe zi, merită să apelați la un serviciu tranzacțional: un serviciu de trimitere pentru e-mailuri automate. Acesta are o reputație bună și arată ce s-a întâmplat cu fiecare mesaj. Conectați domeniul la fel ca la un serviciu de newsletter (DKIM prin CNAME, lecția 7.1). Păstrați separate e-mailurile tranzacționale de newslettere: o campanie eșuată nu trebuie să afecteze e-mailul de confirmare al comenzilor dumneavoastră.

Regula de aur: adresa vizitatorului nu este niciodată expeditorul

La un formular de contact este tentant să lăsați mesajul să fie trimis "din partea" vizitatorului. Astfel puteți apăsa direct pe Răspunde în programul dumneavoastră de e-mail. Arată așa:

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

Dar serverul dumneavoastră nu are voie să trimită în numele example.net. Să presupunem că example.net are o politică DMARC p=reject. Serverul destinatar (al dumneavoastră, sau al Gmail dacă redirecționați mesajul) vede un mesaj cu From example.net care nu trece prin SPF sau DKIM al example.net, și îl refuză. Multe domenii mari de e-mail au o politică strictă: la o verificare din 8 noiembrie 2026, printre altele yahoo.com, aol.com, ziggo.nl și kpnmail.nl aveau o politică DMARC p=reject, iar icloud.com, gmx.de și web.de aveau p=quarantine. Un vizitator cu o astfel de adresă vă completează formularul, iar dumneavoastră nu primiți niciodată mesajul sau acesta ajunge în folderul de spam. Domeniile cu p=none (precum, la acel moment, gmail.com și hotmail.com) își pot înăspri politica în orice moment, iar Google scrie explicit în recomandările sale că nu aveți voie să imitați adresele Gmail ca From. Așadar, nu contați niciodată pe faptul că va merge bine.

Metoda corectă:

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

Expeditorul este propria dumneavoastră adresă, astfel încât SPF, DKIM și DMARC sunt corecte. Adresa vizitatorului se află în Reply-To. Dacă apăsați pe Răspunde, răspunsul dumneavoastră ajunge la Pieter. În majoritatea pluginurilor de formulare găsiți acest lucru la setările e-mailului: puneți la Expeditor (From) o adresă fixă a propriului domeniu, iar la Reply-To câmpul în care vizitatorul își introduce adresa.

Protejarea formularelor împotriva abuzului

Un formular fără protecție este mai devreme sau mai târziu descoperit de boți. În cel mai bun caz, primiți spam. În cel mai rău caz, acesta este folosit pentru a trimite spam altora: dacă formularul dumneavoastră trimite o confirmare la "adresa pe care o completează vizitatorul", un bot poate introduce acolo orice adresă din lume, cu text propriu în mesaj. Astfel, domeniul dumneavoastră trimite spam, cu toate consecințele asupra reputației dumneavoastră (lecția 5.2).

Protecție pe mai multe niveluri:

• Captcha sau o verificare invizibilă (precum reCAPTCHA sau Turnstile) oprește majoritatea boților.
• Honeypot: un câmp ascuns pe care oamenii nu îl văd, dar boții îl completează. Este completat? Atunci mesajul nu este trimis.
• Fără text liber într-o confirmare către vizitator, sau fără nicio confirmare trimisă la adresa indicată. O simplă notificare "Mulțumim, am primit mesajul dumneavoastră" pe pagină este suficientă.
• O limită de trimitere per căsuță poștală pentru căsuța poștală a site-ului, mai mică decât cea a pachetului dumneavoastră.
• Actualizarea software-ului. Pluginurile vechi sunt o cale cunoscută de abuz.

Observați că pachetul dumneavoastră trimite brusc multe e-mailuri sau primiți o notificare că limita zilnică a fost atinsă, deși dumneavoastră trimiteți puține mesaje? Schimbați atunci imediat parolele și verificați care formular sau script trimite mesajele (lecția 3.4).

E-mailul este în altă parte, site-ul aici

O capcană frecventă: site-ul dumneavoastră se află la un furnizor, iar e-mailul la altul (de exemplu Microsoft 365 sau Google Workspace). MX-ul dumneavoastră indică spre acel alt furnizor. Dar serverul web crede în continuare că el însuși gestionează e-mailul pentru domeniul dumneavoastră, pentru că domeniul se află și pe propriul său pachet. Mesajele din formular către info@example.com sunt atunci livrate local, într-o căsuță poștală de pe serverul web unde nimeni nu se uită, sau returnează o eroare de tipul 550 ... mailbox unavailable.

Soluția este să indicați în panoul serverului web că e-mailul este gestionat în altă parte. În DirectAdmin la WebOké, aceasta este caseta de bifat "Folosiți acest server pentru gestionarea e-mailurilor mele" de la MX Records (dezactivați-o). Alte panouri au setări similare, cum ar fi "rutare e-mail: externă" în cPanel. Și mai bine: lăsați site-ul să trimită prin SMTP cu o căsuță poștală la furnizorul la care se află de fapt e-mailul dumneavoastră.

Rezumat

• E-mailul de pe site este verificat la fel de strict ca poșta electronică obișnuită. Lăsați site-ul să trimită prin SMTP cu autentificare, nu prin mail().
• Folosiți o căsuță poștală separată pentru site, cu o limită de trimitere proprie.
• Adresa vizitatorului aparține la Reply-To, niciodată la From. Altfel DMARC eșuează, iar la domeniile cu p=reject (precum yahoo.com, ziggo.nl, kpnmail.nl) mesajul este refuzat.
• Protejați formularele cu captcha, honeypot și fără confirmări cu text liber trimise la adresele indicate.
• Dacă e-mailul dumneavoastră se află la un alt furnizor, dezactivați livrarea locală pe serverul web sau trimiteți prin SMTP la acel furnizor.

Quiz

Exercițiu

Exercițiul O7.3: Verificarea mesajelor trimise de pe site. Completați un formular de pe propriul dumneavoastră site cu o adresă Gmail sau Outlook.com drept expeditor și examinați capetele de mesaj ale e-mailului primit. Răspundeți la lista de verificare: ce adresă se află în From, se află adresa vizitatorului în Reply-To, ce indică spf=, dkim= și dmarc= la Authentication-Results, trimite site-ul dumneavoastră prin SMTP sau prin mail(), și are formularul un captcha sau honeypot? Dacă nu aveți un site propriu, răspundeți la întrebări pentru exemplul din această lecție. Veți primi apoi răspunsul model.

Lectură suplimentară

Pașii din aceste articole sunt valabili pentru panourile WebOké; la alți furnizori funcționarea este similară.

• Un formular de contact pe site-ul dumneavoastră: trimiterea câmpurilor prin e-mail și prevenirea spamului
• Cum obțin expeditorul corect cu mail() în PHP? SMTP
• Trimiterea e-mailurilor prin PHP nu funcționează, înregistrările MX trimit în altă parte
• Limită pentru trimiterea de e-mailuri
• Limita zilnică de e-mailuri a fost atinsă
• Manual DirectAdmin 8.1: Toate setările la un loc: servere, porturi și securitate
• Manual DirectAdmin 5.10: E-mail la Microsoft 365 sau Google Workspace, website la WebOké